被裁员

先说下本人情况，38，坐标杭州，具备后端架构和大数据架构能力。待过大厂，带过团队，落地过大型项目。

近几年被裁员也不算什么稀奇古怪的事情，我记得2022年下半年面试那会行情远比现在好，那会还会有猎头、企业主动找，我2022年的工作就是猎头推进去的。

然而公司运营不善，2023年底裁撤了，因为融资问题，被迫出局。

本想着年后再看工作，也想休息一段时间，于是年前就没理工作这个事。

狗不理

因为信息差，也可能因为行业这种趋势本身就是没法感知的，年后投简历发现了几个情况：

一些感悟

面对这种突如其来的颠覆认知的行情，我有点措手不及，没预想自己可能就此失业了。现在的世界变化太快了，也可能我待在舒适区太久了，根本对外部世界的变化钝感迟缓。

我也没去问招聘方是什么原因，本身就个人从业经历和技能能来说，自认为还OK，但是问人家也未必会告诉你实话，在这个存量市场，势必是僧多肉少，刺刀见红，现实残酷，朝不保夕。

但是反思下十几年的职场生涯，其实多多少少还是有个人原因的，总结出来，留给后来人吧：

个人期望

最后说点自己的个人期望和未深思的规划：
1、后面还是要自己单干的，可以是独立开发、或者其他。
2、还是会热爱技术，即使如果干不了这行了，也会把它当做一个兴趣培养。

一、背景

在讲微前端之前，首先了解下前端开发模式的发展历程，在最早的时候，前端的开发是耦合在服务端，主要的工作其实就是提供一个界面模板，交互也不多，实际的数据还是在服务端渲染的时候提供的。

大概在2010年，界面越来越复杂，调试、部署、都要依赖于后端，如果还是以模板的形式开发效率太低了。于是就提出了前后端分离的模式开发，这个时期也是单页应用开始火起来的时期。

到了2014左右，后端开始了微服务模式的开发，这也为微前端提供的思路。随着前端承担的东西越来越多，不断的迭代后，原本简单的单页应用，已经变成了一个巨石应用，不管是代码量还是页面量都非常庞大，一个单页应用由多个团队一起来维护。同时巨石应用还受到了非常大的约束，比如新技术的更新、打包速度等等问题。

因此，在2019年左右，借鉴微服务的思想，提出了微前端的开发模式，也就是将一个大型的单页应用，以业务域为粒度，拆分为多个子应用，最后通过微前端的技术，整合成一个完整的单页应用，同时，每个子应用也能够享有独立应用开发一致的体验。

二、微前端简介

微前端概念

微前端是一种多个团队通过独立发布功能的方式来共同构建现代化 web 应用的技术手段及方法策略。Micro Frontends

微前端（Micro Frontends）是一种前端架构模式，借鉴了微服务的架构理念，将一个庞大的前端应用拆分为多个独立灵活的小型应用，每个前端应用都可以独立开发、独立运行、独立部署，再将这些小型应用联合为一个完整的应用。

微前端的目标是使前端开发更加容易、可维护和可扩展，并且能够实现团队之间的协作。

微前端的特点

• 技术栈无关 主框架不限制接入应用的技术栈，子应用可自主选择技术栈


• 独立开发/部署 子应用仓库独立，单独部署，互不依赖


• 增量升级 当一个应用庞大之后，技术升级或重构相当麻烦，而微应用具备渐进式升级的特性


• 独立运行 子应用之间运行时互不依赖，有独立的状态管理


• 提升效率 微应用可以很好拆分项目，提升协作效率


• 可维护性 微前端可以更容易地进行维护和测试，因为它们具有清晰的界限和独立的代码库

劣势

• 增加了系统复杂度 需要对系统进行拆分，将单体应用拆分成多个独立的微前端应用。这种拆分可能导致系统整体变得更加复杂，因为需要处理跨应用之间的通信和集成问题


• 需要依赖额外的工具和技术 例如模块加载器、应用容器等，这些工具和技术需要额外的学习和维护成本，也可能会导致一些性能问题


• 安全性问题 由于微前端应用是独立的，它们之间可能存在安全隐患。例如，如果某个微前端应用存在漏洞，攻击者可能会利用这个漏洞来攻击整个系统


• 兼容性问题 由于微前端应用是独立的，它们之间可能存在兼容性问题。例如，某个微前端应用可能使用了一些不兼容的依赖库，这可能会导致整个系统出现问题


• 开发团队需要有一定的技术水平 实现微前端需要开发团队有一定的技术水平，包括对模块化、代码复用、应用集成等方面有深入的了解。如果团队缺乏这方面的技能，可能会导致微前端实现出现问题

三、微前端的技术实现

3.1 微前端的基础架构

微前端架构基本需要实现三个部分:

• 主应用接入子应用，包括子应用的注册、路由的处理、应用的加载和路由的切换。


• 主应用加载子应用，这部分之所以重要，是因为接入的方式决定了是否可以更高效的解耦。


• 子应用的容器，这是子应用加载之后面临的问题，包含了JS沙箱、样式隔离和消息机制。

3.2 微前端的主要技术问题

1） 构建时组合 VS 运行时组合

主框架与子应用集成的方式

微前端架构模式下，子应用打包的方式，基本分为两种：

要实现真正的技术栈无关跟独立部署两个核心目标，大部分场景下需要使用运行时加载子应用这种方案。

2）JS Entry VS HTML Entry

子应用提供什么形式的资源作为渲染入口？

JS Entry 的方式通常是子应用将资源打成一个 entry script。但这个方案的限制也颇多，如要求子应用的所有资源打包到一个 js bundle 里，包括 css、图片等资源。

HTML Entry 则更加灵活，直接将子应用打出来 HTML 作为入口，主框架可以通过 fetch html 的方式获取子应用的静态资源，同时将 HTML document 作为子节点塞到主框架的容器中。

3）样式隔离

由于微前端场景下，不同技术栈的子应用会被集成到同一个运行时中，所以必须在框架层确保各个子应用之间不会出现样式互相干扰的问题。

“甲之蜜糖，乙之砒霜“，每个方案都有着不同的优势与劣势。

• BEM （Block Element Module）规范命名约束


• CSS Modules 构建时生成各自的作用域


• CSS in JS 使用 JS 语言写 CSS


• Shadow DOM 沙箱隔离


• experimentalStyleIsolation 给所有的样式选择器前面都加了当前挂载容器


• Dynamic Stylesheet 动态样式表


• postcss 增加命名空间

4）JS隔离

一个子应用从加载到运行，再到卸载，有可能会对全局产生一些污染。这些污染包括但不限于：添加 / 删除 / 修改全局变量、绑定全局事件、修改原生方法或对象等。而所有这些子应用造成的影响都可能引起潜在的全局冲突。为此，需要在加载和卸载一个应用的同时，尽可能消除这种影响。目前，主要有两种隔离方式，一种是快照沙箱、另外一种是代理沙箱。

• 快照沙箱的核心思想就是在应用挂载（mount方法）的时候记录快照，在应用卸载（unmount）的时候依据快照恢复环境。
  
  

  实现的思路是直接用 window diff，把当前的环境和原来的环境做一个比较，跑两次循环(创建快照和恢复快照)，然后把两个环境做一次比较，最后去全量的恢复回原来的环境。



• 代理沙箱的核心思想是让子应用里面的环境和外面的环境完全隔离。每个应用对应一个环境，比如应用A对应环境A，应用B对应环境B，同时两者之间的环境和全局环境也互不干扰。
  
  

  实现思路是主要利用 ES6 的 Proxy 能力。通过劫持window，可以劫持到子应用对全局环境的一些修改，当子应用往window上挂载、删除、修改的时候，把操作记录下来，当恢复全局环境时，反向执行之前的操作。

四、微前端方案

实现方式	基本思想	优点	不足	代表方案
路由分发	1.前端框架公共路由方案，映射到不同应用 2.服务器反向代理路由到不同应用	1. 维护、开发成本低；2.适应一些关联方不多、业务场景不发展的情况；	不足：1.独立应用的硬聚合，有比较明显的割裂感	--
前端容器化	iframe 可以创建一个全新的独立的宿主环境，这意味着前端应用之间可以相互独立运行，仅需要做好应用之间的管理、通信即可	1. 比较简单，无需过多改造，开发成本低； 2.完美隔离，JS、CSS 都是独立的运行环境； 3. 不限制使用，页面上可以放多个 iframe 来组合业务	1. 无法保持路由状态，刷新后 iframe url 状态丢失（这点也不是完全不能解决，可以将路由作为参数拼接在链接后，刷新时去参数进行页面跳转）； 2. 全局上下文完全隔离，应用之间通信困难（比如iframe 内外系统的通信、数据同步等需求，主应用的 cookie 要透传到根域名都不同的子应用中实现免登效果）； 3. iframe 中的弹窗无法突破其本身，无法覆盖全局； 4. 加载慢，每次子应用进入都是一次浏览器上下文重建、资源重新加载的过程	Iframe
前端微服务化	前端微服务化，是微服务架构在前端的实施，每个前端应用都是完全独立（技术栈、开发、部署、构建独立）、自主运行的，最后通过模块化的方式组合出完成的应用	1. 应用间通信简单，全局注入； 2. html entry 的方式引入子应用，相比 js entry 极大的降低了应用改造的成本； 3. 完备的js、css 沙箱方案，确保微应用之间的样式/全局变量/事件互相不干扰； 4. 具备静态资源预加载能力，加速微应用打开速度	1. 适配成本比较高，webpack工程化、生命周期、静态资源路径、路由等都要做一系列的适配工作； 2. css 沙箱采用严格隔离会有各种问题，js 沙箱在某些场景下执行性能下降严重； 3. 基于路由匹配，无法同时激活多个子应用，也不支持子应用保活； 4. 无法支持 vite 等 ESM 脚本运行	Single-SPA、qiankun
应用组件化	Web Components 是一套不同的技术，允许开发者创建可重用的定制元素（它们的功能封装在代码之外）并且在 Web 应用中使用它们，其中html imports 被废弃，可以直接加载js即可	1. 使用 类WebComponent 加载子应用相比 single-spa 这种注册监听方案更加优雅a; 2. 组件式的 api 更加符合使用习惯，支持子应用保活; 3. 降低子应用改造的成本，提供静态资源预加载能力; 4. 基于CustomElement和样式隔离、js隔离来实现微应用的加载，所以子应用无需改动就可以接入	1. 类 webcomponent css 沙箱依然无法绝对的隔离; 2. 支持 vite 运行，但必须使用 plugin 改造子应用，且 js 代码没办法做沙箱隔离; 3. 对于不支持 webcompnent 的浏览器没有做降级处理，兼容性不够	micro-app
微件化	微前端下的微件化是指，每个业务团队编写自己的业务代码，并将编译好的代码部署到指定的服务器上，运行时只需要加载指定的代码即可	1. webpack 联邦编译可以保证所有子应用依赖解耦； 2. 应用间去中心化的调用、共享模块； 3. 模块远程 ts 支持	1. 需要相关规范约束各Widget； 2. 没有有效的 css 沙箱和 js 沙箱，需要靠用户自觉； 3. 子应用保活、多应用激活无法实现； 4. 主、子应用的路由可能发生冲突	EMP

五、iframe 项目实践

5.1 iframe的概念以及作用

iframe（内联框架）是HTML标签，也是一个内联元素，作用是文档中的文档，或者浮动的框架(FRAME)，iframe 元素会创建包含另外一个HTML文档的内联框架（即行内框架) 。

简言之，iframe可以在当前页面嵌入其他页面

5.2 优缺点

优点：

缺点：

5.3 主要属性

5.4 父子页面通信

5.4.1 单向通信（父传子）

URL传参： 可以在iframe的src属性中使用URL参数，将父页面的数据传递到iframe嵌入的页面。

<iframe src="http://new-iframe-url?param1=value1&param2=value2"></iframe>

5.4.2 双向通信

父页面和子页面（即iframe内的页面）的通信机制，分为两种

（1）同源的父子页面通信：

如果父页面和子页面同源，可以直接通过JavaScript访问对方的DOM。这是因为同源策略允许同源的文档之间进行完全的交互。

父页面可以通过iframe元素的contentWindow属性获取子页面的window对象，然后直接调用其函数或访问其变量。同样，子页面也可以通过window.parent获取父页面的window对象。

父页面访问子页面：

// 获取iframe元素

const iframe = document.getElementById('myIframe');

// 获取子页面的window对象

const childWindow = iframe.contentWindow;

// 调用子页面的函数

childWindow.myFunction();

// 访问子页面的变量

console.log(childWindow.myVariable);

// 修改子页面的DOM

childWindow.document.getElementById('myElement').innerText = 'hhhh';

子页面访问父页面：

// 获取父页面的window对象

var parentWindow = window.parent;

// 调用父页面的函数

parentWindow.myFunction();

// 访问父页面的变量

console.log(parentWindow.myVariable);

// 修改父页面的DOM

parentWindow.document.getElementById('myElement').innerText = 'hhhh';

(2)不同源的父子页面通信：

如果父页面和子页面不同源，则不能直接通过JavaScript访问对方的DOM。但可以通过HTML5的postMessage API进行跨源通信。

具体来说，一个页面可以通过postMessage方法向另一个页面发送消息，然后另一个页面通过监听message事件来接收这个消息。

父页面发送消息到子页面：

var iframe = document.getElementById('myIframe');

iframe.contentWindow.postMessage('Hello', 'https://example.com');

子页面接收来自父页面的消息：

window.addEventListener('message', function(event) {

  if (event.origin !== 'https://parent.com') return;

  console.log('received message:', event.data);

});

5.5 项目中遇到的问题

问题描述

背景：页面初始化时，子应用iframe要从主应用获取cookie，实现免登

问题实现步骤：清除主应用的cookie，刷新页面，点击加载子应用，此时没获取到cookie，接口报鉴权错误

问题原因

1）异步获取 cookie：cookie 是通过 postMessage 从父页面异步获取的，在发送 HTTP 请求时，cookie可能尚未获取或存储在 sessionStorage 中

2）立即发送请求：在页面组件的 useEffect 钩子中，当组件挂载时立即发送请求，而不等待 cookie 的获取和存储，导致请求发出时缺少 cookie，造成请求失败

cookie交互流程

修复方案

为了确保 token 在 HTTP 请求发送之前已经成功获取并存储，需要实现以下步骤：

1）等待 token 被存储：在 httpMethod 中添加一个辅助函数，用于轮询 sessionStorage，直到 token 被存储

2）在请求之前检查并等待 token：在每个 HTTP 请求方法中，在请求实际发送之前，先调用辅助函数等待 token 被存储

具体实现

修改 api.js文件

1）创建一个waitForToken函数用于等待cookie中的 token

每隔 100ms 检查一次 sessionStorage 中是否存在 Access-Token，并返回一个 Promise。若存在 token ，调用 resolve(token) 方法将 Promise 标记为成功，并返回 token，否则等待 200 毫秒，再次检查token是否存在

const waitForToken = (timeout = 20000) => {

  return new Promise((resolve) => {

    const startTime = Date.now();

    const checkToken = () => {

      const token = window.sessionStorage.getItem("Access-Token");

      if (token) {

        resolve(token);  //找到 token，通过 resolve 通知任务成功完成

      } else if (Date.now() - startTime >= timeout) {

        resolve(null); // 超时后返回 null

      } else {

        setTimeout(checkToken, 200); //如果没找到，每200ms检查一次

      }

    };

    checkToken();

  });

};

2）修改httpMethod

在每个请求方法里调用 waitForToken， 确保在发送请求之前获取到 token，并在获取到 token 后将其从 sessionStorage 中取出并添加到请求头中

const httpMethod = {

  get: async (url, params) => {

    const token = await waitForToken();  //获取token

    return axios

      .get(api + url, {

        params: params,

        headers: Object.assign(

          headers("json"),

          { "Access-Token": JSON.parse(token) },

          options.headers || {}

        ),

      })

      .then(dataError, errorHandle);

  },

 postJson: async (url, data, options = {}) => {

    const token = await waitForToken();  //获取token

    return axios

      .post(api + url, data, {

        ...options,

        headers: Object.assign(

          headers("json"),

          { "Access-Token": JSON.parse(token) },

          options.headers || {}

        ),

      })

      .then(dataError, errorHandle);

  },

}

六、总结

微前端能否做到利大于弊，具体取决于实际情况和条件。对于小型、高度协作的团队和相对简单的产品来说，微前端的优势相比代价来说就很不明显了；而对于大型、功能众多的产品和许多较独立的团队来说，微前端的好处就会更突出。

工程就是权衡的艺术，而微前端提供了另一个可以做权衡的维度。

学习资料：

• Microfrontends: the good, the bad, and the ugly


• 万字长文-落地微前端 qiankun 理论与实践指北

源码实现思路（面试高分回答） 📖

面试官问我 Vue 的 nextTick 原理是怎么实现的，我这样回答：

在调用 this.$nextTick(cb) 之前：

当调用 this.nextTick(cb) 时：

graph TD

    A["this.$nextTick(callback)"] --> B[将回调函数 callback 放入到数组 callbacks 中]

    B --> C[判断是否是第一次调用 nextTick]

    C -->|是| D[执行 timerFunc, 将 flushCallbacks 添加到任务队列]

    C -->|否| F[如果没有 cb, 则retrun Promise]

    D --> F

    F --> 结束

如果上面的描述没有很理解。没关系，花几分钟跟着我下面来，看完下面的源码逐行讲解，你一定能够清晰地向别人讲出你的思路！

nextTick思路详解 🏃‍♂‍➡

1. 核心代码 🌟

下面用十几行代码，就已经可以基本实现nextTick的功能（默认浏览器支持Promise)

// 存储所有的cb回调函数

const callbacks = [];

/*类似于节流的标记位，标记是否处于节流状态。防止重复推送任务*/

let pending = false;



/*遍历执行数组 callbacks 中的所有存储的cb回调函数*/

function flushCallbacks() {

  // 重置标记，允许下一个 nextTick 调用

  pending = false;

  /*执行所有cb回调函数*/

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

    callbacks[i]();

  }

  // 清空回调数组，为下一次调用做准备

  callbacks.length = 0;

}



function nextTick(cb) {

  // 将回调函数cb添加到 callbacks 数组中

  callbacks.push(() => {

    cb();

  });

  

  // 第一次使用 nextTick 时，pending 为 false，下面的代码才会执行

  if (!pending) {

    // 改变标记位的值，如果有flushCallbacks被推送到任务队列中去则不需要重复推送

    pending = true;

    // 使用 Promise 机制，将 flushCallbacks 推送到任务队列

    Promise.resolve().then(flushCallbacks);

  }

}

测试一下：

let message = '初始消息';

  

nextTick(() => {

  message = '更新后的消息';

  console.log('回调：', message); // 输出2: 更新后的消息

});



console.log('测试开始：', message); // 输出1: 初始消息

如果你想要应付面试官，能手写这部分核心原理就已经差不多啦。

如果你想彻底掌握它，请继续跟着我来！！！🕵🏻‍♂

2. nextTick() 返回promise 🌟

我们在开发中，会使用await this.$nextTick();让其下面的代码全部变成异步代码。
比如写成这样：

await this.$nextTick();

......

......



// 或者

this.$nextTick().then(()=>{

    ......

})

核心就是nextTick()如果没有参数，则返回一个promise

const callbacks = [];

let pending = false;



function flushCallbacks() {

  pending = false;

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

    callbacks[i]();

  }

  callbacks.length = 0;

}



function nextTick(cb) {

  // 用于存储 Promise 的resolve函数

  let _resolve;

  callbacks.push(() => {

  /* ------------------ 新增start ------------------ */

    // 如果有cb回调函数，将cb存储到callbacks

    if (cb) {

      cb();

    } else if (_resolve) {

    // 如果参数cb不存在，则保存promise的的成功回调resolve

      _resolve();

    }

  /* ------------------ 新增end ------------------ */

  });

  if (!pending) {

    pending = true;

    Promise.resolve().then(flushCallbacks);

  }

  

  /* ------------------ 新增start ------------------ */

  if (!cb) {

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

      // 保存resolve到callbacks数组中

      _resolve = resolve;

    });

  }

  /* ------------------ 新增end ------------------ */

}

测试一下：

async function testNextTick() {

  let message = "初始消息";

  

  nextTick(() => {

    message = "更新后的消息";

  });

  console.log("传入回调：", message); // 输出1: 初始消息



  // 不传入回调的情况

  await nextTick(); // nextTick 返回 Promise

  console.log("未传入回调后：", message); // 输出2: 更新后的消息

}



// 运行测试

testNextTick();

3. 判断浏览器环境 🔧

为了防止浏览器不支持 Promise，Vue 选择了多种 API 来实现兼容 nextTick：

    Promise --> MutationObserver --> setImmediate --> setTimeout

// 存储所有的回调函数

const callbacks = [];

/* 类似于节流的标记位，标记是否处于节流状态。防止重复推送任务 */

let pending = false;



/* 遍历执行数组 callbacks 中的所有存储的 cb 回调函数 */

function flushCallbacks() {

  // 重置标记，允许下一个 nextTick 调用

  pending = false;

  /* 执行所有 cb 回调函数 */

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

    callbacks[i](); // 依次调用存储的回调函数

  }

  // 清空回调数组，为下一次调用做准备

  callbacks.length = 0;

}



// 判断最终支持的 API：Promise / MutationObserver / setImmediate / setTimeout

let timerFunc;



if (typeof Promise !== "undefined") {

  // 创建一个已resolve的 Promise 实例

  var p = Promise.resolve();

  // 定义 timerFunc 为使用 Promise 的方式调度 flushCallbacks

  timerFunc = () => {

    // 使用 p.then 方法将 flushCallbacks 推送到微任务队列

    p.then(flushCallbacks);

  };

} else if (

  typeof MutationObserver !== "undefined" &&

  MutationObserver.toString() === "[object MutationObserverConstructor]"

) {

  /* 新建一个 textNode 的 DOM 对象，用 MutationObserver 绑定该 DOM 并指定回调函数。

   在 DOM 变化的时候则会触发回调，该回调会进入主线程（比任务队列优先执行），

   即 textNode.data = String(counter) 时便会加入该回调 */

   var counter = 1; // 用于切换文本节点的值

   var observer = new MutationObserver(flushCallbacks); // 创建 MutationObserver 实例

   var textNode = document.createTextNode(String(counter)); // 创建文本节点

   observer.observe(textNode, {

      characterData: true, // 监听文本节点的变化

   });

   // 定义 timerFunc 为使用 MutationObserver 的方式调度 flushCallbacks

  timerFunc = () => {

    counter = (counter + 1) % 2; // 切换 counter 的值（0 或 1）

    textNode.data = String(counter); // 更新文本节点以触发观察者

  };

} else if (typeof setImmediate !== "undefined") {

  /* 使用 setImmediate 将回调推入任务队列尾部 */

  timerFunc = () => {

    setImmediate(flushCallbacks); // 将 flushCallbacks 推送到宏任务队列

  };

} else {

  /* 使用 setTimeout 将回调推入任务队列尾部 */

  timerFunc = () => {

    setTimeout(flushCallbacks, 0); // 将 flushCallbacks 推送到宏任务队列

  };

}



function nextTick(cb) {

  // 用于存储 Promise 的解析函数

  let _resolve; 

  // 将回调函数 cb 添加到 callbacks 数组中

  callbacks.push(() => {

    // 如果有 cb 回调函数，将 cb 存储到 callbacks

    if (cb) {

      cb();

    } else if (_resolve) {

      // 如果参数 cb 不存在，则保存 Promise 的成功回调 resolve

      _resolve();

    }

  });



  // 第一次使用 nextTick 时，pending 为 false，下面的代码才会执行

  if (!pending) {

    // 改变标记位的值，如果有 nextTickHandler 被推送到任务队列中去则不需要重复推送

    pending = true;

    // 调用 timerFunc，将 flushCallbacks 推送到合适的任务队列

    timerFunc(flushCallbacks);

  }



  // 如果没有 cb 且环境支持 Promise，则返回一个 Promise

  if (!cb && typeof Promise !== "undefined") {

    return new Promise((resolve) => {

      // 保存 resolve 到 callbacks 数组中

      _resolve = resolve;

    });

  }

}

你真的太牛了，居然几乎全部看完了！

Vue纯源码

    上面的代码实现，对于 nextTick 功能已经非常完整了，接下来我将给你展示出 Vue 中实现 nextTick 的完整源码。无非是加了一些判断变量是否存在的判断。看完上面的讲解，我相信聪明的你一定能理解 Vue 实现 nextTick 的源码了吧！💡

// 存储所有的 cb 回调函数

const callbacks = [];

/* 类似于节流的标记位，标记是否处于节流状态。防止重复推送任务 */

let pending = false;



/* 遍历执行数组 callbacks 中的所有存储的 cb 回调函数 */

function flushCallbacks() {

  pending = false; // 重置标记，允许下一个 nextTick 调用

  const copies = callbacks.slice(0); // 复制当前的 callbacks 数组

  callbacks.length = 0; // 清空 callbacks 数组

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

    copies[i](); // 执行每一个存储的回调函数

  }

}

// 判断是否为原生实现的函数

function isNative(Ctor) {

  // 如Promise.toString() 为 'function Promise() { [native code] }'

  return typeof Ctor === "function" && /native code/.test(Ctor.toString());

}



// 判断最终支持的 API：Promise / MutationObserver / setImmediate / setTimeout

let timerFunc;



if (typeof Promise !== "undefined" && isNative(Promise)) {

  const p = Promise.resolve(); // 创建一个已解决的 Promise 实例

  timerFunc = () => {

    p.then(flushCallbacks); // 使用 p.then 将 flushCallbacks 推送到微任务队列



    // 在某些有问题的 UIWebView 中，Promise.then 并不会完全失效，

    // 但可能会陷入一种奇怪的状态：回调函数被添加到微任务队列中，

    // 但队列并没有被执行，直到浏览器需要处理其他工作，比如定时器。

    // 因此，我们可以通过添加一个空的定时器来“强制”执行微任务队列。

    if (isIOS) setTimeout(() => {}); // 解决iOS 的bug，推迟 空函数 的执行（如果不理解，建议忽略）

  };

} else if (

  typeof MutationObserver !== "undefined" &&

  (isNative(MutationObserver) ||

    MutationObserver.toString() === "[object MutationObserverConstructor]")

) {

  let counter = 1; // 用于切换文本节点的值

  const observer = new MutationObserver(flushCallbacks); // 创建 MutationObserver 实例

  const textNode = document.createTextNode(String(counter)); // 创建文本节点

  observer.observe(textNode, {

    characterData: true, // 监听文本节点的变化

  });

  // 定义 timerFunc 为使用 MutationObserver 的方式调度 flushCallbacks

  timerFunc = () => {

    counter = (counter + 1) % 2; // 切换 counter 的值（0 或 1）

    textNode.data = String(counter); // 更新文本节点以触发观察者

  };

} else if (typeof setImmediate !== "undefined" && isNative(setImmediate)) {

  timerFunc = () => {

    setImmediate(flushCallbacks); // 使用 setImmediate 推送到任务队列

  };

} else {

  timerFunc = () => {

    setTimeout(flushCallbacks, 0); // 使用 setTimeout 推送到宏任务队列

  };

}



function nextTick(cb, ctx) {

  let _resolve; // 用于存储 Promise 的解析函数

  // 将回调函数 cb 添加到 callbacks 数组中

  callbacks.push(() => {

    if (cb) {

      try {

        cb.call(ctx); // 执行传入的回调函数

      } catch (e) {

        handleError(e, ctx, "nextTick"); // 错误处理

      }

    } else if (_resolve) {

      _resolve(ctx); // 解析 Promise

    }

  });

  // 第一次使用 nextTick 时，pending 为 false，下面的代码才会执行

  if (!pending) {

    pending = true; // 改变标记位的值

    timerFunc(); // 调用 timerFunc，调度 flushCallbacks

  }

  // 如果没有 cb 且环境支持 Promise，则返回一个 Promise

  if (!cb && typeof Promise !== "undefined") {

    return new Promise((resolve) => {

      _resolve = resolve; // 存储解析函数

    });

  }

}

总结

      通过这样分成三步、循序渐进的方式，我们深入探讨了 nextTick 的原理和实现机制。希望这篇文章能够对你有所帮助，让你在前端开发的道路上更加得心应手！🚀

一转眼又快过年了，回想整个23年，简直是我人生中最黑暗的一年(之一)。

23年，我30岁，在北京干了8年程序员。30岁这年我做了一个决定：结束8年北漂生涯，回老家（一个三线城市）自己创业，去做自媒体。

一、为何做出这个决定

这个决定也不是一时拍脑袋做出的决定，导火索是在22年：

那时候大环境不好，大家都越来越卷，下班的时间也越来越晚。

放假回家亲戚朋友总说，你在北京996这么累，图啥啊，工资是高点，但是完全没有生活啊。而且你在北京漂到啥时候是个头？你又买不起房，又没户口，早晚得回来吧。

我仔细想想也有道理，活了这么多年了都在当牛做马，被pua，还得面临35岁危机，真的受够这种生活了！所以那时候心里埋下了一颗种子：我要去浪浪山的那边看看！

其实我本身就是一个喜欢自由的人，这么多年那句“打工是不可能打工的，这辈子都不会打工”一直激励着我，我想自己有一天也能实现不打工这个目标。

于是22年底我做了一个决定：23年去山的那边看看大海的样子！拿完年终奖就辞职！去创业，去开启我的新的人生！

在准备辞职前的几件事情，都让我更加坚定了辞职的决心：

我觉得这不是我想要的生活，每天太累了，身体累不算，心还累，生怕自己负责的业务出了什么问题，如坐针毡，如芒刺背，如履薄冰。

二、我辞职了

终于，熬到23年，拿到年终奖后，我决定提出离职。

当时身边有些人劝我不要辞职，说现在环境不好，更不应该放弃你的老本行，去做啥自媒体。

我当时内心嗤之以鼻，心想程序员这行也就干到35岁，而且现在卷的不行，加班加的身体都快废了，这行岁数大了没前途！我趁现在30岁还年轻，创业正值当年，辞职改行的选择非常有战略眼光！（当时真的是感觉杰克马附体，准备在这个三十而立的年纪，大干一场！）

当然我也不是脑袋一热就想着辞职去做自媒体，辞职前我做了充足的准备，和很长时间的调研&分析：

• 我作为一个互联网人，做实体店肯定不是我擅长的，肯定只能从互联网上选择行业，互联网项目有很多：个人工具站，知乎好物，闲鱼二手书，小红书带货，抖音带货，抖音个人ip，公众号写作，短剧cps，小说推文，知识付费等等的项目，我可以说都看了一个遍，其中抖音现在流量最大，要做风口上的猪，做抖音相关肯定要容易很多。


• 然后我也学习了一些创业相关的知识，比如如何找对标，如何分析对方商业模式，参加了很多知识付费的圈子，然后还报了小红书和抖音的培训班，总共加起来得有1w多呢。


• 而且我还预留了充足的资金，我做了最坏的打算，就算我一分钱不挣，也够我活3年呢，我不会3年都创业不成功吧！（此处白岩松表情包：不会吧！.jpg）

三、想象很美好

为了这次创业，我还制定了计划，年度计划，季度计划，月计划，周计划，天计划，真的非常详细。

我也要很自律，每天按时起床，锻炼，学习，做业务。这次我真的抱着必胜的决心来做！

当然我也提前列出可能要遇到的风险，并思考解决方案：

比如项目进展慢怎么办，拖延症怎么办，家人反对怎么办，朋友约吃饭打乱我的计划怎么办，遇到困难我该怎么应对等等

这么一套组合拳下来，我觉得已经万事俱备，只差开干了！

四、现实很残酷

4月我如期辞职，当时正值清明节，淅淅沥沥的小雨并没有浇灭我开启新生活的热情。辞职后，我就按计划开始早睡早起，锻炼，学习，搞创业的事情。

但是马上就被打脸了，这是我创业中遇到的第一个难题，也是我万万没有预料到的

就在我创业后的不久，我患上焦虑症，失眠了，而且还很严重，就是那种从晚上11点躺下，躺到早上6点才睡着的那种失眠，而且还时不时的心悸。

我万万没想到会患上失眠症。因为我觉得没有上班的压力了，想啥时候干活就啥时候干活，想干多少干多少，想啥时候下班就啥时候下班，也没人pua我了，还有时间锻炼，应该睡得更好才是。

但实际并不是这样，对于一个从小被学校管，长大了被公司管的芸芸众生来说，创业实际是这样的：

所以在此奉劝有裸辞创业想法的人，千万不要裸辞！裸辞创业九死一生！ 正确的做法是一边工作愿一边做副业，等副业的收入和工资差不多甚至超过工资了，再去辞职。有人会说，我工作那么忙，根本没时间搞副业啊。我之前也是这么想的，但是现在我会告诉你：没有时间就去挤出时间，每天晚睡或者早起一会，周末也抽出时间搞。这点问题都解决不了？创业的遇到问题会比这难十倍！如果这个你觉得太难了，那我劝你还是老老实实打工吧。

但是我已经裸辞了，没办法，只能去解决问题，我开始吃助眠药，喝中药，有些好转，但也没治好，只是比之前好点。

就这么拖着残血的半条命，我坚持了半年多，一半时间学习，一半时间实践，搞了两个自媒体号，第一个号违规被封了，第二个号流量也没啥起色。这条路是越走越看不到希望，每天晚上都不想睡觉，因为害怕明天的到来，因为明早一起床，眼前又是一片黑暗。

五、彻底崩溃

11月，因为种种原因和媳妇生了一场气，我觉得对于我创业，她不鼓励也就算了，在我状态这么差的情况下还不能对我包容一点，甚至有点拆后台的感觉，那几天我就像一个泄了气的皮球，内心被彻底击垮了。（所以现在有点理解每个成功男人的背后，都有一个伟大的女人这句话的含义了）

终于，在创业的压力，8个月没有收入的恐慌，焦虑失眠心悸的折磨中，我决定放弃了。

失败了，彻彻底底的失败。回想这次经历，就好像之前在一艘航行的货轮上打工，然后受不船上的种种压榨，终于鼓起勇气，自己带着一艘救生艇，跳海奔向自己想要的自由。结果高估了自己的目前的实力，经不起茫茫大海狂风骤雨，翻船了。。濒临溺亡。。。

六、重新找工作

放弃后的那几周，我开始熬夜，开始暴饮暴食，之前的运动也放弃了。整天在家里拉着窗帘，除了吃饭就是躺在床上刷手机，让我尽可能分散注意力，减少内心的痛苦。

但是这样的状态也不是事儿啊，目前肯定是不想再去面对创业的事情了，那只能去找个工作先干着了。

刚开始找工作内心又有不甘，因为一个三线城市比起北京来说，不管是工作机会，环境，薪资来说，都差太多。

但是没办法，我现在的感觉就是快溺死了，我现在急需一个救命稻草，活下来，是我目前的首要任务。

于是在网上海投了一遍，结果惨不忍睹，根本没几家公司招人，前前后后一个月，真正靠谱的面试就一家，是的，只有一家。

好在这家也顺利拿了offer，是一家刚创业的公司，一共十几个人，薪资只有原来1/3多点，但是拿到offer那一刻我依然有些激动，我感觉我活下来了，不管怎样，现在能喘口气了。

七、迷茫的未来

现在上班已经一个多月了，公司挺好，不加班，基本上7点前就都走了，离家也挺近，骑个共享单车也就10分钟。这一个月，焦虑没了，不心悸了，失眠也好了。每天就是按部就班上下班，完成老板给的任务，其他的事情也不用自己操心，终于又做起自己熟悉且擅长的事情。

但是内心还是有落差，本来北京好好的工作自己作死给辞了，要不这一年也能攒不少钱呢，现在不但钱没了，这几个月还花了好几w，最后还差点嘎了。

其实入职这家公司前，北京之前的同事问我要不要回去，说现在正忙，我说你先问问吧。

我当时也纠结，如果真的能回去，我还要不要回去，毕竟在那边挣一个月顶这边仨月。但是回都回来了，再去北京可能就一辈子留北京了吧。

不过后来同事说年前没有招人计划了，可能要年后了，如果招人到时再联系我。正好我不用纠结了，这可能就是命运的安排吧。

不过真的想问问你们，如果到时有机会，是继续北漂呢，还是选择在老家呢？

八、结语

说实话，我现在知道了，山的那边还是山，我不知道什么时候才能看到海，甚至我可能一辈子都看不到海了。不过目前想的就是，调整好状态，先走一步算一步吧。

30岁的年纪，学会和自己和解，学会接受自己的平庸，但是依然要努力，毕竟在这个阴雨连天的环境下，没有伞的孩子只能努力奔跑。

前言

最近写一个移动端的项目，用到了vant做UI界面设计，不得不再次感叹开源的力量，这个组件库封装的实在是太优雅了，只要你愿意看官方文档，就不会担心看不懂，也不会担心不会用，接下来就带大家去浅尝一下这个组件库。官网文档：Vant 4 - 轻量、可定制的移动端组件库 (vant-ui.github.io)

Vant

Vant 是一个轻量、可定制的移动端组件库，于 2017 年开源。

可以看到，移动端，用来做移动端的ui界面。

目前 Vant 官方提供了 Vue 2 版本、Vue 3 版本和微信小程序版本，并由社区团队维护 React 版本和支付宝小程序版本。

特性

• 🚀 性能极佳，组件平均体积小于 1KB（min+gzip）


• 🚀 80+ 个高质量组件，覆盖移动端主流场景


• 🚀 零外部依赖，不依赖三方 npm 包


• 💪 使用 TypeScript 编写，提供完整的类型定义


• 💪 单元测试覆盖率超过 90%，提供稳定性保障


• 📖 提供丰富的中英文文档和组件示例


• 📖 提供 Sketch 和 Axure 设计资源


• 🍭 支持 Vue 2、Vue 3 和微信小程序


• 🍭 支持 Nuxt 2、Nuxt 3，提供 Nuxt 的 Vant Module


• 🍭 支持主题定制，内置 700+ 个主题变量


• 🍭 支持按需引入和 Tree Shaking


• 🍭 支持无障碍访问（持续改进中）


• 🍭 支持深色模式


• 🍭 支持服务器端渲染


• 🌍 支持国际化，内置 30+ 种语言包

没错，这是官网复制来的介绍。

那么从官方文档可以看到目前这是Vant4.x，适用于vue3，如果你用的是vue2，那么就用Vant2。我们切换到快速上手，就能看到如何快速入门使用

Vant使用

1.安装

在现有项目中使用 Vant 时，可以通过 npm 进行安装：

# Vue 3 项目，安装最新版 Vant

npm i vant



# Vue 2 项目，安装 Vant 2

npm i vant@latest-v2

看得出来，非常优雅，最新版直接安装vant，如果不是最新的才加了些-2...

当然，你也可以通过 yarn、pnpm 或 bun 进行安装：什么方式都有，大家可以自己参照官方文档。

# 通过 yarn 安装

yarn add vant



# 通过 pnpm 安装

pnpm add vant



# 通过 Bun 安装

bun add vant

那么引入之后如何使用呢？我们常常需要做一个登陆注册页面，看看有了vant组件库之后，我们还需要去切页面吗？

此处我们需要放一个表单，接下来我们查阅官方文档，看看vant的表单如何使用。

2.引入

写的很清楚，表单会用到三个组件，我们只需要从vant库中引入这三个组件，然后都use掉即可

import { createApp } from 'vue';

import { Form, Field, CellGr0up } from 'vant';



const app = createApp();

app.use(Form);

app.use(Field);

app.use(CellGr0up);

引入之后，就可以在我们需要用到表单的页面使用了。直接将他写好的表单复制到我们的代码中

<van-form @submit="onSubmit">

  <van-cell-group inset>

    <van-field

      v-model="username"

      name="用户名"

      label="用户名"

      placeholder="用户名"

      :rules="[{ required: true, message: '请填写用户名' }]"

    />

    <van-field

      v-model="password"

      type="password"

      name="密码"

      label="密码"

      placeholder="密码"

      :rules="[{ required: true, message: '请填写密码' }]"

    />

  </van-cell-group>

  <div style="margin: 16px;">

    <van-button round block type="primary" native-type="submit">

      提交

    </van-button>

  </div>

</van-form>

可以看到，它使用了v-model双向绑定，因此我们就需要自己去定义一个username、passwor...看需要用到什么，然后官方文档就直接了当告诉我们了这些变量

import { ref } from 'vue';



export default {

  setup() {

    const username = ref('');

    const password = ref('');

    const onSubmit = (values) => {

      console.log('submit', values);

    };



    return {

      username,

      password,

      onSubmit,

    };

  },

};

• 注意他这里提交表单事件，直接接收了一个参数values，事实上这个values可以直接通过values.name，我们input框上的name属性代表的input框拿到的数据，在这里其实就是values.用户名，所以我们可以直接改成英文，如：values.username。

在官方文档上也能看见他的样式，甚至可以做校验

除此之外，再介绍一个，例如微信中点击某个东西成功之后，就会弹出一个弹出框，打勾，或者失败，如果这么一个UI界面要我们自己去写可能多少也有点麻烦，但是vant都给我们封装好了

引入

通过以下方式来全局注册组件，更多注册方式请参考组件注册。

import { createApp } from 'vue';

import { Toast } from 'vant';



const app = createApp();

app.use(Toast);

显然就是引入一个封装好了的Toast组件，然后use掉，vant官方都给我们想好了，一般这种弹出提示框都是我们js中做判断，如果成功就弹出，因此一般都出现在函数里面，官方就直接给我们打造了函数调用的方式

import { showToast } from 'vant';



showToast('提示内容');

全局引入依赖之后，在js中直接引入，然后直接调用就能出现效果，帮助咱们切图仔省去了不少麻烦事儿。

除了成功、失败，他甚至可以自定义写图标，也是极度舒适了。

看看我的登录页面是如何使用的：

<template>

    <div class="login">

        <h1>登录</h1>

        <div class="login-wrapper">

            <div class="avatar">

                <img src="https://q6.itc.cn/q_70/images03/20240601/80b789341c9b45cb8a76238650d288a5.png" alt="">

            </div>



            <van-form @submit="onSubmit">

                <van-cell-group inset>

                    <van-field v-model="username" name="username" label="用户名" placeholder="用户名"

                        :rules="[{ required: true, message: '请填写用户名' }]" />

                    <van-field v-model="password" type="password" name="password" label="密码" placeholder="密码"

                        :rules="[{ required: true, message: '请填写密码' }]" />

                </van-cell-group>

                <div style="margin: 16px;">

                    <van-button round block type="primary" native-type="submit">

                        登录

                    </van-button>

                </div>

            </van-form>





        </div>

    </div>

</template>



<script setup>

import { ref } from 'vue'

import axios from '@/api/index.js'

const password = ref('')

const username = ref('')

// 登录

const onSubmit = (values) => {

    // console.log(values); // 用户输入的账号和密码对象 name作为key

    // 发送接口请求给后端 校验数据 

    axios.post('/user/login', {

        username: values.username,

        password: values.password

    }).then((res) => {

        console.log(res);

    })

}

</script>



<style lang="less" scoped>

.login {

    width: 100vw;

    height: 100vh;

    background-color: #fff;

    padding: 0 0.3rem;

    box-sizing: border-box;

    overflow: hidden;



    h1 {

        height: 0.6933rem;

        text-align: center;

        font-size: 0.48rem;

        margin-top: 1.12rem;

    }



    .login-wrapper {

        width: 7.44rem;

        height: 10.77rem;

        border: 1px solid rgba(187, 187, 187, 1);

        margin: 0 auto;

        margin-top: 1.7rem;

        border-radius: 0.3rem;

        box-shadow: 0 0 0.533rem rgba(170, 170, 170, 1);



        .avatar {

            width: 2.4rem;

            height: 2.4rem;

            margin: 1rem auto 0.77rem auto;

            border-radius: 50%;

            overflow: hidden;



            img {

                width: 100%;

            }

        }

    }

}



:deep(.van-cell__title.van-field__label) {

    width: 45px;

}

</style>

非常方便，跟着上述步骤，官方文档写的很清楚，直接贴上去就实现了，然后自己再加一些less样式。

那么其他的就不做过多介绍了，大家在做项目需要用到一些东西的时候，直接查阅官方文档，直接拿去用即可。Vant 4 - 轻量、可定制的移动端组件库 (vant-ui.github.io)

在这里我写的都是rem单位，目的是做移动端的适配，根据宽度调整fontsize的大小，其实也可以通过vant封装好的移动端适配组件来做，这里不做过多介绍了。

小结

Vant 是一个轻量、可靠的移动端组件库，可用于快速构建风格统一的移动端 UI 界面。它提供了一系列高质量的组件，涵盖了导航、表单、按钮、列表、轮播图等常用功能。

我们只需要安装依赖后引入依赖还有在全局中引入他的整份css代码，最后按需取组件，就能轻松完成ui界面设计。

你好呀，我是歪歪。

前几天发了一个牢骚：

本来只是单纯的吐槽一下，但是好多人对其中的细节比较感兴趣。

大家都是搞技术的嘛，对于“踩 BUG”这种喜闻乐见的事情，有兴趣是很正常的。

其实我这个 BUG，其实严格意义上不能叫做 BUG，因为和程序无关，甚至和技术的关系都不算大。从标题上你也能猜出来，是和一个业务参数相关。

但是在这个过程中，因为我是整个事件全程的亲历者，所以现在回看这个事情，我还是有一些思考在里面的。

我觉得这是一个程序员会遇到的“典型事件”。

那就用这篇文章一起复盘一下吧。

背景

要说明这个问题的背景，甚至不需要一个具体的业务场景，只需要围绕着以下这个非常常见的利息计算公式，就可以说明问题的起因：

利息=计息金额*日利率。

日利率=年利率/360

由于日利率的计算，涉及到除法，在对应需求第一次开发时，业务的要求是日利率保存 7 位小数。

在程序中，年利率和日利率是两个字段分别保存的，日利率在初始化的时候就算好落库了，后续程序直接取这个算好的日利率就行了。

系统上线，相安无事。

跑了一段时间后，业务又提来一个需求：当前的精度不够，需要调整到 11 为小数。

你不用好奇歪师傅这边到底是什么业务场景，反正我去看了业务数据，需求是合理的，那就把需求接过来干就行了。

保存 7 位小数和 11 位小数，大家都是搞开发的，肯定也知道这个就是一个小改动，很快就能搞定。

事实也是如此，虽然之前的需求对应的代码不是我写的，但是我看过代码，清楚的知道改动点在哪，所以很快就开发完成。

前面说了，这个需求之前在线上按照 7 位小数跑了一段时间，所以存在一些存量配置。

针对这些存量数据，在需求评审会议上的时候，我提了一句：存量配置怎么处理呢？

业务答复：这次需求上线的时候，你按照 11 位小数重新算好，然后写 SQL 更新一下就行。

我心里一盘算：计算公式明确，年利率我也有，算一把，没啥问题。

就答应了。

然后，不出意外的出意外了。

假设年利率是 2.5%，除以 360 之后，保留 11 位小数，应该是 0.00006944444。

而我不知道当时为什么手抖了，在 SQL 里面写成了 0.00069444444。

我给你对比一下：

0.00006944444

0.00069444444

相当于我写出来的日利率被扩大了十倍。

然后再回头看看这个公式：

利息=计息金额*日利率

日利率被扩大十倍，那么对应的计提金额也会被扩大十倍。

这就是问题的背景。

一个单纯的人为失误，和程序没有任何关系，所以严格意义上不属于程序 BUG。

但是这个问题确实是足够低级。

为什么没被发现？

那么这个错误的 SQL 是怎么通过代码评审、测试验证这两道关卡被带到生产环节的呢？

首先，这一次提交的代码，压根就没有评审环节。

我有代码提交权限，也有代码审核权限。所以我自己提交，自己就审核通过了。

其实这个需求应该是组里面另外一个小伙伴来做，但是当时他被调到其他组了。

他还在我们组的时候，我们的合作模式是他提交代码，我进行审核。

如果有这个环节，我觉得我有 50% 的几率发现问题。

为什么是 50% 呢？

因为这取决于我审核代码时是否有正在处理其他的事情，如果有其他事情处理，我可能会形式主义的看上几眼。如果没有其他事情，而这次提交的代码量又不大的话，我基本上都会认真的过一下提交的内容。

通过代码评审之后，接下来就应该是测试环节。

测试主要关注的是精度从 7 位变成 11 位之后，最终计算出来的利息是否符合预期。

他测试时是走了整个业务的全流程。

在“全流程”中，这个 11 位精度的日利率，是在页面配置年利率的时候通过程序自动计算出来的，不会错的。

而他在验证 SQL 语句的时候，测试环境又没有生产环境的配置，所以他拿着我提供的 SQL，只能保证写的语法没问题，能正常执行，并不能确保里面数据的正确性。

而我也记得很清楚，我当时给他说过：你执行一下 SQL 不报错就行，值的正确性，我来保证。

而且戏剧性的是，测试同事很仔细的去看了值，他去数了确实是 11 位小数。但是可惜，站在他的视角，他发现不了值被扩大了十倍。

所以，测试环节也没有发现这个问题：

0.00006944444

0.00069444444

就带着上生产了。

一个问题正常来说不应该被带上生产，但是我们确实不能保证测试环节一定能把所有问题都测出来，所以新项目、新迭代的生产验证也是非常有必要的。

这个我们也做了。

按理来说，生产上的数据已经是错误的了，而且是一个“利息金额扩大十倍”的明显的错误，如果主动去做了数据验证，应该能被发现才对。

那为什么做了生产验证，却没有发现问题呢？

因为当时存量配置有三条，我提供了 3 个 SQL，其中有一个是算对了的。

每一条存量配置都对应着大量的利息数据，而算对了的这个对应的数据更多，在比例上超过 60%。

我进行生产验证的时候，在大量的利息计提数据中随机抽选了两条，选中的这两条，恰好都是正确的 SQL 对应的数据。

所以我发现符合预期，得出了生产验证通过的结论。

站在这个节点，回顾整个事件，这个时候应该是最有可能发现问题的时候。

但是没发现。

根本原因是验证方案不严谨，玄学原因是运气不站在我这边。

怎么暴露的？

你想想，这种业务参数配置错误的问题你能通过什么监控规则监控到吗？

其实很难的。

我们一般来说做技术层面的监控，都是监控程序是否按照预期正常运行。比如在计算的过程中出现异常，那我们是可以监控到的。

但是在这种只是参与计算的值不对，但是能正常计算出一个值的情况，并不会报错。

这种问题通过技术手段很难监控到。如果硬要去做监控，肯定是能做的，比如从异常浮动的维度、横向数据对比的维度，但是配套的开发成本又上去了。

我是怎么发现这个问题的呢？

也是纯粹的运气。

是一个周五的晚上，我做另外的一个和本问题毫无关系的场景下的数据验证的时候，偶然间看到了一笔数据的金额和前几天比，明显大了很多。

这是不符合业务规律的。

然后进一步跟踪，最终定位到了前面的问题 SQL。这个时候距离这个 SQL 上线，已经过去了三天，已经产生了一批错误数据了。

如果我没有偶然间看到这个问题数据，那么这个问题会在什么环节暴露呢？

就是在业务使用这个数据做核对的时候。

那个时候整个问题的性质就变了。不仅是处理时间来不来得及的问题了，而是这个问题是由“开发自主发现”还是由“外部反馈发现”这两个完全不同的性质了。

一般来说，不管是什么问题，先抛开严重程度，只要是开发自主发现的，都能一定程度上让事情变得不那么难堪。

所以我们才一度强调“可监控”的重要性。

随后，我联系了业务，反馈了这个情况。他表示在他下次使用这批数据之前，把数据修复好就行。大概一个月后，他会用到这批数据。

这样，我有接近一个月的时间来处理这个问题，防止问题扩大化。

时间非常充足，站在这个角度，我运气还不错的。

问题已经暴露出来了，随后就是制定针对这批错误数据的修复方案了。

修复方案就和业务场景相关了，属于多个业务场景叠加在一起，所以修复方案其实是比较复杂的，涉及到“修数”和“补数”，没有展开描述的必要了。

只是想简单提一句，这个修复方案是我利用周末的时间想出来的，很多细节问题我都需要考虑到，甚至在心里写了一遍伪代码。

确实是浪费了周末的时间，但是这是为自己的错误买单，半点不怨别人，就是活该。

而对于参与后续方案讨论的同事来说，在这件事情上付出的时间，才是属于无妄之灾。

这就是整个事情的过程，一个小数点引发的血案。

再回首

现在整个事情的全貌都在你眼前了，你得到了什么经验教训？

因为手抖了，写错了一位小数，这确实是直接原因，所以是想着下次再处理这种数据的时候，更加小心一点吗？

我觉得不是这样的。

我得到的经验教训就是我的标题：开发人员，千万不要去碰那该死的业务参数！

如果在最开始需求评审会，我们讨论到存量数据的时候。

业务说：这次需求上线的时候，你按照 11 位小数重新算好，然后写 SQL 更新一下就行。

我说：不行，这个属于是业务参数，我不能去动。上线完成后，就具备这个功能了，你可以通过页面配置去修改。

我知道他们修改业务参数的流程，很长很复杂。

首先业务需要发起一个参数变更的 OA 流程，然后走到他的部门负责人审批。

业务部门负责人审批完成后，会到具体负责业务参数配置的人员手里，还需要该人员对应的部门负责人审核。

审核完成后有权限的人员才会去修改这个业务参数，而这个参数的修改，在对应的系统功能上还有两级甚至三级审核。

整个完成之后发起 OA 的人员还需要进行变更确认，看看页面上是否是自己想要的配置。

这一套流程走下来，你觉得还会出错吗？

很难出错了。

你可以批判这个流程过于臃肿，但是你最终总是会认识到，这个流程其实是在保护打工人。

我知道他流程比较复杂，而我写个 SQL 几乎是没有成本的，但是这是在 SQL 正确的前提下。

如果当时不答应通过 SQL 的方式帮他处理存量数据，他其实有更加正规的流程去处理这些数据，而且不会出错。

事后我们复盘的时候，也有同事私下向我提出了这个的问题：为什么不走 OA 流程去调整这个参数？

另外，关于流程，我给你举一个程序员方面的例子。

一个核心开发人员拥有线上数据库的操作权限，我们先假设这个人绝对忠诚、绝对可以信赖、绝对恪尽职守、绝对不会删库跑路。

某一天，他收到一个预警信息，经过排查发现需要去修改数据库里面某个数据的状态，他直接就去修改了。

这个操作非常常见，特别是在小公司或者在一些在快速发展阶段的公司。

后来这个公司成长起来了，开始更加注重操作风险了，回收了所有人员的数据库权限，以前的事儿既往不咎，以后想要修改数据库数据，必须要发起一个审批流程，经过层层审批之后才能执行。

这个流程和“直接去修改”这个动作比起来，就重了无数倍了。

站在程序员的角度，前几年都是可以直接操作生产数据，突然这个制度出来了，极大的影响了之前的开发惯性。所以刚刚开始执行的时候，你可能会骂一句：xxx。

但是长远来看，这个流程其实是在保护你。

当你有数据库权限的时候，操作对了，没有人会夸你。操作错了，你就是罪魁祸首。

有了一个审批流程，在加重了操作成本的同时，也降低了错误成本。

处理问题的时长可能增加了，对于问题处理的敏捷度可能降低了，但是站在公司的角度，随着公司的发展“稳定”才是永恒的主旋律，在稳定面前，敏捷度反而是可以牺牲的。

歪师傅在第一家公司业务野蛮发展的时代，曾经就有这样的权限，那个时候刚刚参加工作两年多的时间，觉得事情就应该是这样的，这样才是正确的，可以足够敏捷，足够迅速的处理问题。

后来权限回收了，当时我也在私底下骂骂咧咧了几句。

再回来，随着经验和在职场上见过得事儿越来越多，才渐渐认识到：蛮荒时代确实出英雄，但是我没有把握好机会成为英雄。蛮荒时代之后的流程规范，规章制度其实是在保护那批没有成为英雄的人，其中就有我。

最后，给你，也给我自己一个忠告：开发人员，你最好要知道你数据库里面每一个业务参数背后的业务含义，但是千万不要去碰那该死的业务参数。也轮不到你碰，该碰的人会在正确的流程下去碰。

无论什么时候，心中都要绷着这根弦。

深入解析 effet.js：人脸识别、添加、打卡与睡眠检测的项目结构揭秘

近年来，面部识别和 AR 特效技术的普及让我们在日常应用中越来越多地接触到有趣的互动体验。而基于 facemesh.js 的二次开发框架——effet.js，则为开发者提供了一种简单而强大的方式来实现面部特效和识别功能。今天，我们将通过 effet.js 的项目结构，深入探讨其运行原理，看看它是如何利用前沿技术来实现流畅的人脸检测与交互的。

1. effet.js 的整体架构

effet.js 的项目结构采用模块化设计，通过明确的目录划分，将各项功能进行清晰地组织和封装。我们可以将项目大致分为以下几个部分：

• components：主要包括内部初始化数据、公共枚举以及管理当前 DOM 实例的逻辑。


• core：核心模块，包含动作处理、数据库交互、DOM 操作等多项功能，是整个框架的关键部分。


• styles：存放框架的样式文件，用于定义人脸特效的视觉表现。


• util：各种通用工具函数，包括摄像头操作、条件检测、绘制等常用的辅助功能。


• index.js：整个项目的入口文件，负责初始化和启动框架。

接下来，我们将详细介绍这些模块的作用及其在 effet.js 运行过程中的角色。

2. components 组件模块

components 目录主要用于存放框架的公共组件和初始化数据。

• AppState.ts：管理内部的初始化数据，包括摄像头、DOM 元素等基本信息。


• FaceManager.ts：用于管理当前 DOM 单例，这个类的作用是确保在处理消息替换时，始终对同一 DOM 元素进行操作，避免出现不必要的内存占用和资源浪费。

这种设计让 effet.js 在处理多次人脸检测和特效应用时能够高效、稳定地管理 DOM 元素。

3. core 核心模块

core 目录是 effet.js 的核心逻辑所在，涵盖了以下几个重要部分：

• action：动作处理模块，包含人脸添加、登录检测、睡眠检测和打卡等功能。例如，addFace/index.js 负责处理用户人脸添加的逻辑，而 checkLogin/index.js 则用于人脸登录的检测。


• before：动作前的预处理模块。每个动作在执行前，可能需要一些额外的检查或准备工作。例如，checkLogin/index.js 用于处理登录前的检查逻辑。


• db：数据库模块，db.js 负责使用 IndexedDB 来存储和缓存用户数据、模型信息等。这种设计让 effet.js 可以离线运行，提升了用户体验。


• defaultAssign：默认配置和参数分配模块，assign.js 用于为框架中的各个组件提供初始参数和默认值，确保框架在各种环境下均能正常运行。


• dom：DOM 操作模块，包含创建和管理人脸相关 DOM 元素的逻辑，例如 createFaceElements.js 用于动态创建人脸特效所需的 DOM 元素。


• log：用于屏蔽插件相关的内部警告信息，log.js 确保了控制台的整洁，方便开发人员进行调试。

核心模块的分层设计使得每个功能都具有独立性和可维护性，这对于复杂交互和特效的实现尤为重要。

代码示例：人脸添加动作

以下是处理人脸添加动作的代码示例：

import { addFace } from './core/action/faceAction';



// 执行人脸添加逻辑

addFace().then(() => {

  console.log('人脸添加成功');

}).catch(error => {

  console.error('人脸添加失败:', error);

});

上述代码展示了如何调用核心模块中的人脸添加逻辑来实现用户的人脸注册功能。

4. styles 样式模块

styles 目录包含所有与视觉表现相关的文件，用于定义人脸特效的外观。

• template：存放不同功能的样式模板，如 addFace 和 checkLogin 等模块中的 index.css 定义了对应特效的样式。


• faceColor.js：用于处理与人脸特效颜色相关的逻辑，让开发者可以根据需求自定义特效的颜色效果。


• root.css：全局样式文件，定义了一些基础样式和布局。

样式模块确保了特效在浏览器中展示时具有一致性和视觉吸引力。通过将样式与逻辑分离，开发者可以更方便地对特效的外观进行调整。

图片示例：人脸添加样式

5. util 通用工具模块

util 目录包含了多个工具函数，用于简化常见的任务，例如摄像头操作、距离计算和人脸网格处理。

• cameraAccessUtils.js 和 cameraUtils.js：用于处理摄像头的访问和操作，如获取摄像头权限、切换摄像头等。


• faceMesh.js：负责处理人脸网格的相关逻辑，例如通过 facemesh 模型获取人脸特征点。


• distanceUtils.js 和 drawingUtils.js：用于进行距离计算和绘图操作，这些工具函数在渲染特效时被频繁使用。

这些工具函数的存在，让开发者可以专注于高层次的功能开发，而不必担心底层的细节实现。

代码示例：摄像头访问工具

import { requestCameraAccess } from './util/cameraAccessUtils';



// 请求摄像头权限

requestCameraAccess().then(stream => {

  console.log('摄像头权限已获取');

  // 使用摄像头流进行进一步处理

}).catch(error => {

  console.error('无法获取摄像头权限:', error);

});

6. 使用 IndexedDB 的缓存机制

effet.js 通过 core/db/db.js 使用 IndexedDB 来缓存模型和其他依赖资源，从而减少每次加载的时间。这种设计可以显著提升用户体验，尤其是对于网络环境不稳定的用户。

IndexedDB 是浏览器内置的一个低级 API，它允许我们在用户设备上存储大量结构化数据。在 effet.js 中，我们利用 IndexedDB 缓存 facemesh 模型和用户的面部数据，确保在用户首次加载模型后，后续访问时能够直接从缓存中读取数据，而无需重新下载模型。这不仅提升了加载速度，还降低了对网络的依赖。

代码示例：使用 IndexedDB 缓存模型

// 缓存 facemesh 模型到 IndexedDB

async function cacheModel(modelData) {

  const db = await openIndexedDB('effetModelCache', 1);

  const transaction = db.transaction(['models'], 'readwrite');

  const store = transaction.objectStore('models');

  store.put(modelData, 'facemeshModel');

}



// 从 IndexedDB 加载模型

async function loadModelFromCache() {

  const db = await openIndexedDB('effetModelCache', 1);

  const transaction = db.transaction(['models'], 'readonly');

  const store = transaction.objectStore('models');

  return store.get('facemeshModel');

}



function openIndexedDB(dbName, version) {

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

    const request = indexedDB.open(dbName, version);

    request.onsuccess = () => resolve(request.result);

    request.onerror = () => reject(request.error);

  });

}

通过这样的缓存机制，用户在第一次访问时可能需要加载较长时间，但后续的访问速度会大大提升，从而提供更流畅的用户体验。

7. 核心模块中的预处理逻辑

在 core/before 目录下，包含了许多预处理逻辑，这些逻辑在每个动作执行之前运行，以确保后续的动作能够顺利进行。

• checkLogin/index.js：负责在执行人脸登录之前检查用户的身份信息，例如判断用户是否已经注册或存在于数据库中。


• faceBefore.js：是所有预处理逻辑的入口，通过调用不同的预处理函数，确保每个动作的执行环境和条件都已满足。

这种预处理机制有效地提高了系统的稳定性和安全性。例如，在进行人脸登录时，如果用户的数据尚未注册或缓存不完整，系统将通过预处理逻辑提前捕获这些问题并进行相应的处理。

代码示例：登录前的预处理

import { checkLogin } from './core/before/faceBefore';



// 执行登录前的检查逻辑

checkLogin().then(() => {

  console.log('预处理完成，准备执行登录动作');

}).catch(error => {

  console.error('登录预处理失败:', error);

});

8. DOM 操作和特效渲染

effet.js 中的 DOM 操作模块负责创建和管理人脸特效相关的 DOM 元素。通过对 DOM 的操作，我们可以将各种特效应用到用户的人脸上，并根据用户面部的变化来实时调整特效的位置和形状。

• createFaceElements.js：用于动态创建用于渲染特效的 DOM 元素。这些元素包括虚拟的眼镜、面具等，通过将它们附加到特定的人脸特征点，可以实现各种视觉特效。


• defaultElement.js：提供了一些默认的 DOM 元素配置，如特效的初始位置、大小和样式等。

代码示例：创建人脸特效元素

import { createFaceElements } from './core/dom/createFaceElements';



// 创建用于渲染特效的 DOM 元素

createFaceElements().then(elements => {

  console.log('特效元素创建成功', elements);

}).catch(error => {

  console.error('特效元素创建失败:', error);

});

通过将特效元素与人脸特征点绑定，我们可以实现一些有趣的交互。例如，当用户张嘴或眨眼时，系统可以检测到这些动作并触发相应的视觉反馈，从而提升用户体验的互动性。

9. 样式与用户体验

样式模块不仅仅是为了让特效看起来美观，更是为了确保其与用户的操作无缝对接。styles/template 目录下的样式模板被精心设计，以适应不同类型的设备和显示环境。

例如，addFace/index.css 和 checkLogin/index.css 分别定义了人脸添加和登录检测的样式，通过这些样式文件，开发者可以轻松地实现具有一致性且专业的用户界面。

图片示例：多种特效风格

这种模块化的样式管理方式让我们可以快速调整不同特效的外观，同时确保代码的可读性和可维护性。在不断的版本迭代中，样式模块可以独立于逻辑模块进行修改，极大地提高了项目的可扩展性。

10. effet.js 的初始化流程

index.js 作为项目的主要入口，负责初始化 effet.js 的所有模块。在初始化过程中，系统会调用核心模块、样式模块和工具函数，以确保整个框架能够无缝启动。

• initializeEffet：这是一个主函数，负责加载配置、初始化摄像头、检测用户设备是否满足要求，并调用各个核心模块来启动面部检测和特效渲染。


• FaceManager：用于管理初始化后的 DOM 元素，确保在不同的特效之间切换时，DOM 操作能够始终保持一致。

代码示例：框架初始化

import { initializeEffet } from './core/index';



// 初始化 effet.js 框架

initializeEffet().then(() => {

  console.log('effet.js 初始化完成');

}).catch(error => {

  console.error('初始化失败:', error);

});

通过这样的初始化流程，我们可以确保框架的各个部分能够正确协同工作，从而为用户提供稳定且高质量的体验。

11. 开发与优化的挑战

effet.js 在开发过程中遇到了许多挑战，例如：

• 模型加载时间长：由于 facemesh 模型文件较大，我们使用 IndexedDB 来缓存模型，减少用户每次访问的加载时间。


• 资源丢包与网络不稳定：为了解决网络环境不稳定的问题，我们采用了离线缓存策略，并通过优化加载顺序和减少请求次数来提升加载速度。


• 性能优化：为了保证在中低端设备上的流畅运行，我们对人脸检测和特效渲染进行了大量优化，包括减少计算开销、利用 WebGL 加速等。

这些挑战促使我们不断改进框架的架构和实现方式，以确保 effet.js 在不同的设备和网络环境下都能表现出色。

结语

effet.js 是一个旨在降低面部识别和特效开发门槛的框架，通过模块化的项目结构封装复杂的底层逻辑，让开发者可以专注于创造有趣的互动体验。通过组件、核心模块、样式、工具函数以及缓存机制的有机结合，effet.js 为开发者提供了强大的基础设施来构建各种人脸交互应用。

通过这篇文章，我们展示了 effet.js 的整体架构、人脸检测与特征点定位、特效渲染、交互逻辑实现以及优化挑战，并结合代码示例和图片示例来帮助你更好地理解其运行原理。希望你能够从中获得启发，创造更多有趣的应用！

如果你有任何问题或者想要进一步了解它的应用，欢迎在评论区留言讨论！

这篇博客旨在详细介绍 effet.js 的运行原理和模块化设计，帮助开发者深入了解其工作机制。在未来的开发中，我们期待更多的人参与到这个项目中来，共同探索面部识别和特效技术的更多可能性。

更多资源

• 官方文档：faceeffet.com


• GitHub 仓库：github.com/typsusan/ef…


• Gitee 仓库：gitee.com/susantyp/ef…

用于url参数转化：parse和stringify的js库

import qs from 'qs'



qs.parse('a=b&c=d');  => 转化为{ a: 'b', c: 'd'  }

qs.stringify({a: 'b', c: 'd'}) => 转化为‘a=b&c=d’

qs.parse

qs.parse 方法可以把一段格式化的字符串转换为对象格式

let url = 'http://item.taobao.com/item.htm?a=1&b=2&c=&d=xxx&e';

let data = qs.parse(url.split('?')[1]);



// data的结果是

{

    a: 1, 

    b: 2, 

    c: '', 

    d: xxx, 

    e: ''

}

qs.stringify

基本用法

qs.stringify 则和 qs.parse 相反，是把一个参数对象格式化为一个字符串。

let params = { c: 'b', a: 'd' };

qs.stringify(params)



// 结果是

'c=b&a=d'

排序

甚至可以对格式化后的参数进行排序

qs.stringify(params, (a,b) => a.localeCompare(b))



// 结果是

'a=b&c=d'

let params = { c: 'z', a: 'd' };

qs.stringify(params, {

    sort: (a, b) => a.localeCompare(b)

}); 



// 结果是  

'a=d&c=z'

指定数组编码格式

let params = [1, 2, 3];



// indices(默认)

qs.stringify({a: params}, {

    arrayFormat: 'indices'

})

// 结果是

'a[0]=1&a[1]=2&a[2]=3'



// brackets 

qs.stringify({a: params}, {

    arrayFormat: 'brackets'

})

// 结果是

'a[]=1&a[]=2&a[]=3'



// repeat

qs.stringify({a: params}, {

    arrayFormat: 'repeat'

})

// 结果是

'a=1&a=2&a=3'

处理json格式的参数

在默认情况下，json格式的参数会用 [ ] 方式编码

let json = { a: { b: { c: 'd', e: 'f' } } };



qs.stringify(json);

//结果 'a[b][c]=d&a[b][e]=f'

但是某些服务端框架，并不能很好的处理这种格式，所以需要转为下面的格式

qs.stringify(json, {allowDots: true});  

//结果 ‘a.b.c=d&a.b.e=f’

引言

一天哈比比突然冒出一个毫无理头的一个问题:

本文就该问题进行展开...

一、需求说明

大致需求如下, 当然这里做了些简化

有如下初始代码:

• 一个自适应的表格
• 每个单元格的宽度固定 200px
• 每个单元格高度则是自适应
• 每个单元格内是一个 div 标签, div 标签内包裹了一段文本, 文本内容不定

下面是初始代码(为了方便演示和美观, 代码中还加了些背景色、边距、圆角, 这些都是可以忽略):

<table>

  <tr>

    <td width="400">

      <div>

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

      div>

    td>

    <td width="400">

      <div>

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

      div>

    td>

    <td width="400">

      <div>

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

      div>

    td>

  tr>

table>

<style>

  table {

    background: #f5f5f5;

  }

  

  td {

    background: #ffccc7;

  }



  table, tr, td {

    padding: 12px;

    border-radius: 4px;

  }



  td > div {

    padding: 12px;

    border-radius: 4px;

    background: #f4ffb8;

  }

style>

上面代码的整体效果如下:

上面是哈比比目前的现状, 然后需求就是希望, 黄色部分也就是 div 标签能够高度撑满单元格(td), 也就是如下图所示:

二、关键问题

这里我第一反应就是, 既然 td 高度是对的(自适应)的那么 div 高度直接设置 100% 不就好了吗? 事实是这样的吗? 我们可以试下:

  ...

实际效果肯定是没有用的, 要不然也就不会有这篇文章了 🐶🐶🐶

主要问题: 在 CSS 中如果父元素没有一个明确的高度, 子元素设置 100% 是无法生效的, 至于为啥就不能生效呢, 因为如果可以, 那么必然会进入死循环这里可以参考张鑫旭大大的文章《从 height:100% 不支持聊聊 CSS 中的 "死循环"》

三、方案一(定位)

通过定位来实现, 也是哈比比最初采用的一个方案:

• td 设置相对定位即: position: relative;
• td 下的子元素通过相对定位(position: absolute;)撑满

....

整体效果如下:

上面代码其实我并没有给所有 td 中的 div 设置 position: absolute; 目的是为了留一个内容最多的块, 来将 tr、 td 撑开, 如果不这么做就会出现下面这种情况:

所以, 严格来说该方案是不行的, 但是可能哈比比情况比较特殊, 他只有空值和有内容两种情况, 所以他完全可以通过判断内容是否为空来设置 position: absolute; 即可

四、方案二(递归设置 height 100%)

第二个方案就是给 table、tr、td 设置一个明确的高度即 100%, 这样的话 td 中的子元素 div 再设置高度 100% 就可以生效了

效果如下:

上面第一个单元格高度其实还是有点问题, 目前也没找到相关研究可以结束这个现象, 要想达到我们要的效果解决办法有两个:

1. 移除代码中所有 padding, 有关代码和效果图如下:

2. 修改 td 中 div 的 box-sizing 属性为 border-box, 有关代码和效果图如下:

五、方案三(利用 td 自增加特效, 推荐)

方案三是比较推荐的做法, 其利用了 td 自增加的一个特效, 那么何谓自增加呢? 假设我们给 td 设置可一个高度 1px 但是呢它实际高度实际上是会根据 tr 的高度进行自适应(自动增长), 那么在这种情况下我们给 td 下子元素 div 设置高度 100% 则会奏效, 因为这时的 td 高度是明确的

<table>

  <tr>

    <td width="400">

      <div>

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

      div>

    td>

    <td width="400">

      <div>

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

      div>

    td>

    <td width="400">

      <div>

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

      div>

    td>

  tr>

table>

<style>

  table {

    background: #f5f5f5;

  }

  

  td {

    height: 1px; /* 关键代码 */

    background: #ffccc7;

  }



  table, tr, td {

    padding: 12px;

    border-radius: 4px;

  }



  td > div {

    height: 100%; /* 关键代码 */

    padding: 12px;

    border-radius: 4px;

    background: #f4ffb8;

  }

style>

效果如下:

六、补充: td 下 div 内容顶对齐

几天后, 哈比比又来找我了 🐶🐶🐶

这次需求就比较简单了, 就是 td 中默认情况下子元素(p)都是居中呈现的, 现想要的就是能否居上(置顶)展示

这里初始代码和上面是一样的:

<table>

  <tr>

    <td width="400">

      <div>

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

      div>

    td>

    <td width="400">

      <div>

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

      div>

    td>

    <td width="400">

      <div>

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

      div>

    td>

  tr>

table>

<style>

  table {

    background: #f5f5f5;

  }

  

  td {

    background: #ffccc7;

  }



  table, tr, td {

    padding: 12px;

    border-radius: 4px;

  }



  td > div {

    padding: 12px;

    border-radius: 4px;

    background: #f4ffb8;

  }

style>

默认效果就是 div 都居中展示:

这里我第一反应是用 vertical-align 但是该属性在很多人印象中只针对 行内元素(或文本)才能生效, 但这里是 div 是 块元素 所以哈比比自然就忽略了该 vertical-align 属性

但实际上如果查阅文档会发现 vertical-align 实际用途有两个:

1. 用来指定行内元素(inline)的垂直对齐方式
2. 表格单元格(table-cell)元素的垂直对齐方式

所以这个问题就简单了, 一行 CSS 就解决了:

完美实现(最终效果):

七、参考

• How to make
  fill height
• 从 height:100% 不支持聊聊 CSS 中的 "死循环"

作者：墨渊君
来源：juejin.cn/post/7436027021057884172

本文为稀土掘金技术社区首发签约文章，30天内禁止转载，30天后未获授权禁止转载，侵权必究！

前言

在基于GIS的数据可视化层面，我们能够展示的基本数据无非就是点线面体，其中，离散的点数据出现的情况相对较为普遍，通常POI（Point of Interest）的展示方式和丰富程度对于用户体验和地图的实用性有着重要的影响。在这篇技术分享文章中，我们将由浅入深地探讨如何在高德地图上创建大量立体 POI。相信通过本文的介绍，开发者能够受到启发，并且掌握这一个不错的技巧，为地图点数据的展示和应用带来新的视觉和功能体验。

需求分析

首先收集一波需求：在地图上展示大量的POI，能够配置用第三方工具制作的模型，作为POI的主体，能够实现基本的鼠标交互操作，比如鼠标悬浮状态下具有区别于其他POI的特殊的形态或者动画，每个POI能够根据自身属性出现特异的外观，再厉害一点的能不能实现固定POI在屏幕上的大小，即POI的尺寸不会随着地图缩放的远近而出现变化。

根据以上琐碎的内容我们可以整理为以下功能描述，下文我们将一步步实现这些需求：

• 支持灵活配置POI模型，POI样式可调整


• 能够支持大数据量（10000+）的POI展示


• 支持鼠标交互，能够对外派发事件


• 支持动画效果


• 支持开启一种模式，不会随地图远近缩放而改变POI的可见尺寸

实现步骤

从基础功能到进阶功能逐步完善这个POI图层，篇幅有限每个功能仅陈述开发原理以及核心代码，完整的代码工程可以到这里查看下载。

加载模型到场景中

解决大量模型的性能问题

上文的方案用来处理数据量较小的场景基本上是没有问题的，然而现实中往往有大量散点数据的情况需要处理，这时候需要THREE.InstancedMesh 出手了，InstanceMesh用于高效地渲染大量相同几何形状但具有不同位置、旋转或其他属性的物体实例，使用它可以显著提高渲染性能，尤其是在需要渲染大量相似物体的场中，比如一片森林中的树木、一群相似的物体等。