1. 分享目标：

2. 什么是微前端？

故事开始于三年前…

小明为公司重构了一版新的管理后台，采用了市面上最流行的SPA渲染模式，具体技术栈使用的是 react + react-router。

项目第一版很快就顺利上线了，但在后续的迭代中，遇到一个棘手的问题：产品经理希望快速复用之前项目的某些页面。这让小明犯了难，因为老项目是用“上古神器” jQuery 写的，完全重构成 react，成本非常高。这时后端老哥丢过来一句：“你们前端用 iframe 嵌进来就可以了吧？ ” 小明心里很清楚 iframe 有许多小毛病，但在当时，也确实没有比它更好的选择了。

上线后，随着时间的推移，用户产生了困惑：

1. 为什么这个页面的弹框不居中了？
2. 为什么这个页面的跳转记录无法保存？ ...

小明心里其实非常清楚，这一切都是 iframe 带来的弊端。

时间来到三年后的今天，小明听说微前端能够解决 iframe 的各种疑难杂症，于是展开了调研。

市面上对微前端的定义让人眼花缭乱，比如微前端是：

这里给出我对微前端最接地气的定义：

“类似于iframe的效果，但没有它带来的各种问题”——小明。

3. 主流技术方向分类

首先，“微前端”作为近几年国内前端界最火的技术之一，目前存在多个技术流派。我按照它们对 iframe 看法的不同，将主流微前端方案分为了三大派系：革新派、改良派、中间派。

3.1. 革新派 qiankun

以 qiankun 为主的革新派认为： iframe 问题很多，应避免使用它。 完全可以利用现有的前端技术自建一套应用隔离渲染方案。

3.1.1. 原理：

3.1.1.1. 基于 single-spa

将路由切换与子应用加载、卸载等生命周期结合起来是微前端的一项核心能力。这一步 qiankun 是基于 single-spa 实现的，不同的是它支持以 html 作为加载子应用的入口，不必像 single-spa 那样需要手动梳理资源链接，内部插件 import-html-entry 会自动分析 html 以获取 js 和 css。

3.1.1.2. 样式隔离

为了确保子应用之间样式互不影响，qiankun 内置了三种样式隔离模式：

1. 默认模式。

原理是加载下一个子应用时，将上一个子应用的 、等样式相关标签通通删除与替换，来实现样式隔离。缺点是仅支持单例模式（同一时间只能渲染单个子应用），且没法做到主子应用及多个子应用之间的样式隔离。

2. 严格模式。

可通过 strictStyleIsolation：true 开启。原理是利用 webComponent 的 shadowDOM 实现。但它的问题在于隔离效果太好了，在目前的前端生态中有点水土不服，这里举两个例子。

• 可能会影响 React 事件。比如这个issue 当 Shadow Dom 遇上 React 事件 ，大致原因是在 React 中事件是“合成事件”，在React 17 版本之前，所有用户事件都需要冒泡到 document 上，由 React 做统一分发与处理，如果冒泡的过程中碰到 shadowRoot 节点，就会将事件拦截在 shadowRoot 范围内，此时event.target 强制指向 shadowRoot，导致在 react 中事件无响应。React 17 之后事件监听位置由 document 改为了挂载 App 组件的 root 节点，就不存在此问题了。

• 弹框样式丢失。 原因是主流UI框架比如 antd 为了避免上层元素的样式影响，通常会把弹框相关的 DOM 通过 document.body.appendChild插入到顶层 body 的下边。此时子应用中 antd 的样式规则，由于开启了 shadowDom ，只对其下层的元素产生影响，自然就对全局 body 下的弹框不起作用了，造成了样式丢失的问题。

解决方案：调整 antd 入参，让其在当前位置渲染。

3. 实验模式。

可通过 experimentalStyleIsolation：true 开启。 原理类似于 vue 的 scope-css，给子应用的所有样式规则增加一个特殊的属性选择器，限定其影响范围，达到样式隔离的目的。但由于需要在运行时替换子应用中所有的样式规则，所以目前性能较差，处于实验阶段。

3.1.1.3. JS 沙箱

确保子应用之间的“全局变量”不会产生冲突。

1. 快照沙箱（ snapshotSandbox ）

• 激活子应用时，对着当前 window 对象照一张相（所有属性 copy 到一个新对象 windowSnapshot 中保存起来）。
• 离开子应用时，再对着 window 照一张相，对比离开时的 window 与激活时的 window （也就是 windowSnapshot ）之间的差异。
  • 记录变更。Diff 出在这期间更改了哪些属性，记录在 modifyPropsMap 对象中。
  • 恢复环境。依靠 windowSnapshot 恢复之前的 window 环境。
• 下次激活子应用时，从 modifyPropsMap 对象中恢复上一次的变更。

2. 单例的代理沙箱 （ LegacySanbox ）

与快照沙箱思路很相似，但它不用通过 Diff 前后 window 的方式去记录变更，而是通过 ES6的 Proxy 代理 window 属性的 set 操作来记录变更。由于不用反复遍历 window，所以性能要比快照沙箱好。

3. 支持多例的代理沙箱（ ProxySandbox ）

以上两种沙箱机制，都只支持单例模式（同一页面只支持渲染单个子应用）。

原因是：它们都直接操作的是全局唯一的 window。此时机智的你肯定想到了，假如为每个子应用都分配一个独立的“虚拟window”，当子应用操作 window 时，其实是在各自的“虚拟 window”上操作，不就可以实现多实例共存了？事实上，qiankun 确实也是这样做的。

既然是“代理”沙箱，那“代理”在这的作用是什么呢？

主要是为了实现对全局对象属性 get、set 的两级查找，优先使用fakeWindow，特殊情况(set命中白名单或者get到原生属性)才会改变全局真实window。

如此，qiankun 就对子应用中全局变量的 get 、 set 都实现了管控与隔离。

3.1.2. 优势：

3.1.2.1. 具有先发优势

2019年开源，是国内最早流行起来的微前端框架，在蚂蚁内外都有丰富的应用，后期维护性是可预测的。

3.1.2.2. 开箱即用

虽然是基于国外的 single-spa 二次封装，但提供了更加开箱即用的 API，比如支持直接以 HTML 地址作为加载子应用的入口。

3.1.2.3. 对 umi 用户更加友好

有现成的插件 @umijs/plugin-qiankun 帮助降低子应用接入成本。

3.1.3. 劣势：

3.1.3.1. vite 支持性差

由上可知，代理沙箱实现的关键是需要将子应用的 window “替换”为 fakeWindow，在这一步 qiankun 是通过函数 window 同名参数 + with 作用域绑定的方式，更改子应用 window 指向为 fakeWindow，最终使用 eval(...) 解析运行子应用的代码。

const jsCode = `

(function(window, self, globalThis){

    with(this){

      // your code

      window.a = 1;

      b = 2

      ...

	}

}).bind(window.proxy)(window.proxy, window.proxy, window.proxy);

` 

eval(jsCode)

问题就出在这个 eval 上， vite 的构建产物如果不做特殊降级，默认打包出的就是 ESModule 语法的代码，使用 eval 解析运行会报下图这个错误。

报错的大意是， import 语法的代码必须放在 中执行。

官方目前推荐的解决方法是关闭沙箱... 但其实还有另一种比较取巧的方案：vite 生态里有一款专门兼容此问题的vite-plugin-qiankun 插件，它的原理是： eval 虽然没办法执行静态 import 语法，但它可以执行动态 import(...) 语法。

所以这款插件的解决方案就是替换子应用代码中的静态 import 为动态 import()，以绕过上述限制。

3.1.3.2. 子应用接入成本较高，详细步骤参考子应用接入文档

umi 用户可忽略这点，尤其是 @umi/max 用户，相比 webpack 接入成本要低很多。

3.1.3.3. JS 沙箱存在性能问题，且并不完善。

大致原因是 with + proxy 带来的性能损耗，详见 JS沙箱的困境 。当然 qiankun 官方也在针对性的进行优化，进展在这篇《改了 3 个字符，10倍的沙箱性能提升？！！》文章中可见一斑 。

3.2. 改良派 wujie

3.2.1. 原理：

wujie 是腾讯出品的一款微前端框架。作为改良派的代表，它认为： iframe 虽然问题很多，但仅把它作为一个 js 沙箱去用，表现还是很稳定的，毕竟是浏览器原生实现的，比自己实现 js 沙箱靠谱多了。至于 iframe 的弊端，可以针对性的去优化：

• DOM 渲染无法突破 iframe 边界？(弹框不居中问题)

那 DOM 就不放 iframe 里渲染了，而是单独提取到一个 webComponent 里渲染，顺便用 shadowDOM 解决样式隔离的问题。

简单说，无界的方案就是：JS 放 iframe 里运行，DOM 放 webComponent 渲染。

那么问题来了： 用 JS 操作 DOM 时，两者如何联系起来呢？毕竟 JS 默认操作的总是全局的 DOM。无界在此处用了一种比较 hack 的方式：代理子应用中所有的 DOM 操作，比如将 document 下的 getElementById、querySelector、querySelectorAll、head、body 等查询类 api 全部代理到 webComponent。

下图是子应用真实运行时的例子：

至于多实例模式，就更容易理解了。给每个子应用都分配一套 iframe + webComponent 的组合，就可以实现相互之间的隔离了！

• 刷新页面会导致子应用路由状态丢失？

通过重写 iframe 实例的history.pushState 和 history.replaceState，将子应用的 path 记录到主应用地址栏的 query 参数上，当刷新浏览器初始化 iframe 时，从地址栏读到子应用的 path 并使用 iframe 的 history.replaceState 进行同步。

简单理解就是：将子应用路径记录在地址栏参数中。

3.2.2. 优势：

3.2.2.1. 相比 qiankun 接入成本更低。

• 父应用：
  • 与 iframe 的接入方式很类似，只需引入一个 React 组件渲染子应用即可。

• 子应用理论上不需要做任何改造

3.2.2.2. vite 兼容性好

直接将完整的 ESM 标签块  插入 iframe 中，避免了 qiankun 使用 eval 执行 ESM 代码导致的报错问题。

3.2.2.3. iframe 沙箱隔离性好

3.2.3. 劣势：

3.2.3.1. 坑比较多

• 明坑： 用于 JS 沙箱的 iframe 的 src 必须指向一个同域地址导致的问题。

  具体问题描述见下图：

此 [issue]() 至今无法在框架层面得到解决，属于 iframe 的原生限制。

手动的解决方案：

• 主应用提供一个路径比如说 https://host/empty ，这个路径不需要返回任何内容，子应用设置 attr 为 {src:'https://host/empty'}，这样 iframe 的 src 就是 https://host/empty。
• 在主应用 template 的 head 插入这样的代码可以避免主应用代码污染。
• 暗坑： 复杂的 iframe 到 webComponent 的代理机制，导致市面上大部分富文本编辑器都无法在无界中完好运行。所以有富文本的项目，尽量别用无界，除非你对富文本库的源码了如指掌。issues 在这里。

3.2.3.2. 长期维护性一般。

3.2.3.3. 内存开销较大

用于 js 沙箱的 iframe 是隐藏在主应用的 body 下面的，相当于是常驻内存，这可能会带来额外的内存开销。

3.3. 中间派 micro-app

3.3.1. 原理：

京东的大前端团队出品。

样式隔离方案与 qiankun 的实验方案类似，也是在运行时给子应用中所有的样式规则增加一个特殊标识来限定 css 作用范围。

子应用路由同步方案与 wujie 类似，也是通过劫持路由跳转方法，同步记录到 url 的 query 中，刷新时读取并恢复。

组件化的使用方式与 wujie 方案类似，这也是 micro-app 主打的宣传点。

最有意思的是它的沙箱方案，居然内置了两种沙箱：

1. 类 qiankun 的 with 代理沙箱，据说相比 qiankun 性能高点，但目前微前端框架界并没有一个权威的基准性能测试依据，所以并无有效依据支撑。
2. 类 wujie 的 iframe 沙箱，用于兼容 vite 场景。

开发者可以根据自身的实际情况自由选择。

整体感觉 micro-app 是一种偏“现实主义”的框架，它的特点就是取各家所长，最终成为了功能最丰富的微前端框架。

3.3.2. 优势：

3.3.2.1. 支持的功能最丰富。

3.3.2.2. 接入成本低。

3.3.2.3. 文档完善。

micro-zoe.github.io/micro-app/d…

3.3.3. 劣势：

3.3.3.1. 功能丰富导致配置项与 api 太多。

3.3.3.2. 静态资源补全问题。

静态资源补全是基于父应用的，而非子应用这需要开发者自己手动解决。

4. 选型建议

统计时间2023.12.3	npm周下载量	star数	issue数	最近更新时间	接入成本	沙箱支持vite
qiankun	22k	15k	362/1551	12天前	高	❌
wujie	1.3k	3.4k	280/271	24天前	低	✅
micro-app	1.1k	4.9k	57/748	1个月前	中	✅

1. 刚性建议。

• vite 项目且对 js 沙箱有刚需，选 wujie 或者 micro-app。
• 项目存在复杂的交互场景，比如有用到富文本编辑器库，选 wujie 前请做好充分的测试。
• 如果你的团队对主、子应用的开发完全受控，即使有隔离性问题也可以通过治理来解决，那么可以试试更轻量的 single-SPA 方案。
• 如果特别重视稳定性，那无疑是 iframe 最佳... 因为 iframe 存在的问题都是摆在明面的，市面上现有的微前端框架多多少少都有一些隐性问题。

2. 综合推荐。

主要从接入成本、功能稳定性、长期维护性三方面来衡量：

• 接入成本： wujie > microApp > qiankun （由低到高）
• 功能稳定性：qiankun > microApp > wujie
• 长期维护性：qiankun > microApp > wujie

看你的团队最看重哪一点，针对性去选择就好了，没有十全十美微前端框架，只有适合自己的。

最后

以上内容，确实会有我强烈的个人理解与观点，这也是我写文章一贯的风格。我并不喜欢那种客观且枯燥无味的文章，读完之后感觉像流水账，给不了读者任何的指导。我认为文章就是要有观点输出，技术文章也不例外，如果非常看重准确无误的表达，可以直接去看说明文档or源码，那应该是最权威的知识。如有错误或者误解，可以评论区或者私信指出，我积极改正。

作者：郑鱼咚
来源：juejin.cn/post/7309477710523269174

❝

工欲善其事必先利其器，使用过内网开发的小伙伴都知道，CV大法在内网基本就废了，查资料也是非常的不便。对于一名程序员来说，如果把搜索引擎和CV键给他ban了，遇到问题后那基本是寸步难行。今天给大家介绍几种帮助内网开发提效的方法，希望能够帮助到大家。

一、文档站点内网部署

可以把项目中所用技术和框架的文档部署到公司内网中。

以elementPlus为例：

1、访问gh-pages分支https://github.com/element-plus/element-plus/tree/gh-pages，下载文档站源码。

2、将文档站部署到内网服务器（以nginx为例）。

    server {

        listen       9800;

        server_name  localhost;



        location / {

            root   html/element-plus-gh-pages;

            index  index.html index.htm;

            try_files $uri $uri/ /element-plus-gh-pages/index.html;

        }



        error_page   500 502 503 504  /50x.html;

        location = /50x.html {

            root   html;

        }

    }

部署后的访问速度也是非常快的

使用这种方式，随着部署的站点增多，后续框架、文档更新的时候，维护起来相对是比较麻烦的。且只能查看文档，遇到问题需要求助度娘还是不太方便。

下面介绍两种物理外挂，可以直接访问外网。

二、USB跨屏穿越器数据线

个人感觉此方案的体验是最好的，缺点是需要两台电脑，并且需要花钱买一根线，价格在80-200之间。

购买

某宝、某鱼都有销售，我是在某宝85块买的。

使用

连接两台电脑的USB端口即可，会自动安装驱动，那根线实际上就相当于是一个文件中转器，可以实现剪切板、文件的互传。使用体验就跟一台电脑连接了两台显示器一样。如下图所示：

三、手机投屏

本文重点介绍此方案，因为可以白嫖且不需要第二台电脑。一部安卓手机+数据线即可，缺点是文件传输不太方便。它就是一个开源投屏项目scrcpy。可以看到，此项目在github上拥有高达102k的star数量。

✨亮点

• 亮度 （原生，仅显示设备屏幕）


• 表演 （30~60fps）


• 质量 （1920×1080或以上）


• 低延迟 （70~100ms）


• 启动时间短 （显示第一张图像约1秒）


• 非侵入性 （设备上没有安装任何东西）


• 不需要 ROOT


• 有线无线都可连接


• 可以随便调整界面和码率


• 画面随意裁剪，自带录屏（手游直播利器）


• 支持多设备同时投屏


• 利用电脑的键盘和鼠标可以控制手机


• 把 APK 文件拖拽到电脑窗口即可安装应用到手机，把普通文件拖拽到窗口即可复制到手机


• 手机电脑共享剪贴板


• 自动检测USB连接的设备


• 可直接添加设备的局域网IP，达到无线控制的效果


• 将自动保存连接过的IP地址，下次输入时，自动提醒


• 支持设备别名


• 支持中英两种语言


• Tray menu


• 等等等...

安装

根据不同系统直接去release页面下载对应版本即可：github.com/Genymobile/…

使用

下载解压完，进入软件目录，点击下图按钮打开命令行界面，输入启动命令即可。

命令行输入scrcpy，按回车， 猿神，起洞！

启动之后，即可使用鼠标操作手机，非常的丝滑

1、手机复制文本到电脑

2、电脑复制文本到手机

可以看到，使用投屏的方式，也可以实现CV大法。并且可以使用手机端的外网搜索资料、解决问题等。以下是该项目的快捷键，熟练使用，即可达到人机合一的地步。

快捷键

使用小技巧

经过笔者几天的使用，总结出几个小技巧。

1、电脑键盘控制手机进行中文输入，必须使用正确的输入法组合。

手机端：讯飞输入法(搜狗输入法不支持)

电脑端：ENG(使用英文键盘)

2、手机熄屏状态下投屏。 在scrcpy命令后加上熄屏参数即可：scrcpy --turn-screen-off

这样就可以在手机熄屏的状态下，仍可以被电脑操作，达到节省电量和减轻发热的目的。

诸如此类的命令参数还有很多，执行scrcpy --help就可查看详细的帮助文档。

衍生项目

因为开源的特性，scrcpy也衍生了一些相关项目，列举其中一些：

• QtScrcpy 使用qt重新实现的桌面端，并加强了对游戏的支持。


• scrcpy-gui 为scrcpy的命令行提供了gui界面。


• guiscrcpy 另一个scrcpy的gui界面。


• scrcpy-docker docker版本的scrcpy。


• scrcpy-go go语言版本的scrcpy，增强对游戏的支持。

总结

第二第三种方法虽然建立了内网开发电脑和外网设备的联系，但是是不会被公司的安全系统检测到一机双网的，因为其本质就类似于设计模式中的发布订阅模式，用数据线充当了中间人，两台设备之间方便传输数据了而已，不会涉及到联网。

内网开发的痛点，无非就是复制粘贴、文件传输不便，只要打通这个链路，就能解决此问题。以上三个方法，笔者在实际工作中都用到了，确实极大的提高了工作效率。如果你也在饱受内网开发的折磨，不妨试试这几个方法。

背景

最近在开发H5，ui稿给的border：1px solid,因为ui稿上的宽度是750px，我们运行的页面宽度是375px，所以我们需要把所以尺寸/2。所以我们可能会想写border：0.5px solid。但是实际上，我们看页面渲染，仍然是渲染1px而不是0.5

示例代码

<!DOCTYPE html>

<html lang="en">

  <head>

    <meta charset="UTF-8" />

    <meta name="viewport" content="width=device-width, initial-scale=1.0" />

    <style>

      * {

        margin: 0;

        padding: 0;

        box-sizing: border-box;

      }



      body {

        font-family: Arial, sans-serif;

      }



      .flex {

        display: flex;

      }

      .item {

        margin-right: 10px;

        padding: 10px;

        font-size: 13px;

        line-height: 1;

        background-color: rgba(242, 243, 245,1);

      }

      .active {

        color: rgba(250, 100, 0, 1);

        font-size: 14px;

        border: 0.5px solid ;

      }

    </style>

  </head>

  <body>

    <div class="flex">

      <!-- <div class="item active">

        active

      </div> -->

      <div class="item">

        item1

      </div>

      <div class="item">

        item2

      </div>

      <div class="item">

        item3

      </div>

    </div>

  </body>

</html>

在没active的情况下

他们的内容都是占13px

在有active的情况下

active占了14px这个是没问题的，因为它font-size是14px嘛，但是我们是设置了border的宽度是0.5px，但展现的却是1px。

再来看看item

它内容占了16px，它受到相邻元素影响是14px+2px的上下边框

为啥border是1px呢

在 CSS 中，边框可以设置为 0.5px，但在某些情况下，尤其是低分辨率的屏幕上，浏览器可能会将其渲染为 1px 或根本不显示。这是因为某些浏览器和显示设备不支持小于 1px 的边框宽度或不能准确渲染出这样的细小边框。

浏览器渲染机制

• 不同浏览器对于小数像素的处理方式不同。一些浏览器可能会将 0.5px 边框四舍五入为 1px，以确保在所有设备上的一致性。

设备像素比

• 在高 DPI（如 Retina 显示器）设备上，0.5px 边框可能看起来更清晰，因为这些设备可以渲染更细的边框。


• 在低 DPI 设备上，0.5px 边框可能会被放大或者根本不会被显示。

解决办法

方法一：使用伪类和定位

.active {

  color: rgba(250, 100, 0, 1);

  font-size: 14px;

  position: relative;

}

.active::after {

  content: "";

  pointer-events: none;

  display: block;

  position: absolute;

  left: 0;

  top: 0;

  transform-origin: 0 0;

  border: 1px #ff892e solid;

  box-sizing: border-box;

  width: 100%;

  height: 100%;

}

另外的item的内容高度也是14px了符合要求

方法二：使用阴影，使用F12看的时候感觉还是有些问题

.active2 {

  margin-left: 10px;

  color: rgba(250, 100, 0, 1);

  font-size: 14px;

  position: relative;

  box-shadow: 0 0 0 0.5px #ff892e;

}

方法三：使用svg，但这种自己设置了宽度。

<div class="active">

  <svg width="100%" height="100%" viewBox="0 0 100 100" preserveAspectRatio="none">

    <rect x="0" y="0" width="100" height="100" fill="none" stroke="#ff892e" stroke-width="0.5"></rect>

  </svg>

  active

</div>

方案四：使用svg加定位，也比较麻烦，而且有其他的问题

<div class="active">

    <svg viewBox="0 0 100 100" preserveAspectRatio="none">

        <rect x="0" y="0" width="100" height="100" fill="none" stroke="#ff892e" stroke-width="0.5"></rect>

    </svg>

    <div class="content">active</div>

</div>

.active {

  color: rgba(250, 100, 0, 1);

  font-size: 14px;

  position: relative;

  display: inline-block; 

}

.active svg {

  position: absolute;

  top: 0;

  left: 0;

  width: 100%;

  height: 100%;

  pointer-events: none; 

  box-sizing: border-box;

}

.active .content {

  position: relative;

  z-index: 1; 

}

方法五：使用一个父元素 比较麻烦

<div class="border-container">

  <div class="active">active</div>

</div>



.border-container {

  display: inline-block;

  padding: 0.5px; 

  background-color: #ff892e; 

}



.active {

  color: rgba(250, 100, 0, 1);

  font-size: 14px;

  background-color: white; 

}

最后

在公司里，我们使用的都是方案一，这样active和item它们的内容高度都是14px了。然后我们再给他们的父盒子加上 align-items: center。这样active的高度是14px，其他都是13px了。但是active的高度会比其他item的盒子高1px，具体看个人需求是否添加吧。

1、背景

前两天老板找到我说有一个需求，要求使用英雄联盟的人物动画制作一个加载中的组件，类似于下面这样：

我定眼一看：这个可以实现，但是需要UI妹子给切图。

老板：UI？ 咱们啥时候招的UI !

我：老板，那不中呀，不切图弄不成呀。

老板：下个月绩效给你A。

我：那中，管管管。

2、调研

发动我聪明的秃头，实现这个需求有以下几种方案：

• 切动画帧，没有UI不中❎。


• 去lol客户端看看能不能搞到什么美术素材，3D模型啥的，可能行❓


• 问下 gpt4o，有没有哪个老表收集的有lol英雄的美术素材，如果有那就更得劲了✅。

经过我一番搜索，发现了这个网站：model-viewer，收集了很多英雄联盟的人物模型，模型里面还有各种动画，还给下载。老表，这个需求稳了50%了！

接下来有几种选择：

• 将模型动画转成动画帧，搞成雪碧图，较为麻烦，且动画不支持切换。


• 直接加载模型，将模型放在进度条上，较为简单，支持切换不同动画，而且可以自由过渡。就是模型文件有点大，初始化加载可能耗时较长。但是后续缓存一下就好了。

聪明的我肯定先选第二个方案呀，你糊弄我啊，我糊弄你。

3、实现

web中加载模型可以使用谷歌基于threejs封装的 model-viewer, 使用现代的 web component 技术。简单易用。

先初始化一个vue工程

 npm create vue@latest

然后将里面的初始化的组件和app.vue里面的内容都删除。

安装model-viewer依赖：

npm i three // 前置依赖

npm i @google/model-viewer

修改vite.config.js，将model-viewer视为自定义元素，不进行编译

import { fileURLToPath, URL } from 'node:url'

​

import { defineConfig } from 'vite'

import vue from '@vitejs/plugin-vue'

​

// https://vitejs.dev/config/

export default defineConfig({

  plugins: [

    vue({

      template: {

        // 添加以下内容

        compilerOptions: {

          isCustomElement: (tag) => ['model-viewer'].includes(tag)

        }

      }

    })

  ],

  resolve: {

    alias: {

      '@': fileURLToPath(new URL('./src', import.meta.url))

    }

  },

  assetsInclude: ['./src/assets/heros/*.glb']

})

​

新建 src/components/LolProgress.vue

<template>

  <div class="progress-container">

    <model-viewer

      :src="hero.src"

      disable-zoom

      shadow-intensity="1"

      :camera-orbit="hero.cameraOrbit"

      class="model-viewer"

      :style="heroPosition"

      :animation-name="animationName"

      :camera-target="hero.cameraTarget"

      autoplay

      ref="modelViewer"

    ></model-viewer>

    <div

      class="progress-bar"

      :style="{ height: strokeWidth + 'px', borderRadius: strokeWidth / 2 + 'px' }"

    >

      <div class="progress-percent" :style="currentPercentStyle"></div>

    </div>

  </div>

</template>

​

<script setup lang="ts">

import { computed, onMounted, ref, watch, type PropType } from 'vue'

/** 类型 */

interface Hero {

  src: string

  cameraOrbit: string

  progressAnimation: string

  finishAnimation: string

  finishAnimationIn: string

  cameraTarget: string

  finishDelay: number

}

type HeroName = 'yasuo' | 'yi'

​

type Heros = {

  [key in HeroName]: Hero

}

const props = defineProps({

  hero: {

    type: String as PropType<HeroName>,

    default: 'yasuo'

  },

  percentage: {

    type: Number,

    default: 100

  },

  strokeWidth: {

    type: Number,

    default: 10

  },

  heroSize: {

    type: Number,

    default: 150

  }

})

​

const modelViewer = ref(null)

​

const heros: Heros = {

  yasuo: {

    src: '/src/components/yasuo.glb',

    cameraOrbit: '-90deg 90deg',

    progressAnimation: 'Run2',

    finishAnimationIn: 'yasuo_skin02_dance_in',

    finishAnimation: 'yasuo_skin02_dance_loop',

    cameraTarget: 'auto auto 0m',

    finishDelay: 2000

  },

  yi: {

    src: '/src/components/yi.glb',

    cameraOrbit: '-90deg 90deg',

    progressAnimation: 'Run',

    finishAnimationIn: 'Dance',

    finishAnimation: 'Dance',

    cameraTarget: 'auto auto 0m',

    finishDelay: 500

  }

}

​

const heroPosition = computed(() => {

  const percentage = props.percentage > 100 ? 100 : props.percentage

  return {

    left: `calc(${percentage + '%'} - ${props.heroSize / 2}px)`,

    bottom: -props.heroSize / 10 + 'px',

    height: props.heroSize + 'px',

    width: props.heroSize + 'px'

  }

})

​

const currentPercentStyle = computed(() => {

  const percentage = props.percentage > 100 ? 100 : props.percentage

  return { borderRadius: `calc(${props.strokeWidth / 2}px - 1px)`, width: percentage + '%' }

})

​

const hero = computed(() => {

  return heros[props.hero]

})

​

const animationName = ref('')

​

watch(

  () => props.percentage,

  (percentage) => {

    if (percentage < 100) {

      animationName.value = hero.value.progressAnimation

    } else if (percentage === 100) {

      animationName.value = hero.value.finishAnimationIn

      setTimeout(() => {

        animationName.value = hero.value.finishAnimation

      }, hero.value.finishDelay)

    }

  }

)

onMounted(() => {

  setTimeout(() => {

    console.log(modelViewer.value.availableAnimations)

  }, 2000)

})

</script>

<style scoped>

.progress-container {

  position: relative;

  width: 100%;

}

.model-viewer {

  position: relative;

  background: transparent;

}

.progress-bar {

  border: 1px solid #fff;

  background-color: #666;

  width: 100%;

}

.progress-percent {

  background-color: aqua;

  height: 100%;

  transition: width 100ms ease;

}

</style>

组件非常简单，核心逻辑如下：

• 根据传入的英雄名称加载模型


• 指定每个英雄的加载中的动画，


• 加载100%,切换完成动作进入动画和完成动画即可。


• 额外的细节处理。
  
  

  最后修改 app.vue:

  
  

  <script setup lang="ts">
  
  import { ref } from 'vue'
  
  import LolProgress from './components/LolProgress.vue'
  
  const percentage = ref(0)
  
  setInterval(() => {
  
    percentage.value = percentage.value + 1
  
  }, 100)
  
  </script>
  
  ​
  
  <template>
  
    <main>
  
      <LolProgress
  
        :style="{ width: '200px' }"
  
        :percentage="percentage"
  
        :heroSize="200"
  
        hero="yasuo"
  
      />
  
    </main>
  
  </template>
  
  ​
  
  <style scoped></style>
  
  ​
  
  

  
  

这不就完成了吗，先拿给老板看看。

老板：换个女枪的看看。

我：好嘞。

老板：弄类不赖啊小伙，换个俄洛伊的看看。

4、总结

通过本次需求，了解到了 model-viewer组件。

老板招个UI妹子吧。

在线体验：github-pages

前言

做了7年前端我一直不知道瀑布流是什么（怪设计师不争气啊，哈哈哈），我一直以为就是个普通列表，几行css解决的那种。

当然瀑布流确实有css解决方案，但是这个方案对于分页列表来说完全不能用，第二页内容一出来位置都变了。

我看了一下掘金的一些文章，好长啊，觉得还是自己想一下怎么写吧。就自己实现了一遍。希望思路给大家一点帮助。

分析瀑布流

以小红书的瀑布流为例，相同宽度不同高度的卡片堆叠在一起形成瀑布流。

这里有两个难点：

• 卡片高度如何确定？


• 堆叠布局如何实现？

卡片的高度 = padding + imageHeight + textHeight....

不固定的内容包括：图片高度、标题行数

也就是说当我们解决了图片和标题的高度问题，那么瀑布流的第一个问题就解决了。（感觉已经写好代码了一样）

堆叠问题——因为css没有这样的布局方式，所以肯定得用js实现。最简单的解决方案就是对每一个盒子进行绝对定位。

这个问题就转换成计算现有盒子的定位问题。

从问题到代码

第一个问题——图片高度

无论是企业业务场景还是个人开发，通过后端返回图片的width、height都是合理且轻松的。

前端去获取图片信息，无疑让最重要的用户体验变得糟糕。前端获取图片信息并不困难，但是完全没有必要。

所以我直接考虑后端返回图片信息的情况。

const realImageHeight = imageWidth / imageHeight * cardContentWidth;  

图片高度轻松解决，无平台差异

第二个问题——文字高度

从小红书可以看出，标题有些两行有些一行，也有些三行。

如果你固定一行，这个问题完全可以跳过。

• 方案一：我们可以用字数和宽度来计算可能得行数
  
  优势：速度快，多平台复用
  
  劣势：不准确（标题包括英文中文）


• 方案二：我们可以先渲染出来再获取行数
  
  优势：准确
  
  劣势：相对而言慢，不同平台方法不同

准确是最重要的！选择方案二

其实方案二也有两种方案，一种是用canvas模拟，这样可以最大限度摆脱平台（h5、小程序）的限制，

然而我试验后，canvas还没找到准确的计算的方法（待后续更新）

第二种就是用div渲染一遍，获取行数或者高度。

创建一个带有指定样式的 div 元素

function createDiv(style: string): HTMLDivElement {  

    const div = document.createElement('div');  

    div.style.cssText = style;  

    document.body.appendChild(div);  

    return div;  

}  

计算文本数组在指定字体大小和容器宽度下的行数

/**  

* 计算文本数组在指定字体大小和容器宽度下的行数  

* @param texts - 要渲染的文本数组  

* @param fontSize - 字体大小（以像素为单位）  

* @param lineHeight - 字体高度（以像素为单位）  

* @param containerWidth - 容器宽度（以像素为单位）  

* @param maxLine - 最大行数（以像素为单位）  

* @returns 每个文本实际渲染时的行数数组  

*/  

export function calculateTextLines(  

    texts: string[],  

    fontSize: number,  

    lineHeight: number,  

    containerWidth: number,  

    maxLine?: number  

): number[] {  

// 创建一个带有指定样式的 div 元素  

    const div = createDiv(`font-size: ${fontSize}px; line-height: ${lineHeight}px; width: ${containerWidth}px; white-space: pre-wrap;`);  

    const results: number[] = [];  

    texts.forEach((text) => {  

        div.textContent = text;  

        // 获取 div 的高度，并根据字体大小计算行数  

        const divHeight = div.offsetHeight;  

        const lines = Math.ceil(divHeight / lineHeight);  

        maxLine && lines > maxLine ? results.push(maxLine) : results.push(lines);  

    });  

  

    // 清理 div  

    removeElement(div);  



    return results;  

}  

这个问题小程序如何解决放在文末

第三个问题——每个卡片的定位问题

解决了上面的问题，就解决了盒子高度的问题，这个问题完全就是相同宽度不同高度盒子的堆放问题了

问题的完整描述是这样的：

写一个ts函数实现将一堆小盒子，按一定规则顺序推入大盒子里

函数输入：小盒子高度列表

小盒子：不同小盒子高度不一致，宽度为stackWidth，彼此间隔gap

大盒子：高度无限制，宽度为width

堆放规则：优先放置高度低的位置，高度相同时优先放在左侧

返回结果：不同盒子的高度和位置信息

如果你有了这么清晰的描述，接下去的工作你只需要交给gpt来写你的函数

// 返回的盒子信息  

export interface Box {  

    x: number;  

    y: number;  

    height: number;  

}  

// 盒子堆叠的方法类  

export class BoxPacker {  

    // 返回的小盒子信息列表  

    private boxes: Box[] = [];  

    // 大盒子宽度  

    private width: number;  

    // 小盒子宽度  

    private stackWidth: number;  

    // 小盒子间隔  

    private gap: number;  



    constructor(width: number, stackWidth: number, gap: number) {  

    this.width = width;  

    this.stackWidth = stackWidth;  

    this.gap = gap;  

    this.boxes = [];  

}  

// 添加单个盒子  

public addBox(height: number): Box[] {  

    return this.addBoxes([height]);  

}  

// 添加多个盒子（一般用这个方法）  

public addBoxes(heights: number[], isReset?: boolean): Box[] {  

    isReset && (this.boxes = [])  

    console.log('this.boxes—————— ', JSON.stringify(this.boxes) )  



    for (const height of heights) {  

        const position = this.findBestPosition();  

        const newBox: Box = { x: position.x, y: position.y, height };  

        this.boxes.push(newBox);  

    }  

    return this.boxes;  

}  

// 查找定位函数  

private findBestPosition(): { x: number; y: number } {  

    let bestX = 0;  

    let bestY = Number.MAX_VALUE;  



    for (let x = 0; x <= this.width - this.stackWidth; x += this.stackWidth + this.gap) {  

        const currentY = this.getMaxHeightInColumn(x, this.stackWidth);  

        if (currentY < bestY || (currentY === bestY && x < bestX)) {  

            bestX = x;  

            bestY = currentY;  

        }  

    }  



    return { x: bestX, y: bestY };  

}  

  

private getMaxHeightInColumn(startX: number, width: number): number {  

    return this.boxes  

        .filter(box => box.x >= startX && box.x < startX + width)  

        .reduce((maxHeight, box) => Math.max(maxHeight, box.y + box.height + this.gap), 0);  

}  

}  

  

这样我们就实现了根据高度获取定位的功能了

来实现一波

核心的代码就是获取每个盒子的定位、宽高信息

// 实例  

const boxPacker = useMemo(() => {  

    return new BoxPacker(width, stackWidth, gap)  

}, []);  

  

const getCurrentPosition = (currentData: DataItem[], reset?: boolean) => {  

    // 获取标题文本行数列表  

    const textLines = calculateTextLines(currentData.map(item => item.title),card.fontSize,card.lineHeight, cardContentWidth)  

    // 获取图片高度列表  

    const imageHeight = currentData.map(item => (item.imageHeight / item.imageWidth * cardContentWidth))  

    // 获取小盒子高度列表  

    const cardHeights = imageHeight.map((h, index) => (  

    h + textLines[index] * card.lineHeight + card.padding * 2 + (card?.otherHeight || 0)  

    )  

    );  

    // 获取盒子定位信息  

    const boxes = boxPacker.addBoxes(  

        cardHeights,  

        reset  

    )  

    // 返回盒子列表信息  

    return boxes.map((box, index) => ({  

        ...box,  

        title: currentData[index]?.title,  

        url: currentData[index]?.url,  

        imageHeight: imageHeight[index],  

    }))  

}  

set获取到的盒子信息

const [boxPositions, setBoxPositions] = useState<(Box & Pick<DataItem, 'url' | 'title' | 'imageHeight'>)[]>([]);  

useEffect(() => {  

    // 首次和刷新  

    if (page === 1) {  

        setBoxPositions(getCurrentPosition(data, true))  

    } else {  

    // 加载更多  

        setBoxPositions(getCurrentPosition(data.slice((page - 1) * pageSize, page * pageSize)))  

    }  

}, [])  

效果如下

小程序获取文本高度

从上面的分析可以看出来只有文本高度实现是不同的，如果canvas方案实验成功，说不定还能做到大一统。

目前没成功大家就先看看我的目前方案：先实际渲染文字然后读取信息，然后获取实际高度

import React, {useEffect, useMemo, useState} from 'react'  

import { View } from '@tarojs/components'  

import Taro from "@tarojs/taro";  

import './index.less'  

import {BoxPacker} from "./flow";  

  

const data = [  

    'vwyi这是一个标题，这是一个标题，这是一个标题，这是一个标题',  

    '这是一个标题',  

    '这是一个标题,这是一个标题,这是一个标题,这是一个标题',  

    '这是一个标题',  

    '这是一个标题,这是一个标题,这是一个标题,一个标题',  

    '这是一个标题,这是一个标题,这是一个标题,这题',  

    '这是一个标题,这是一个标题,这是一',  

    '这是一个标题,这是一个标题,这是一',  

];  

  

function Index() {  

const boxPacker = useMemo(() => new BoxPacker(320, 100, 5), []);  

  

const [boxPositions, setBoxPositions] = useState<any[]>([])  

function getTextHeights() {  

return new Promise((resolve, reject) => {  

    Taro.createSelectorQuery()  

        .selectAll('#textContainer .text-item')  

        .boundingClientRect()  

        .exec(res => {  

            if (res && res[0]) {  

                const heights = res[0].map(item => item.height);  

                resolve(heights);  

            } else {  

                reject('No buttons found');  

            }  

        });  

    });  

}  

useEffect(() => {  

    getTextHeights().then(h => {  

        setBoxPositions(boxPacker.addBoxes(h))  

    })  

}, [])  

return (  

<View className="flow-container">  

<View id="textContainer">  

{  

data.map((item, index) => (<View key={index} className="text-item">{item}</View>))  

}  

</View>  

<View className="text-box-container">  

{boxPositions.map((position, index) => (  

<View  

key={index}  

className="text-box"  

style={{  

left: `${position.x}px`,  

top: `${position.y}px`,  

height: `${position.height}px`,  

width: '100px', // 假设盒子的宽度固定为100px  

}}  

>  

{`${data[index]}`}  

</View>  

))}  

  

</View>  

  

</View>  

)  

}  

  

export default Index  

  

项目react源码地址

面试官：看你简历上做过图片或文件批量下载，那么假如我一次性下载几十个，如何去控制并发请求的？

让我想想，额~， 选中ID，循环请求？，八嘎！肯定不是那么沙雕的做法，这样做服务器直接崩溃啦！突然灵光一现，请求池！！！

我：利用Promise模拟任务队列，从而实现请求池效果。

面试官：大佬！

废话不多说，正文开始：

众所周知，浏览器发起的请求最大并发数量一般都是6~8个，这是因为浏览器会限制同一域名下的并发请求数量，以避免对服务器造成过大的压力。

首先让我们来模拟大量请求的场景

const ids = new Array(100).fill('')



console.time()

for (let i = 0; i < ids.length; i++) {

  console.log(i)

}

console.timeEnd()

一次性并发上百个请求，要是配置低一点，又或者带宽不够的服务器，直接宕机都有可能，所以我们前端这边是需要控制的并发数量去为服务器排忧解难。

什么是队列？

先进先出就是队列，push一个的同时就会有一个被shift。我们看下面的动图可能就会更加的理解：

我们接下来的操作就是要模拟上图的队列行为。

定义请求池主函数函数

export const handQueue = (  

  reqs // 请求数量

) => {}

接受一个参数reqs，它是一个数组，包含需要发送的请求。函数的主要目的是对这些请求进行队列管理，确保并发请求的数量不会超过设定的上限。

定义dequeue函数

const dequeue = () => {  

  while (current < concurrency && queue.length) {  

    current++;  

    const requestPromiseFactory = queue.shift() // 出列  

    requestPromiseFactory()  

      .then(() => { // 成功的请求逻辑  

      })  

      .catch(error => { // 失败  

        console.log(error)  

      })  

      .finally(() => {  

        current--  

        dequeue()  

      });  

  }  

}

这个函数用于从请求池中取出请求并发送。它在一个循环中运行，直到当前并发请求数current达到最大并发数concurrency或请求池queue为空。对于每个出队的请求，它首先增加current的值，然后调用请求函数requestPromiseFactory来发送请求。当请求完成（无论成功还是失败）后，它会减少current的值并再次调用dequeue，以便处理下一个请求。

定义返回请求入队函数

return (requestPromiseFactory) => {  

  queue.push(requestPromiseFactory) // 入队  

  dequeue()  

}

函数返回一个函数，这个函数接受一个参数requestPromiseFactory，表示一个返回Promise的请求工厂函数。这个返回的函数将请求工厂函数加入请求池queue，并调用dequeue来尝试发送新的请求，当然也可以自定义axios，利用Promise.all统一处理返回后的结果。

实验

const enqueue = requestQueue(6) // 设置最大并发数

for (let i = 0; i < reqs.length; i++) {  // 请求

  enqueue(() => axios.get('/api/test' + i))  

}

我们可以看到如上图所示,请求数确实被控制了，只有有请求响应成功的同时才会有新的请求进来，极大的降低里服务器的压力，后端的同学都只能喊6。

整合代码

import axios from 'axios'



export const handQueue = (

  reqs // 请求总数

) => {

  reqs = reqs || []





  const requestQueue = (concurrency) => {

    concurrency = concurrency || 6 // 最大并发数

    const queue = [] // 请求池

    let current = 0



    const dequeue = () => {

      while (current < concurrency && queue.length) {

        current++;

        const requestPromiseFactory = queue.shift() // 出列

        requestPromiseFactory()

          .then(() => { // 成功的请求逻辑

          })

          .catch(error => { // 失败

            console.log(error)

          })

          .finally(() => {

            current--

            dequeue()

          });

      }



    }



    return (requestPromiseFactory) => {

      queue.push(requestPromiseFactory) // 入队

      dequeue()

    }



  }



  const enqueue = requestQueue(6)



  for (let i = 0; i < reqs.length; i++) {



    enqueue(() => axios.get('/api/test' + i))

  }

}

实战文章

之前写过一篇关于web-worker大文件切片的案例文章，就是利用了此特性感兴趣的小伙伴可以看看web-worker的基本用法并进行大文件切片上传（附带简易node后端）

大家好，作为今年刚毕业的大聪明（小🐂🐎），知道今年不好就业，费心费力的面试终于进了个小公司，然后我的奇妙之旅开始了。

叮！闹钟响了！牙都不刷了，直接起床出门去上班，身为🐂🐎就要有早起吃草干活的觉悟，所以我是个很合格的食草动物。只不过，下面的信息，让我一天当动物的好心情都没了。

部署？因为该公司人数比较少，也没有自动化部署操作，只能让前端build一下dist包然后丢给后端，让后端部署，然后该项目也比较急，我刚来，也不好意思@后端，恰巧跟我对接的后端也是刚来不熟悉，所以我就跟负责人继续扯皮拖延时间了。（真是不好意思，假的）↓↓↓

终于经过不断努力（后端），部署好了，但是，我的样式乱了，为什么呢？看了一下网络和源代码，样式文件都请求到了，问了后端，一致说是我前端的问题，我懵了，然后快马加鞭查找问题

解决

ok，那我先看打包的dist文件有样式有问题吗，使用npm安装个 http-server 运行打包后的index.html，运行打开运行后的地址，欧克样式没乱，文件引用也没问题，那到底是什么鬼影响的呢？

在我百思不得其解的时候，我打开了神器--csdn，搜索打包dist部署后样式文件不生效，就遇到了这个神文t.csdnimg.cn/WbQyq
欧克，按照博主说的Nginx没有配置这两个东西而导致的，我有点不确定是不是，有点犹犹豫豫的找到后端说帮我在Nginx配置文件的http加下这两个配置，然后样式就好了，完美！后端由于疏忽，没加上就把问题推给我，结果被我扳回一城。

include   mime.types;

default_type  application/octet-stream;

总之，添加 include mime.types; 和 default_type application/octet-stream; 配置后，Nginx能够正确地识别和处理CSS文件的MIME类型，从而确保浏览器能够正确加载和应用CSS样式。

所以，前端仔不能只当前端仔，还是要好好学点服务端的知识，不然锅给你，你还认为这是你该背的锅。

以上是开玩笑的描述，只是为了吸引增加阅读量

在一个美好的周末，闲来无事，约上朋友一起在家打麻将，奈何尘封已久的麻将包里翻来翻去也没找到骰子的踪影，于是想在网上找一个骰子模拟器来代替，找了半天都没有发现一款合适好用的软件，于是心血来潮，打算自己做一个🎲模拟器。

1.制定需求设计以及技术方案

1.骰子模型

• 用户可以选择多种骰子模型，如六面 15面 20面等不同风格的供选择


• 并且可以选择要投掷骰子的数量 暂定1-10

2.分数计算规则

• 每次投掷完后会自动计算总点数并显示在屏幕上


• 可以保存历史摇骰子记录 最多支持历史100条记录


• 可以自定义用户参与摇骰子，投掷完成后会显示：luke摇出了xx点。。并且保存在历史记录中


• 支持多人参与摇骰子比赛：比如先加入4名玩家，开始后会依次提示轮到哪位玩家来开始投掷，并且可以选择每局大家需要投掷的次数，最后会统计总点数以及排名。

3.动画特效

• 每次投掷时对骰子随机一个角度以及投掷方向，如果同时投掷多个骰子则随机每一个骰子的角度，给骰子施加一个向赌盘中心的力，让骰子随机落在赌盘中部，在赌盘周围增加一道空气墙来阻止骰子移动到牌桌外。


• 模拟不同骰子的落地音效

4.技术实现

• 利用threejs来实现webgl相关渲染。如骰子模型、场景渲染、相机、棋盘等。


• 利用cannosjs来模拟物理引擎。如骰子碰撞检测、抛出坠落动画、重力加速等物理效果。

2.效果展示

3.开始实现

准备3d骰子模型和棋盘素材

首先是找到合适的gltf模型，这里我们在sketchfab上找到了一款质感很真实的骰子模型。下载下来的模型可以通过gltf-viewer来查看模型效果。
棋盘的话其实是一张图片平铺起来的，这里我用了一张木地板图片。

引入资源以及初始化webgl场景

import * as CANNON from "cannon-es";

import * as THREE from 'three';

import { OrbitControls } from 'three/addons/controls/OrbitControls.js';

import { GLTFLoader } from 'three/addons/loaders/GLTFLoader.js';

import { GUI } from 'three/addons/libs/lil-gui.module.min.js';





const scene = new THREE.Scene();

const camera = new THREE.PerspectiveCamera(75, window.innerWidth / window.innerHeight, 0.1, 1000);

const renderer = new THREE.WebGLRenderer();

renderer.setSize(window.innerWidth, window.innerHeight);

document.body.appendChild(renderer.domElement);



//创建物理世界对象

const world = new CANNON.World();

// 设置物理世界重力加速度

world.gravity.set(0, -100, 0);  //重力加速度： 单位：m/s²

创建物理模型、地面以及网格模型地面

这里简单叙述一下物理世界和webgl世界的联系以及如何在webgl场景里模拟出真实的物理效果。

• 首先在three创建的webgl场景是无法直接创建并感知到物理世界的，threejs只负责实时渲染物理的状态并展示在画布上。而cannos恰好相反，它不负责渲染，只负责创建一个物理世界以及具备物理引擎的物体，并根据物体状态实时计算物体的位置、角度等。并把这些信息实时同步给webgl场景中的模型，把模型渲染到页面上实现物理世界的可视化。


• 所以我们创建骰子、地面等模型都需要创建两份。一份在webgl中创建，一份在物理世界中创建，并且保持同样的尺寸。
  
  

    //创建骰子网格模型（gltf模型）
  
    const loader = new GLTFLoader();
  
    const gltf = await loader.loadAsync('./assets/model/dice_model.glb');
  
  
  
    const meshModel = gltf.scene;//获取箱子网格模型
  
    meshModel.position.set(50,30,50);
  
    meshModel.scale.set(5,5,5);
  
    scene.add(meshModel);
  
  
  
    //包围盒计算
  
    const box3 = new THREE.Box3();
  
    box3.expandByObject(meshModel);//计算模型包围盒
  
    const size = new THREE.Vector3();
  
    box3.getSize(size);//包围盒计算箱子的尺寸
  
  
  
    // 创建骰子物理模型
  
    const sphereMaterial = new CANNON.Material()//碰撞体材质
  
    // 物理正方体
  
    const bodyModel = new CANNON.Body({
  
        mass: 0.3, // 碰撞体质量0.3kg
  
        position: new CANNON.Vec3(50,30,50), // 位置
  
        shape: new CANNON.Box(new CANNON.Vec3(size.x/2, size.y/2, size.z/2)),
  
        material: sphereMaterial
  
    });
  
    
  
    
  
    // 物理地面
  
    const groundMaterial = new CANNON.Material()
  
    const groundBody = new CANNON.Body({
  
        mass: 0, // 质量为0，始终保持静止，不会受到力碰撞或加速度影响
  
        shape: new CANNON.Plane(),
  
        material: groundMaterial,
  
    });
  
    // 改变平面默认的方向，法线默认沿着z轴，旋转到平面向上朝着y方向
  
    groundBody.quaternion.setFromEuler(-Math.PI / 2, 0, 0);//旋转规律类似threejs 平面
  
    world.addBody(groundBody)
  
  
  
    //设置物理世界参数
  
    const contactMaterial = new CANNON.ContactMaterial(groundMaterial, sphereMaterial, {
  
        restitution: 0.5, //反弹恢复系数
  
    })
  
    // 把关联的材质添加到物理世界中
  
    world.addContactMaterial(contactMaterial)
  
  
  
  
  
    // 网格地面
  
    const planeGeometry = new THREE.PlaneGeometry(1000, 1000);
  
    const texture = new THREE.TextureLoader().load('./assets/textures/hardwood2_diffuse.jpg');
  
    texture.wrapS = THREE.RepeatWrapping;
  
    texture.wrapT = THREE.RepeatWrapping;
  
    texture.repeat.set(10, 10);
  
    const planeMaterial = new THREE.MeshLambertMaterial({
  
        // color:0x777777,
  
        map: texture,
  
    });
  
    const planeMesh = new THREE.Mesh(planeGeometry, planeMaterial);
  
    planeMesh.rotateX(-Math.PI / 2);
  
    scene.add(planeMesh);
  
  

  
  

创建好模型后，我们在创建光源，相机等，这里就不再赘述。接下来我们开始设计物理世界的骰子抛出后坠落效果，并将物理世界和webgl渲染同步。

    //点击屏幕后，设置物理骰子的角度和速度，物理会向上抛出并随着重力下落，触碰到地面后则会发生碰撞反弹

    renderer.domElement.addEventListener('click', function (event) {

        start_throw = true;

        clearPoints();

        const randomEuler = Math.random()*3;

        bodyModel.quaternion.setFromEuler(Math.PI / randomEuler, Math.PI / randomEuler, Math.PI / randomEuler);

        bodyModel.position.set(0,50,0);//点击按钮，body回到下落的初始位置

        // 为物体设置初始速度（用以产生抛物线效果）

        bodyModel.velocity.set(option.x,option.y,option.z); // x, y, z 方向上的速度

        // 选中模型的第一个模型，开始下落

        world.addBody(bodyModel);

    })

    

    function render() {

        world.step(1/60);//更新物理计算

        meshModel.position.copy(bodyModel.position);  //渲染循环中，同步物理球body与网格球mesh的位置

        meshModel.quaternion.copy(bodyModel.quaternion);   //同步姿态角度

        locateView();   //相机跟随物体移动

        requestAnimationFrame(render);

        renderer.render(scene, camera);

        if (isBodyStopped(bodyModel)&&start_throw) {

            showPoints();   //停止运动后，显示点数

            start_throw = false;

        }

    }

    render();//根据帧数渲染

    

接下来，我们再添加骰子点数计算相关逻辑。

//获取朝上面的点数

function getUpperFace(mesh) {

    // 定义每个面的局部法线向量（手动定义）

    const localNormals = [

        new THREE.Vector3(0, 1, 0),  // 面1

        new THREE.Vector3(0, 0, -1),  // 面2

        new THREE.Vector3(-1, 0, 0), // 面3

        new THREE.Vector3(1, 0, 0),  // 面4

        new THREE.Vector3(0, 0, 1),  // 面5

        new THREE.Vector3(0, -1, 0), // 面6

    ];

    

    let maxDot = -Infinity;

    let faceValue = 0;

    for (let i = 0; i < localNormals.length; i++) {

        // 将局部法线向量转化为世界空间

        const worldNormal = localNormals[i].clone().applyQuaternion(mesh.quaternion);

    

        // 与全局上方向的点积

        const dot = worldNormal.dot(new THREE.Vector3(0, 1, 0));

    

        // 检查点积，找到最大值

        if (dot > maxDot) {

            maxDot = dot;

            faceValue = i + 1; // 面的点数即为索引加1

        }

    }

    

    return faceValue;

}

//判断物体是否停止运动

function isBodyStopped(body, linearVelocityThreshold = 0.1, angularVelocityThreshold = 0.1) {

    // 获取物体的线性速度和角速度

    const linearVelocityMagnitude = body.velocity.length();

    const angularVelocityMagnitude = body.angularVelocity.length();



    // 判断速度是否低于设定的阈值

    return linearVelocityMagnitude < linearVelocityThreshold && angularVelocityMagnitude < angularVelocityThreshold;

}

//展示点数

function showPoints() {

    let res = getUpperFace(meshModel);

    let point = document.getElementById("points");

    point.innerHTML = `点数：${res}`

}

//清空点数

function clearPoints() {

    let point = document.getElementById("points");

    point.innerHTML = ``

}

实现这些逻辑后，我们已经可以模拟出骰子抛出坠落并触碰地面后反弹，在停止运动后计算点数的效果。已经实现基础功能，但是我们发现如果随机速度过大的时候会移动很远才停下，于是我们增加一个空气墙来限制骰子在固定范围内。并且增加一个碰撞检测来触发撞地声音的效果。

//添加空气墙

const wallShape = new CANNON.Box(new CANNON.Vec3(100, 100, 0.1));

    

const wall1 = new CANNON.Body({ mass: 0 });

wall1.addShape(wallShape);

wall1.position.set(0, 100, -100); // Back wall

world.addBody(wall1);



const wall2 = new CANNON.Body({ mass: 0 });

wall2.addShape(wallShape);

wall2.position.set(0, 100, 100); // Front wall

world.addBody(wall2);



const wall3 = new CANNON.Body({ mass: 0 });

wall3.addShape(wallShape);

wall3.quaternion.setFromEuler(0, Math.PI / 2, 0); // Rotate for side walls

wall3.position.set(100, 100, 0); // Right wall

world.addBody(wall3);



const wall4 = new CANNON.Body({ mass: 0 });

wall4.addShape(wallShape);

wall4.quaternion.setFromEuler(0, Math.PI / 2, 0); // Rotate for side walls

wall4.position.set(-100, 100, 0); // Left wall

world.addBody(wall4);



//监听物体碰撞回调

const audio = new Audio('./assets/audio/peng.mp3');

bodyModel.addEventListener('collide', (event) => {

    const contact = event.contact;

    //获得沿法线的冲击速度

    const ImpactV = contact.getImpactVelocityAlongNormal();

    // 碰撞越狠，声音越大

    if(ImpactV/35>1) {

        audio.volume = 1;

    } else {

        audio.volume = ImpactV/35>0?ImpactV/35:0;

    }

    audio.currentTime = 0;

    audio.play();

})

这样我们就初步完成了抛掷一个骰子并获取点数的功能，看似简单的一个场景实际上设计起来并不容易，要考虑很多因素。后续我会继续增加多个骰子同时抛掷的场景，以及比赛模式。源码也会贡献出来供大家一起学习参考，如果有更好的idea也可以在评论区留言或私信，大家一起在webgl中感受物理世界的魅力！

• 效果展示：codesandbox.io/p/github/lu…


• 源码地址：github.com/lukeSuperCo…

附完整代码：

import * as CANNON from "cannon-es";

import * as THREE from 'three';

import { OrbitControls } from 'three/addons/controls/OrbitControls.js';

import { GLTFLoader } from 'three/addons/loaders/GLTFLoader.js';

import { GUI } from 'three/addons/libs/lil-gui.module.min.js';





const scene = new THREE.Scene();

const camera = new THREE.PerspectiveCamera(75, window.innerWidth / window.innerHeight, 0.1, 1000);

const renderer = new THREE.WebGLRenderer();

renderer.setSize(window.innerWidth, window.innerHeight);

document.body.appendChild(renderer.domElement);



// 实例化一个gui对象

// const gui = new GUI();

// //改变交互界面style属性

// gui.domElement.style.right = '0px';

// gui.domElement.style.width = '300px';



const option = {

    z: -24,

    x: -36,

    y: -17,

    z1: 1,

    x1: 1,

    y1: 1,

}

// //gui控制参数

// const folder_position = gui.addFolder('速度方向');

// folder_position.add(option, 'z', -100, 100);

// folder_position.add(option, 'x', -100, 100);

// folder_position.add(option, 'y', -100, 100);

// const folder_rotation = gui.addFolder('角度');

// folder_rotation.add(option, 'z1', -10, 10).step(0.1);

// folder_rotation.add(option, 'x1', -10, 10).step(0.1);

// folder_rotation.add(option, 'y1', -10, 10).step(0.1);



// CANNON.World创建物理世界对象

const world = new CANNON.World();

// 设置物理世界重力加速度

// world.gravity.set(0, -1000, 0); //重力加速度： 单位：m/s²

world.gravity.set(0, -100, 0);









//网格球体（gltf模型）

const loader = new GLTFLoader();

const gltf = await loader.loadAsync('./assets/model/dice_model.glb');



const meshModel = gltf.scene;//获取箱子网格模型

meshModel.position.set(50,30,50);

meshModel.scale.set(5,5,5);

scene.add(meshModel);



//包围盒计算

const box3 = new THREE.Box3();

box3.expandByObject(meshModel);//计算模型包围盒

const size = new THREE.Vector3();

box3.getSize(size);//包围盒计算箱子的尺寸



// 物理球体

const sphereMaterial = new CANNON.Material()//碰撞体材质

// 物理箱子

const bodyModel = new CANNON.Body({

    mass: 0.3, // 碰撞体质量0.3kg

    position: new CANNON.Vec3(50,30,50), // 位置

    shape: new CANNON.Box(new CANNON.Vec3(size.x/2, size.y/2, size.z/2)),

    material: sphereMaterial

});



// 骨骼辅助显示

const skeletonHelper = new THREE.SkeletonHelper(meshModel);

scene.add(skeletonHelper);



// world.addBody(bodyModel);



//添加空气墙

// Create air walls

const wallShape = new CANNON.Box(new CANNON.Vec3(100, 100, 0.1));

    

const wall1 = new CANNON.Body({ mass: 0 });

wall1.addShape(wallShape);

wall1.position.set(0, 100, -100); // Back wall

world.addBody(wall1);



const wall2 = new CANNON.Body({ mass: 0 });

wall2.addShape(wallShape);

wall2.position.set(0, 100, 100); // Front wall

world.addBody(wall2);



const wall3 = new CANNON.Body({ mass: 0 });

wall3.addShape(wallShape);

wall3.quaternion.setFromEuler(0, Math.PI / 2, 0); // Rotate for side walls

wall3.position.set(100, 100, 0); // Right wall

world.addBody(wall3);



const wall4 = new CANNON.Body({ mass: 0 });

wall4.addShape(wallShape);

wall4.quaternion.setFromEuler(0, Math.PI / 2, 0); // Rotate for side walls

wall4.position.set(-100, 100, 0); // Left wall

world.addBody(wall4);



camera.position.set(42,85,21)

camera.lookAt(0,10,0);



// 物理地面

const groundMaterial = new CANNON.Material()

const groundBody = new CANNON.Body({

    mass: 0, // 质量为0，始终保持静止，不会受到力碰撞或加速度影响

    shape: new CANNON.Plane(),

    material: groundMaterial,

});

// 改变平面默认的方向，法线默认沿着z轴，旋转到平面向上朝着y方向

groundBody.quaternion.setFromEuler(-Math.PI / 2, 0, 0);//旋转规律类似threejs 平面

world.addBody(groundBody)



//设置物理世界参数

const contactMaterial = new CANNON.ContactMaterial(groundMaterial, sphereMaterial, {

    restitution: 0.5, //反弹恢复系数

})

// 把关联的材质添加到物理世界中

world.addContactMaterial(contactMaterial)



//光源设置

const directionalLight = new THREE.DirectionalLight(0xffffff, 2);

directionalLight.position.set(20, 100, 10);

scene.add(directionalLight);





// 网格地面

const planeGeometry = new THREE.PlaneGeometry(1000, 1000);

const texture = new THREE.TextureLoader().load('./assets/textures/hardwood2_diffuse.jpg');

texture.wrapS = THREE.RepeatWrapping;

texture.wrapT = THREE.RepeatWrapping;

texture.repeat.set(10, 10);

const planeMaterial = new THREE.MeshLambertMaterial({

    // color:0x777777,

    map: texture,

});

const planeMesh = new THREE.Mesh(planeGeometry, planeMaterial);

planeMesh.rotateX(-Math.PI / 2);

scene.add(planeMesh);



// 添加一个辅助网格地面

// const gridHelper = new THREE.GridHelper(50, 50, 0x004444, 0x004444);

// scene.add(gridHelper);





var controls = new OrbitControls(camera, renderer.domElement);

controls.enableDamping = true; // 允许阻尼效果

controls.dampingFactor = 0.25; // 阻尼系数



let start_throw = false;

renderer.domElement.addEventListener('click', function (event) {

    start_throw = true;

    clearPoints();

    const randomEuler = Math.random()*3;

    bodyModel.quaternion.setFromEuler(Math.PI / randomEuler, Math.PI / randomEuler, Math.PI / randomEuler);

    bodyModel.position.set(0,50,0);//点击按钮，body回到下落的初始位置

    // 为物体设置初始速度（用以产生抛物线效果）

    bodyModel.velocity.set(option.x,option.y,option.z); // x, y, z 方向上的速度

    // 选中模型的第一个模型，开始下落

    world.addBody(bodyModel);

})

const audio = new Audio('./assets/audio/peng.mp3');

bodyModel.addEventListener('collide', (event) => {

    const contact = event.contact;

    //获得沿法线的冲击速度

    const ImpactV = contact.getImpactVelocityAlongNormal();

    // 碰撞越狠，声音越大

    if(ImpactV/35>1) {

        audio.volume = 1;

    } else {

        audio.volume = ImpactV/35>0?ImpactV/35:0;

    }

    audio.currentTime = 0;

    audio.play();

})



//判断物体是否停止运动

function isBodyStopped(body, linearVelocityThreshold = 0.1, angularVelocityThreshold = 0.1) {

    // 获取物体的线性速度和角速度

    const linearVelocityMagnitude = body.velocity.length();

    const angularVelocityMagnitude = body.angularVelocity.length();



    // 判断速度是否低于设定的阈值

    return linearVelocityMagnitude < linearVelocityThreshold && angularVelocityMagnitude < angularVelocityThreshold;

}



function showPoints() {

    let res = getUpperFace(meshModel);

    let point = document.getElementById("points");

    point.innerHTML = `点数：${res}`

}



//相机跟随物体移动

function locateView() {

    camera.position.x = meshModel.position.x;

    camera.position.y = meshModel.position.y + 30;

    camera.position.z = meshModel.position.z + 20;

    camera.lookAt(meshModel.position)

}



function clearPoints() {

    let point = document.getElementById("points");

    point.innerHTML = ``

}

//获取朝上面的点数

function getUpperFace(mesh) {

    // 定义每个面的局部法线向量（手动定义）

    const localNormals = [

        new THREE.Vector3(0, 1, 0),  // 面1

        new THREE.Vector3(0, 0, -1),  // 面2

        new THREE.Vector3(-1, 0, 0), // 面3

        new THREE.Vector3(1, 0, 0),  // 面4

        new THREE.Vector3(0, 0, 1),  // 面5

        new THREE.Vector3(0, -1, 0), // 面6

    ];

    

    let maxDot = -Infinity;

    let faceValue = 0;

    for (let i = 0; i < localNormals.length; i++) {

        // 将局部法线向量转化为世界空间

        const worldNormal = localNormals[i].clone().applyQuaternion(mesh.quaternion);

    

        // 与全局上方向的点积

        const dot = worldNormal.dot(new THREE.Vector3(0, 1, 0));

    

        // 检查点积，找到最大值

        if (dot > maxDot) {

            maxDot = dot;

            faceValue = i + 1; // 面的点数即为索引加1

        }

    }

    

    return faceValue;

}

function render() {

    world.step(1/60);//更新物理计算

    meshModel.position.copy(bodyModel.position);  //渲染循环中，同步物理球body与网格球mesh的位置

    meshModel.quaternion.copy(bodyModel.quaternion);   //同步姿态角度

    locateView();   //相机跟随物体移动

    requestAnimationFrame(render);

    renderer.render(scene, camera);

    if (isBodyStopped(bodyModel)&&start_throw) {

        showPoints();   //停止运动后，显示点数

        start_throw = false;

    }

}

render();

因为工作的原因，我和一些外国前端开发有些交流。他们对于国内环境不了解，有时候会问出一些有趣的问题，大概是这些问题的启发，让我反复在思考一些更为深入的问题。

今天聊三个事情：

• 小程序
• 微前端
• 模块加载

小程序

每个行业都有一把银座，当坐上那把银座时，做什么便都是对的。

“我们为什么需要小程序？”

第一次被问到这个问题，是因为一个法国的同事。他被派去做一个移动端业务，刚好那个业务是采用小程序在做。于是一个法国小哥就在被痛苦的中文文档和黑盒逻辑中来回折磨着 🤦。

于是，当我们在有一次交流中，他问出了我这个问题：我们为什么需要小程序？

说实话，我试图解释了 19 年国内的现状，以及微信小程序推出时候所带来的便利和体验等等。总之，在我看来并不够深刻的见解。

即便到现在为止，每次当我使用小程序的时候，依旧会复现这个问题。在 ChatGPT 11 月份出来的时候，我也问了它这个很有国内特色的问题：

看起来它回答的还算不错，至少我想如果它来糊弄那些老外，应该会比我做的更好些。

但如果扪心自问，单从技术上来讲。以上这些事情，一定是有其他方案能解决的。

所以从某种程度上来看，这更像是一场截胡的商业案例：

应用市场

全世界的互联网人都知道应用市场是非常有价值的事情，可以说操作系统最值钱的部分就在于他们构建了自己的应用市场。

只要应用在这里注册发行，雁过拔毛，这家公司就是互联网世界里的统治阶级，规则的制定者。

反之则需要受制于人，APP 做的再大，也只是应用市场里的一个应用，做的好与坏还得让应用商店的评判。

另外，不得不承认的是，一个庞大如苹果谷歌这样的公司，他们的应用商店对于普通国内开发者来说，确实是有门槛的。

在国内海量的 APP 需求来临之前，能否提供一个更低成本的解决方案，来消化这些公司的投资？

毕竟不是所有的小企业都需要 APP，其实他们大部分需求 Web 就可以解决，但是 Web 没牌面啊，做 Web 还得砸搜索的钱才有流量。(某度搜索又做成那样...)

那做操作系统？太不容易，那么多人都溺死在水里了，这水太深。

那有没有一种办法可以既能构建生态，又有 APP 的心智，还能给入驻企业提供流量？

于是，在 19 年夏天，滨海大厦下的软件展业基地里，每天都在轮番播放着，做 XX小程序，拥抱下一个风口...

全新体验心智

小程序用起来挺方便的。

你有没有想过，这些美妙感觉的具体都来自哪些？以及这些真的是 Web 技术本身无法提供的吗？

1. 靠谱感，每个小程序都有约束和规范，于是你可以将他们整整齐齐的陈放在你的列表里，仿佛你已经拥有了这一个个精心雕琢的作品，相对于一条条记不住的网页地址和鱼龙混杂的网页内容来说，这让你觉得小程序更加的有分量和靠谱。
2. 安全感，沉浸式的头部，没有一闪而过的加载条，这一切无打扰的设计，都让你觉得这是一个在你本地的 APP，而不是随时可能丢失网页。你不会因为网速白屏而感到焦虑，尽管网络差的时候，你的 KFC 依旧下不了单 😂
3. 沉浸感，我不知道是否打开网页时顶部黑黑的状态栏是故意留下的，还是不小心的... 这些限制都让用户非常强烈的意识到这是一个网页而不是 APP，而小程序中虽然上面也存在一个空间的空白，但是却可以被更加沉浸的主题色和氛围图替代。网页这个需求做不了？我不信。

H5	小程序

4. 顺滑感，得益于 Native 的容器实现，小程序在所有的视图切换时，都可以表现出于原生应用一样的顺滑感。其实这个问题才是在很多 Hybrid 应用中，主要想借助客户端来处理和解决的问题。类似容器预开、容器切换等技术是可以解决相关问题的，只是还没有一个标准。

我这里没有提性能，说实话我不认为性能在小程序中是有优势的（Native 调用除外，如地图等，不是一个讨论范畴）。作为普通用户，我们感受到的只是离线加载下带来的顺滑而已。

而上述提到的许多优势，这对于一个高品质的 Web 应用来说是可以做得到的，但注意这里是高品质的 Web 应用。而这种“高品质”在小程序这里，只是入驻门槛而已。

心智，这个词，听起来很黑话，但却很恰当。当小程序通过长期这样的筛选，所沉淀出来一批这样品质的应用时。就会让每个用户即便在还没打开一个新的小程序之前，也有不错体验的心理预期。这就是心智，一种感觉跟 Web 不一样，跟 APP 有点像的心智。

打造心智，这件事情好像就是国内互联网企业最擅长做的事情，总是能从一些细微的差别中开辟一条独立的领域，然后不断强化灌输本来就不大的差异，等流量起来再去捞钱变现。

我总是感觉现在的互利网充斥着如何赚钱的想法，好像永远赚不够。“赚钱”这个事情，在这些公司眼里就是圈人圈地抢资源，看看谁先占得先机，别人有的我也得有，这好像是最重要的事情。

很少有企业在思考如何创造些没有的市场，创造些真正对技术发展有贡献，对社会发展有推动作用的事情。所以在国内互联网圈也充斥着一种奇怪的价值观，有技术的不一定比赚过钱的受待见。

管你是 PHP 还是 GO，管你是在做游戏还是直播带货，只要赚到钱就是高人。并且端的是理所应当、理直气壮，有些老板甚至把拍摄满屋子的程序员为自己打工作为一种乐趣。什么情怀、什么优雅、什么愿景，人生就俩字：搞钱。

不是故意高雅，赚钱这件事情本身不寒碜，只是在已经赚到盆满钵满、一家独大的时候还在只是想着赚更多的钱，好像赚钱的目的就是为了赚钱一样，这就有点不合适。企业到一定程度是要有社会责任的，龙头企业每一个决定和举措，都有会影响接下来的几年里这个行业的价值观走向。

当然也不是完全没有好格局的企业，我非常珍惜每一个值得尊重的中国企业，来自一个蔚来车主。

小程序在商业上固然是成功的，但吃的红利可以说还是来自 网页 到 应用 的心智变革。将本来流向 APP 的红利，截在了小程序生态里。

但对于技术生态的发展却是带来了无数条新的岔路，小程序的玩法就决定了它必须生长在某个巨型应用里面，不论是用户数据获取、还是 API 的调用，其实都是取决于应用容器的标准规范。

不同公司和应用之间则必然会产生差异，并且这种差异是墒增式的差异，只会随着时间的推移越变越大。如果每个企业都只关注到自己业务的增长，无外部约束的话，企业必然会根据自己的业务发展和政策需要，选择成本较低的调整 API，甚至会故意制造一些壁垒来增加这种差异。

小程序，应该是 浏览器 与 操作系统 的融合，这本应该是推动这两项技术操刀解决的事情。

微前端

qiankun、wujie、single-spa 是近两年火遍前端的技术方案，同样一个问题：我们为什么需要微前端？

我不确定是否每个在使用这项技术的前端都想清楚了这个问题，但至少在我面试过的候选人中，我很少遇到对自己项目中已经在使用的微前端，有很深的思考和理解的人。

先说下我的看法：

没有万能银弹

银色子弹（英文：Silver Bullet），或者称“银弹”“银质子弹”，指由纯银质或镀银的子弹。在欧洲民间传说及19世纪以来哥特小说风潮的影响下，银色子弹往往被描绘成具有驱魔功效的武器，是针对狼人、吸血鬼等超自然怪物的特效武器。后来也被比喻为具有极端有效性的解决方法，作为杀手锏、最强杀招、王牌等的代称。

所有技术的发展都是建立在前一项技术的基础之上，但技术依赖的选择过程中一定需要保留第一性原理的意识。

当 React、Vue 兴起，当 打包技术(Webpack) 兴起，当 网页应用(SPA) 兴起，这些杰出的技术突破都在不同场景和领域中给行业提供了新的思路、新的方案。

不知从何时开始，前端除了 div 竟说不出其他的标签(还有说 View 的)，项目中再也不会考虑给一个通用的 class 解决通用样式问题。

不知从何时开始，有没有权限需要等到 API 请求过后才知道，没有权限的话再把页面跳转过去申请。

不知从何时开始，大家的页面都放在了一个项目里，两个这样的巨石应用融合竟然变成了一件困难的事。

上面这些不合理的现状，都是在不同的场景下，不思考适不适合，单一信奉 “一招吃遍天” 下演化出的问题。

B 端应用，是否应该使用 SPA？ 这其实是一个需要思考的问题。

微前端从某种程度上来讲，是认准 SPA 了必须是互联网下一代应用标准的产物，好像有了 SPA 以后，MPA 就变得一文不值。甭管页面是移动端的还是PC的；甭管页面是面对 C 端的还是 B 端的；甭管一个系统是有 20 个页面还是 200 个页面，一律行这套逻辑。

SPA 不是万能银弹，React 不是万能银弹，Tailwind 不是万能银弹。在新技术出现的时候，保持热情也要保持克制。

ps. 我也十分痛恨 React 带来的这种垄断式的生态，一个 React 组件将 HTML 和 Style 都吃进去，让你即使在做一个移动端的纯展示页面时，也需要背上这些称重的负担。

质疑 “墨守成规”，打开视野，深度把玩，理性消费。

分而治之

分治法，一个很基本的工程思维。

在我看来在一个正常商业迭代项目中的主要维护者，最好不要超过 3 个人，注意是主要维护者(Maintainer) 。

你应该让每个项目都有清晰的责任人，而不是某行代码，某个模块。责任人的理解是有归属感，有边界感的那种，不是口头意义上的责任人。(一些公司喜欢搞这种虚头巴脑的事情，什么连坐…)

我想大部分想引入微前端的需求都是类似 如何更好的划分项目边界，同时保留更好的团队协同。

比如 导航菜单 应该是独立收口独立管理的，并且当其更新时，应该同时应用于所有页面中。类似的还有 环境变量、时区、主题、监控及埋点。微前端将这些归纳在主应用中。

而具体的页面内容，则由对应的业务进行开发子应用，最后想办法将路由关系注册进主应用即可。

当然这样纯前端的应用切换，还会出现不同应用之间的全局变量差异、样式污染等问题，需要提供完善的沙箱容器、隔离环境、应用之间通信等一系列问题，这里不展开。

当微前端做到这一部分的时候，我不禁在想，这好像是在用 JavaScript 实现一个浏览器的运行容器。这种本应该浏览器本身该做的事情，难道 JS 可以做的更好？

只是做到更好的项目拆分，组织协同的话，引入后端服务，由后端管控路由表和页面规则，将页面直接做成 MPA，这个方案或许并不比引入微前端成本高多少。

体验差异

从 SPA 再回 MPA，说了半天不又回去了么。

所以不防想想：在 B端 业务中使用 SPA 的优势在哪里？

流畅的用户体验：

这个话题其实涵盖范围很广，对于 SPA 能带来的 “流畅体验”，对于大多数情况下是指：导航菜单不变，内容变化 发生变化，页面切换中间不出现白屏。

但要做到这个点，其实对于 MPA 其实并没有那么困难，你只需要保证你的 FCP 在 500ms 以内就行。

以上的页面切换全部都是 MPA 的多页面切换，我们只是简单做了导航菜单的 拆分 和 SWR，并没有什么特殊的 preload、prefetch 处理，就得到了这样的效果。

因为浏览器本身在页面切换时会在 unload 之前先 hold 当前页面的视图不变，发起一下一个 document 的请求，当页面的视图渲染做到足够快和界面结构稳定就可以得到这样的效果。

这项浏览器的优化手段我找了很久，想找一篇关于它的博文介绍，但确实没找到相关内容，所以 500ms 也是我的一个大致测算，如果你知道相关的内容，可以在评论区补充，不胜感激。

所以从这个角度来看，浏览器本身就在尽最大的努力做这些优化，并且他们的优化会更底层、更有效的。

离线访问 (PWA)

SPA 确实会有更好的 PWA 组织能力，一个完整的 SPA 应用甚至可以只针对编译层做改动就可以支持 PWA 能力。

但如果看微前端下的 SPA 应用，需要支持 PWA 那就同样需要分析各子应用之间的元数据，定制 Service Worker。这种组织关系和定制 SW，对于元数据对于数据是来自前端还是后端，并不在意。

也就是说微前端模式下的 PWA，同样的投入成本，把页面都管理在后端服务中的 MPA 应用也是可以做到相同效果的。

项目协同、代码复用

有人说 SPA 项目下，项目中的组件、代码片段是可以相互之间复用的，在 MPA 下就相对麻烦。

这其实涉及到项目划分的领域，还是要看具体的需求也业务复杂度来定。如果说整个系统就是二三十个页面，这做成 SPA 使用前端接管路由高效简单，无可厚非。

但如果你本身在面对的是一个服务于复杂业务的 B 端系统，比如类似 阿里云、教务系统、ERP 系统或者一些大型内部系统，这种往往需要多团队合作开发。这种时候就需要跟完善的项目划分、组织协同和系统整合的方案。

这个时候 SPA 所体现出的优势在这样的诉求下就会相对较弱，在同等投入的情况下 MPA 的方案反而会有更少的执行成本。

也不是所有项目一开始就会想的那么清楚，或许一开始的时候就是个简单的 SPA 项目，但是随着项目的不断迭代，才变成了一个个复杂的巨石应用，现在如果再拆出来也会有许多迁移成本。引入微前端，则可以...

这大概是许多微前端项目启动的背景介绍，我想说的是：对于屎山，我从来不信奉“四两拨千斤”。

如果没有想好当下的核心问题，就引入新的“银弹”解决问题，只会是屎山雕花。

项目协同，抽象和复用这些本身不是微前端该解决的问题，这是综合因素影响下的历史背景问题。也是需要一个个资深工程师来把控和解决的核心问题，就是需要面对不同的场景给出不同的治理方案。

这个道理跟防沙治沙一样，哪有那么多一蹴而就、立竿见影的好事。

模块加载

模块加载这件事情，从玉伯大佬的成名作 sea.js 开始就是一个非常值得探讨的问题。在当时 jQuery 的时代里，这是一个绝对超前的项目，我也在实际业务中体会过在无编译的环境下 sea.js 的便捷。

实际上，不论是微前端、低代码、会场搭建等热门话题离不开这项技术基础。

import * from * 我们每天都在用，但最终的产物往往是一个自运行的 JS Bundle，这来自于 Webpack、Vite 等编译技术的发展。让我们可以更好的组织项目结构，以构建更复杂的前端应用。

模块的概念用久了，就会自然而然的在遇到浏览器环境中，遇到动态模块加载的需求时，想到这种类似模块加载的能力。

比如在遇到会场千奇百怪的个性化营销需求时，能否将模块的 Props 开放出来，给到非技术人员，以更加灵活的方式让他们去做自由组合。

比如在低代码平台中，让开发者自定义扩展组件，动态的将开发好的组件注册进低代码平台中，以支持更加个性的需求。

在万物皆组件的思想影响下，把一整个完整页面都看做一个组件也不是不可以。于是在一些团队中，甚至提倡所有页面都可以搭建、搭建不了的就做一个大的页面组件。这样及可以减少维护运行时的成本，又可以统一管控和优化，岂不美哉。

当这样大一统的“天才方案”逐渐发展成为标准后，也一定会出现一些特殊场景无法使用，但没关系，这些天才设计者肯定会提供一种更加天才的扩展方案出来。比如插件，比如扩展，比如 IF ELSE。再后来，就会有性能优化了，而优化的 追赶对象 就是用原来那种简单直出的方案。

有没有发现，这好像是在轮回式的做着自己出的数学题，一道接一道，仿佛将 1 + 1的结论重新演化了一遍。

题外话，我曾经自己实现过一套通过 JSON Schema 描述 React 结构的 “库” ，用于一个低代码核心层的渲染。在我的实现过程中，我越发觉得我在做一件把 JSX 翻译成 JS 的事情，但 JSX 或者 HTML 本身不就是一种 DSL 么。为什么一定要把它翻译成 JSON 来传输呢？或者说这样的封装其本身有意义么？这不就是在做 PHP、.Net 直接返回带有数据的 HTML Ajax 一样的事情么。

传统的浏览器运行环境下要实现一个模块加载器，无非是在全局挂载一个注册器，通过 Script 插入一段新的 JS，该 JS 通过特殊的头尾协议，将运行时的代码声明成一个函数，注册进事先挂载好的注册器。

但实际的实现场景往往要比这复杂的多，也有一些问题是这种非原生方式无法攻克的问题。比如全局注册器的命名冲突；同模块不同版本的加载冲突；并发加载下的时序问题；多次模块加载的缓存问题 等等等等等...

到最后发现，这些事情好像又是在用 JS 做浏览器该做的事情。然而浏览器果然就做了，，Vite 就主要采用这种模式实现了它 1 年之内让各大知名项目切换到 Vite 的壮举。

“但我们用不了，有兼容性问题。”

哇哦，当我看着大家随意写出的 display: grid 样式定义，不禁再次感叹人们对未知的恐惧。

import.meta 的兼容性是另外一个版本，是需要 iOS12 以上，详情参考：caniuse.com/?search=imp…

试想一下，现在的低代码、会场搭建等等各类场景的模块加载部分，如果都直接采用 ESM 的形式处理，这对于整个前端生态和开发体验来说会有多么大的提升。

模块加载，时至今日，本来就已经不再需要 loader。 正如 seajs 中写的：前端模块化开发那点历史

历史不是过去，历史正在上演。随着 W3C 等规范、以及浏览器的飞速发展，前端的模块化开发会逐步成为基础设施。一切终究都会成为历史，未来会更好。

结语

文章的结尾，我想感叹另外一件事，国人为什么一定要有自己的操作系统？为什么一定需要参与到一些规范的制定中？

因为我们的智慧需要有开花的土壤，国内这千千万开发者的抱负需要有地方释放。

如果没有自己掌握核心技术，就是只能在问题出现的时候用另类的方式来解决。最后在一番折腾后，发现更底层的技术只要稍稍一改就可以实现的更好。这就像三体中提到的 “智子” 一样，不断在影响着我们前进的动力和方向。

不论是小程序、微前端还是模块加载。试想一下，如果我们有自己的互联网底蕴，能决定或者影响操作系统和浏览器的底层能力。这些 “怪啖” 要么不会出现，要么就是人类的科技创新。

希望未来技术人不用再追逐 Write Once, Run Everywhere 的事情...

最近逛github的时候发现了一个非常好用的轻量工具库，Fuse.js，支持模糊搜索。感觉还是非常好用的，所以有了此篇博客，这篇文章主要是介绍Fuse的使用，同样，我对这个开源项目的实现也非常感兴趣。后续会出一篇Fuse源码解析的文章来分析其实现原理。

Fuse.js是什么？

强大、轻量级的模糊搜索库，没有任何依赖关系。

什么是模糊搜索？

一般来说，模糊搜索（更正式的名称是近似字符串匹配）是查找与给定模式近似相等（而不是完全相等）的字符串的技术。

通常我们项目中的的模糊搜索大多数情况下有几种方案可用：

• 前端工程通过正则表达式或者字符串匹配来实现


• 调用后端接口去匹配搜索


• 使用搜索引擎如：ElasticSearch或Algolia等

但是这些方案都有各自的缺陷，比如正则表达式和字符串匹配的效率较低，且无法处理复杂的搜索需求，而调用后端接口和搜索引擎虽然效率高，但是需要额外的服务器资源，且需要维护一套搜索引擎。

所以，Fuse.js的出现就是为了解决这些问题，它是一个轻量级的模糊搜索库，没有依赖关系，支持复杂的搜索需求，且效率高，当然Fuse并不适用于所有场景。

Fuse.js的使用场景

它可能不适用于所有情况，但根据您的搜索要求，它可能是最理想的。例如：

• 当您想要对小型到中等大型数据集进行客户端模糊搜索时


• 当您无法证明设置专用后端只是为了处理搜索时


• ElasticSearch 或 Algolia 虽然都是很棒的服务，但对于您的特定用例来说可能有些过度

Fuse.js的使用

安装

Fuse支持多种安装方式

NPM

npm install fuse.js

Yarn

yarn add fuse.js

CDN 引入

<script src="https://cdn.jsdelivr.net/npm/fuse.js@7.0.0">script>

引入

ES6 模块语法

import Fuse from 'fuse.js'

CommonJS 语法

const Fuse = require('fuse.js')

Tips: 使用npm或者yarn引入，支持两种模块语法引入，如果是使用cdn引入，那么Fuse将被注册为全局变量。直接使用即可

使用

以下是官网一个最简单的例子，只要简单的构造new Fuse对象，就能模糊搜索匹配到你想要的结果

// 1. List of items to search in

const books = [

  {

    title: "Old Man's War",

    author: {

      firstName: 'John',

      lastName: 'Scalzi'

    }

  },

  {

    title: 'The Lock Artist',

    author: {

      firstName: 'Steve',

      lastName: 'Hamilton'

    }

  }

]



// 2. Set up the Fuse instance

const fuse = new Fuse(books, {

  keys: ['title', 'author.firstName']

})



// 3. Now search!

fuse.search('jon')



// Output:

// [

//   {

//     item: {

//       title: "Old Man's War",

//       author: {

//         firstName: 'John',

//         lastName: 'Scalzi'

//       }

//     },

//     refIndex: 0

//   }

// ]

从上述代码中可以看到我们要通过Fuse 对books的这个数组进行模糊搜索，构建的Fuse对象中，模糊搜索的key定义为['title', 'author.firstName']，支持对title及author.firstName这两个字段进行搜索。然后执行fuse的search API就能过滤出我们的期望结果。整体代码还是非常简单的。

高级配置

Demo示例只是提供了一个基础版本的模糊搜索。如果用户想获得更灵活的搜索能力，比如搜索结果排序、权重控制、搜索结果高亮等，那么就需要对Fuse进行一些高级配置。

Fuse的所有配置都是通过new Fuse时传入的参数来配置的，下面列举一些常用的配置项：

    const options = {

            keys: ['title', 'author'], // 指定搜索key值，可多选

            isCaseSensitive: false, //是否区分大小写 默认为false

            includeScore: false, //结果集中是否展示匹配项的分数字段， 分数越大代表匹配程度越低，区间值为0-1,注意：当此项为true时，会返回完整的结果集，只不过每一项中携带了score分数字段

            includeMatches: false, //匹配项是否应包含在结果中。当时true，结果的每条记录都包含匹配项的索引。这个通常我们用来对搜索内容做高亮处理

            threshold: 0.6, // 阈值控制匹配的敏感度,默认值为0.6，如果要完全匹配这里要设置为0

            shouldSort: true, // 是否对结果进行排序

            location: 0, // 匹配的位置，0 表示开头匹配

            distance: 100, // 搜索的最大距离

            minMatchCharLength: 2, // 最小匹配字符长度

    };

出了上述常用的一些配置项之外，Fuse还支持更高阶模糊搜索，如权重搜索，嵌套搜索，运算符拓展搜索，具体高阶用法可以参考官方文档。
Fuse的主要实现原理是通过改写Bitap 算法(近似字符串匹配)算法的内部实现来支撑其模糊搜索的算法依据，后续会出一篇文章看一下作者源码的算法实现。

总结

Fuse的文章到此就结束了，你没看错就这么一点介绍就基本能支撑我们在项目中的应用，谢谢阅读，如果哪里有不对的地方请评论博主，会及时进行改正。

最近维护了将近的一年的微信小程序（某知名企业），突然提出要兼容折叠屏，这款小程序主要功能一些图表汇总展示，也就是专门给一些领导用的，也不知道为啥领导们为啥突然喜欢用折叠屏手机了，一句话需求，苦的还是咱们程序员，但没办法，谁让甲方是爸爸呢，硬着头皮改吧，好在最后解决了，因为是甲方内部使用的小程序，这里不便贴图，但有官方案例图片，以供参考

查看了微信官网
大屏适配
响应显示区域变化

启用大屏模式

从小程序基础库版本 2.21.3 开始，在 Windows、Mac、车机、安卓 WMPF 等大屏设备上运行的小程序可以支持大屏模式。可参考小程序大屏适配指南。方法是：在 app.json 中添加 "resizable": true

看到这里我心里窃喜，就加个配置完事了？这也太简单了，但后面证明我想简单了，
主要有两大问题：

• 1 尺寸不同的情况下内容展示效果兼容问题


• 2 预览版和体验版 大屏模式冷启动会生效，但热启动 和 菜单中点击重新进入小程、授权操作，会失效变成窄屏

解决尺寸问题

因为css的长度单位大部分用的 rpx，窄屏和宽屏展示差异出入较大，别说客户不认，自己这关就过不了，简直都不忍直视，整个乱成一片，尤其登录页，用了定位，更是乱上加乱。

随后参考了官方的文档 小程序大屏适配指南和自适应布局，方案对于微信小程序原生开发是可行的，但这个项目用的 uni-app开发的，虽然uni-app 也有对应的响应式布局组件，再加上我是个比较爱偷懒的人（甲方给的工期事件也有限制），不可能花大量时间把所有也页面重新写一遍布局，这是不现实的。

于是又转战到uni-app官网寻找解决方案 uni-app宽屏适配指南

内容缩放拉伸的处理 这一段中提出了两个策略

• 1.局部拉伸：页面内容划分为固定区域和长宽动态适配区域，固定区域使用固定的px单位约定宽高，长宽适配区域则使用flex自动适配。当屏幕大小变化时，固定区域不变，而长宽适配区域跟着变化


• 2.等比缩放：根据页面屏幕宽度缩放。rpx其实属于这种类型。在宽屏上，rpx变大，窄屏上rpx变小。

随后看到这句话特别符合我的需求，哈哈 省事 省事 省事

策略2省事，设计师按750px屏宽出图，程序员直接按rpx写代码即可。但策略2的实际效果不如策略1好。程序员使用策略1，分析下界面，设定好局部拉伸区域，这样可以有更好的用户体验

具体实现

1.配置 pages.json 的 globeStyle

{

  "globalStyle": {

    "rpxCalcMaxDeviceWidth": 1200, // rpx 计算所支持的最大设备宽度，单位 px，默认值为 960

    "rpxCalcBaseDeviceWidth": 375, // rpx 计算使用的基准设备宽度，设备实际宽度超出 rpx 计算所支持的最大设备宽度时将按基准宽度计算，单位 px，默认值为 375

    "rpxCalcIncludeWidth": 750 // rpx 计算特殊处理的值，始终按实际的设备宽度计算，单位 rpx，默认值为 750

  },

}

2.单位兼容

还有一点官方也提出来了很重要，那就很多时候 会把宽度750rpx 当成100% 使用，这在宽屏的设备上就会有问题， uniapp给了两种解决方案

• 750rpx 改为100%


• 另一种是配置rpxCalcIncludeWidth，设置某个特定数值不受rpxCalcMaxDeviceWidth约束

想要用局部拉伸：页面内容划分为固定区域和长宽动态适配区域”的策略，单位必须用px

添加脚本

项目根目录新增文件 postcss.config.js 内容如下。则在编译时，编译器会自动转换rpx单位为px。

// postcss.config.js



const path = require('path')

module.exports = {

  parser: 'postcss-comment',

  plugins: {

    'postcss-import': {

      resolve(id, basedir, importOptions) {

        if (id.startsWith('~@/')) {

          return path.resolve(process.env.UNI_INPUT_DIR, id.substr(3))

        } else if (id.startsWith('@/')) {

          return path.resolve(process.env.UNI_INPUT_DIR, id.substr(2))

        } else if (id.startsWith('/') && !id.startsWith('//')) {

          return path.resolve(process.env.UNI_INPUT_DIR, id.substr(1))

        }

        return id

      }

    },

    'autoprefixer': {

      overrideBrowserslist: ["Android >= 4", "ios >= 8"],

      remove: process.env.UNI_PLATFORM !== 'h5'

    },

    // 借助postcss-px-to-viewport插件，实现rpx转px，文档：https://github.com/evrone/postcss-px-to-viewport/blob/master/README_CN.md

    // 以下配置，可以将rpx转换为1/2的px，如20rpx=10px，如果要调整比例，可以调整 viewportWidth 来实现

    'postcss-px-to-viewport': {

      unitToConvert: 'rpx',

      viewportWidth: 200,

      unitPrecision: 5,

      propList: ['*'],

      viewportUnit: 'px',

      fontViewportUnit: 'px',

      selectorBlackList: [],

      minPixelValue: 1,

      mediaQuery: false,

      replace: true,

      exclude: undefined,

      include: undefined,

      landscape: false

    },

    '@dcloudio/vue-cli-plugin-uni/packages/postcss': {}

  }

}

大屏模式失效问题

下面重头戏来了，这期间经历 蜿蜒曲折 ，到头来发现都是无用功，我自己都有被wx蠢到发笑，唉，

样式问题解决后 开始着重钻研 大屏失效的问题，但看了官方的多端适配示例demo，人家的就是好的，那就应该有解决办法，于是转战github地址 下项目，谁知这项目暗藏机关，各种报错，让你跑不起来。。。。，让我一度怀疑腾讯也这么拉跨

还好issues 区一位大神有解决办法 感兴趣的老铁可以去瞅瞅

另外 微信小程序开发工具需要取消这两项，最后当项目跑起来后我还挺开心，模拟器上没有问题，但用真机预览的时候我啥眼了，还是窄屏，偶尔可以大屏，后面发现 冷启动是大屏，热启动和点击右上角菜单中的重新进入小程序按钮都会自己变成窄屏幕

这是官方的项目啊，为啥人家的可以，我本地跑起来却不可以，让我一度怀疑这里有内幕，经过几轮测试还是不行，于是乎，我开始了各种询问查资料，社区、私聊、评论、github issues，最后甚至 统计出来了 多端适配示例demo 开发者的邮箱 挨个发了邮件，但都结果无一例外，全部石沉大海

结果就是，没有办法了，想看看是不是只有预览和体验版有问题，后面发布到正式版后，再看居然没问题了，就是这么神奇，也是无语！！！！ 原来做了这么多无用功。。。。

1. 通用组件（表单搜索+表格展示+分页器）

在项目当中我们总会遇到这样的页面：页面顶部是一个表单筛选项，下面是一个表格展示数据。表格下方是一个分页器，这样的页面在我们的后台管理系统中经常所遇到，有时候可能不止一个页面，好几个页面的结构都是这种。如图：

本人记得，在react中的高级组件库中有这么一个组件，就实现了这么一个效果。就拿这个页面来说我们实现一下组件封装的思想：1.首先把每个页面的公共部分抽出来，比如标题等，用props或者插槽的形式传入到组件中进行展示 2. 可以里面数据的双向绑定实现跟新的效果 3. 设置自定义函数传递给父组件要做上面事情

1.将公共的部分抽离出来

TableContainer组件

<template>

    <div class="container">

      <slot name="navbar"></slot>

      <div class="box-detail">

        <div class="detail-box">

          <div class="box-left">

            <div class="left-bottom">

              <div class="title-bottom">{{ title }}</div>

              <div class="note">  

                <div class="note-detail">

                  <slot name="table"></slot>

                </div>

              </div>

            </div>

          </div>

        </div>

      </div>

      <el-backtop style="width: 3.75rem; height: 3.75rem" :bottom="10" :right="5">

        <div

          style="

             {

              width: 5.75rem;

              flex-shrink: 0;

              border-radius: 2.38rem;

              background: #fff;

              box-shadow: 0 0.19rem 1rem 0 #2b4aff14;

            }

          "

        >

          <i class="el-icon-arrow-up" style="color: #6e6f74"></i>

        </div>

      </el-backtop>

    </div>

  </template>

这里的话利用了具名插槽插入了navbar、table组件，title通过props的属性传入到子组件当中。进行展示，

父组件

    <TableContainer title="资源审核">

        <template v-slot:navbar>

            <my-affix :offset="0">

                <Navbar/>

            </my-affix>

        </template>

        <template v-slot:table>

            <SourceAuditTable/>

        </template>

    </TableContainer>

当然这是一个非常非常简单的组件封装案例

接下来我们看一个高级一点的组件封装

父组件

<template>

  <div>

    <hr>

    <HelloWorld :page.sync="page" :limit.sync="limit" />

  </div>

</template>



<script>

import HelloWorld from './components/HelloWorld.vue';

export default {

  data() {

    return {

      page: 1,

      limit: 5

    }

  },

  components: {

    HelloWorld

  },





}

</script>

父组件传递给子组件各种必要的属性：total（总共多少条数据）、page(当前多少页)、limit（每页多少条数据）、pageSizes（选择每页大小数组）

子组件

<template>

  <el-pagination :current-page.sync="currentPage" :page-size.sync="pageSize" :total="20" />

</template>



<script>

export default {

  name: 'HelloWorld',



  props: {

    page: {

      default: 1

    },

    limit: {

      default: 5

    },

  },

  computed: {

    currentPage: {

      get() {

        return this.page

      },

      set(val) {

        //currentPage 这里对currentPage做出来改变就会走这里

        //这边更新数据走这里

        console.log('currentPage', this.currentPage)

        this.$emit('update:page', val)

      }

    },

    pageSize: {

      get() {

        return this.limit

      },

      set(val) {

        this.$emit('update:limit', val)

      }

    }

  },

  methods: {

  }

}

</script>



<!-- Add "scoped" attribute to limit CSS to this component only -->

这里的page.sync、limit.sync目的就是为了实现数据的双向绑定，computed中监听page和limit的变化，子组件接收的数据通过computed生成的currentPage通过sync绑定到了 el-pagination中， 点击分页器的时候会改变currentPage 此时会调用set函数设置新的值，通过代码 this.$emit（update:page,value） 更新父组件中的值，实现双向的数据绑定

本文是作者在闲暇的时间随便记录一下， 若有错误请指正，多多包涵。感谢支持！