我是天元，立志做1000个有趣的项目的前端。如果你喜欢的话，请点赞，收藏，转发。评论领取零花钱+100勋章

背景

我老婆从事HR的工作，公司有很多连锁店，她需要将所有的门店的工资汇总计算，然后再拆分给各门店请确认，最后再提供给财务发工资。

随着门店数量渐渐增多，渐渐的我老婆已经不堪重负，每天加班都做不完，严重影响夫妻感情生活。

最终花费了2天的时间，完成了整个node程序，她只需要传入工资表，相应的各种表格在10s内自动输出。目前已正式交付，得到了每月零花钱提高100元的重大成果。

整体需求

• 表格的导入和识别


• 表格的计算（计算公式要代入），表格样式正确


• 最终结果按照门店拆分为工资表

需求示例（删减版）

需求为，根据传入的基本工资及补发补扣，生成总工资表，门店工资表，财务工资表发放表。

工资表中字段为门店，姓名，基本工资，补发补扣，最终工资（基本工资+补发补扣）。最后一行为总计

门店工资表按照每个门店，单独一个表格，字段同工资表。最后一行为总计

工资表

基础工资

补发补扣

技术选型

这次的主力库为exceljs，官方文档介绍如下

读取，操作并写入电子表格数据和样式到 XLSX 和 JSON 文件。

一个 Excel 电子表格文件逆向工程项目

选择exceljs是因为它支持完整的excel的样式及公式。

安装及目录结构

优先安装exceljs

npm init

yarn add exceljs

创建input,out,src三个文件夹，src放入index.js

package.json增加start脚本

"scripts": {

    "start": "node src/index.js"

  },

代码相关

导入

通过new Excel.Workbook();创建一个工作簿，通过workbook.xlsx.readFile来导入文件, 注意这是个promise

const ExcelJS = require("exceljs");

const path = require("path");

const inputPath = path.resolve(__dirname, "../input");

const outputPath = path.resolve(__dirname, "../out");



const loadInput =async () => {

  const workbook = new ExcelJS.Workbook();

  const inputFile = await workbook.xlsx.readFile(inputPath + "/工资表.xlsx")

};



loadInput()

数据拆分

通过getWorksheetApi,我们可以获取到对应的工作表的内容

  const loadInput =async () => {

	...

  // 基本工资

  const baseSalarySheet = inputFile.getWorksheet("基本工资");

  // 补发补扣

  const supplementSheet = inputFile.getWorksheet("补发补扣");



}

然后我们需要进一步的来进行拆分，因为第一行为每个工作表的头，这部分在我们实际数据处理中不会使用，所以通过getRows来获取实际的内容。

  const baseSalaryContent = baseSalarySheet.getRows(

    2,

    baseSalarySheet.rowCount

  );

  baseSalaryContent.map((row) => {

    console.log(row.values);

  });



  /**

[ <1 empty item>, '2024-02', '海贼王', '路飞', 12000 ]

[ <1 empty item>, '2024-02', '海贼王', '山治', 8000 ]

[ <1 empty item>, '2024-02', '火影忍者', '鸣人', '6000' ]

[ <1 empty item>, '2024-02', '火影忍者', '佐助', 7000 ]

[ <1 empty item>, '2024-02', '火影忍者', '雏田', 5000 ]

[ <1 empty item>, '2024-02', '一拳超人', '琦玉', 4000 ]

[]

[]

**/

可以看到实际的内容已经拿到了，我们要根据这些内容拼装一下最终便于后续的调用。

我们可以通过 row.getCellApi获取到对应某一列的内容，例如门店是在B列，那么我们就可以使用row.getCell('B')来获取。

因为我们需要拆分门店，所以这里的基本工资，我们以门店为单位，把数据进行拆分

  const baseSalary = {};



  baseSalaryContent.forEach((row) => {

    const shopName = row.getCell("B").value;

    if (!shopName) return; // 过滤空行



    const name = row.getCell("C").value;

    const salary = row.getCell("D").value;



    if (!baseSalary[shopName]) {

      baseSalary[shopName] = [];

    }

    baseSalary[shopName].push({

      name,

      salary,

    });

  });

这样我们得到了一个以门店名称为key的对象，value为该门店的员工信息数组。利用相同方法，获取补发补扣。因为每个人已经确定了门店，所以后续只需要根据姓名来做key，拆分成一个object即可

  // 补发补扣

  const supplement = {};

  supplementSheet.getRows(2, supplementSheet.rowCount).forEach((row) => {

    const name = row.getCell("C").value;

    const type = row.getCell("H").value;



    let count = row.getCell("D").value;

    // 如果为补扣，则金额为负数

    if (type === "补扣") {

      count = -count; 

    }

    if (!supplement[name]) {

      supplement[name] = 0;

    }

    supplement[name] += count;

  });



  

数据组合

门店工资表

因为每个门店需要独立一张表，所以需要遍历baseSalary

  

  Object.keys(baseSalary).forEach((shopName) => {

    const workbook = new ExcelJS.Workbook();

    const worksheet = workbook.addWorksheet("工资表");



    // 添加表头

    worksheet.addRow([

      "序号",

      "门店",

      "姓名",

      "基本工资",

      "补发补扣",

      "最终工资",

    ]);

    baseSalary[shopName].forEach((employee, index) => {

      worksheet.addRow([

        index + 1,

        shopName,

        employee.name,

        +employee.salary,

        supplement[employee.name] || 0,

        +employee.salary + (supplement[employee.name] || 0),

      ]);

    });

  });

此时你也可以快进到表格输出来查看输出的结果，以便随时调整

这样我们就把基本工资已经写入工作表了，但是这里存在问题，最终工资使用的是一个数值，而没有公式。所以我们需要改动下

 worksheet.addRow([        index + 1,        shopName,        employee.name,        employee.salary,        supplement[employee.name] || 0,

        {

          formula: `D${index + 2}+E${index + 2}`,

          result: employee.salary + (supplement[employee.name] || 0),

        },

      ]);

这里的formula将对应到公式，而result是显示的值，这个值是必须写入的，如果你写入了错误的值，会在表格中显示该值，但是双击后，公式重新计算，会替换为新的值。所以这里必须计算正确

合计

依照上方的逻辑，继续添加一行作为合计，但是之前计算的时候，需要添加一个临时变量，记录下合计的相关内容。

     const count = [0, 0, 0];

    baseSalary[shopName].forEach((employee, index) => {

      count[0] += +employee.salary;

      count[1] += supplement[employee.name] || 0;

      count[2] += +employee.salary + (supplement[employee.name] || 0);

      worksheet.addRow([

        index + 1,

        shopName,

        employee.name,

        +employee.salary,

        supplement[employee.name] || 0,

        {

          formula: `D${index + 2}+E${index + 2}`,

          result: +employee.salary + (supplement[employee.name] || 0),

        },

      ]);

    });

然后在尾部添加一行

worksheet.addRow([      "合计",      "",      "",      {        formula: `SUM(D2:D${baseSalary[shopName].length + 1})`,

        result: count[0],

      },

      {

        formula: `SUM(E2:E${baseSalary[shopName].length + 1})`,

        result: count[1],

      },

      {

        formula: `SUM(F2:F${baseSalary[shopName].length + 1})`,

        result: count[2],

      },

    ]);

美化

表格的合并，可以使用mergeCells

   worksheet.mergeCells(

      `A${baseSalary[shopName].length + 2}:C${baseSalary[shopName].length + 2}`

    );

这样就合并了我们的最后一行的前三列，接下来我们要给表格添加线条。

对于批量的添加，可以直接使用addConditionalFormatting，它将在一个符合条件的单元格范围内添加规则

    worksheet.addConditionalFormatting({

      ref: `A1:F${baseSalary[shopName].length + 2}`,

      rules: [

        {

          type: "expression",

          formulae: ["true"],

          style: {

            border: {

              top: { style: "thin" },

              left: { style: "thin" },

              bottom: { style: "thin" },

              right: { style: "thin" },

            },

            alignment: { vertical: "top", horizontal: "left", wrapText: true },

          },

        },

      ],

    });

表格输出

现在门店工资表已经拆分完成，我们可以直接保存了，使用xlsx.writeFileApi来保存文件

 Object.keys(baseSalary).forEach((shopName) => {

 

	...



	  workbook.xlsx.writeFile(outputPath + `/${shopName}工资表.xlsx`);

})

最终效果

相关代码地址

github.com/tinlee/1000…

前言

autofit.js 发布马上要一年了，也收获了一批力挺用户，截至目前它在github上有1k 的 star，npm 上有超过 13k 的下载量。

这篇文章主要讲从设计稿到落地开发大屏应用，大道至简，这篇文章能帮助各位潇洒自如的开发大屏。

分析设计稿

分析设计稿之前先吐槽一下大屏这种展现形式，这简直就是自欺欺人、面子工程的最直接的诠释，是吊用没有，只为了好看，如果设计的再不好看啊，这就纯纯是屎。在我的理解中，这就像把PPT放到了web端，仅此而已。

但是王哥告诉我："你看似没有用的东西，其实都有用，很多想真正做出有用的产品的企业，没钱，就要先把面子工程做好，告诉别人他们要做一件什么事，这样投资人才会看到，后面才有机会发展。"

布局方案

上图展示了一个传统意义上且比较普遍的大屏形态，分为四个部分，分别是

头部

头部经常放标题、功能菜单、时间、天气

左右面板

左右面板承载了各种数字和报表，还有视频、轮播图等等

中间

中间部分一般放地图，这其中又分假地图（一张图片）、图表地图（如echarts）、地图引擎（如：leaflet、mapbox、高德、百度）。或者有的还会放3D场景，一般有专门的同事去做3D场景，然后导入到web端。

大屏的设计通常的分辨率是 1920*1080 的，这也是迄今为止应用最广泛的显示器配置，当然也有基于客户屏幕做的异形分辨率，这就五花八门了。

但是万变不离其宗，分辨率的变化不会影响它的基本结构，根据上面的图，我们可以快速构建结构代码

  <div class='Box'>

    <div class="header"></div>

    <div class="body">

      <div class="leftPanel"></div>

      <div class="mainMap"></div>

      <div class="rightPanel"></div>

    </div>

  </div>

上面的代码实现了最简单的上下(Box)+左右(body)的布局结构，完全不需要任何定位策略。

要实现上图的效果，只需最简单的CSS即可完成布局。

组件方案

大屏虽然是屎，但是是一种可玩性很强的项目，想的越复杂，做起来就越复杂，想的越简单，做起来就越简单。

可以疯狂封装炫技，因为大屏里面的可玩组件简直太多了，且涵盖的太全了，想怎么玩都可以，包括但不限于 各类图表库的封装（echarts、highCharts、vChart）、轮播图（swiper）、地图引擎、视频库（包括直播流）等等。

如果想简单，甚至可以不用封装，可以看到结构甚至简单到不用CSS几行就可以搭建出基本框架，只把header、leaftPanel、rightPanel、map封装一下就可以了。

这里还有一个误区，就是大家都喜欢把 大型的组件库 拉到大屏里来用，结果做完了发现好像只用了一个 toast 和一个下拉组件，项目打包后却增大了几十倍的体积，其实像这种简单的组件，完全可以手写，或者找小的独立包来用，一方面会减小体积，不至于让项目臃肿，另一方面可以锻炼自己的手写能力，这才是有必要的封装。

适配

目前主流的适配方案，依然是 rem 方案，其原理就是根据根元素的 font-size 自动计算大小，但是此方法需要手动计算 rem 值，或者使用第三方插件如postcss等，但是此方案还有一个弊端，就是无法向下兼容，因为浏览器中最小的文字大小是12px。

vh/vw方案就不再赘述了，原理基本和 rem/em 相似，都涉及到单位的转换。

autofit.js

主要讲一下使用 autofit.js 如何快速实现适配。

不支持的场景

首先 autofit.js 不支持 elementUI(plus)、ant-design等组件库，具体是不支持包含popper.js的组件，popper.js 在计算弹出层位置时，不会考虑 scale 后的元素的视觉大小，所以会造成弹出元素的位置偏移。

其次，不支持 百度地图，百度地图对窗口缩放事件没有任何处理，有同学反馈说，即使使用了resize属性，百度地图在和autofit.js共同使用时，也会有事件热区偏移的问题。而且百度地图使用 bd-09 坐标系，和其他图商不通用，引擎的性能方面也差点意思，个人不推荐在开发中使用百度地图。

然后一些拖拽库，如甘特图插件，可能也不支持，他们在计算鼠标位置时同样没有考虑 scale 后的元素的视觉大小。

用什么单位

不支持的单位：vh、vw、rem、em

让我诧异的是，老有人问我该用什么单位，主要徘徊在 px 和 % 之间，加群的同学多数是因为用了相对单位，导致留白了。不过人各有所长，跟着各位大佬我也学到了很多。

看下图

假如有两个宽度为1000的元素，他们内部都有一个子元素，第一个用百分比设置为 width:50%;left:1% , 第二个设置为 wdith:500px;left:10px 。此时，只要外部的1000px的容器宽度不变，这两个内部元素在视觉上是一模一样的，且在实际数值上也是一模一样的，他们宽度都为500px，距离左侧10px。

但是如果外部容器变大了，来看一下效果：

在样式不变的情况下，仅改变外部容器大小，差异就出来了，由上图可知，50%的元素依然占父元素的一半，实际宽度变成了 1000px，距离左侧的实际距离变成了 20px。

这当然不难理解，百分比单位是根据 最近的、有确定大小的父级元素计算的。

所以，应该用什么单位其实取决于想做什么，举个例子：在1920*1080基础上开发，中间的地图写成了宽度为 500px ，这在正常情况下，看起来没有任何问题，它大概占屏幕的 26%，当屏幕分辨率达到4096*2160时,它在屏幕上只占 12%，看起来就是缩在一角。而当你设置宽度为26%时，无论显示器如何变化，它始终占屏幕26%。

autofit.js 所干的事，就是把1000px 变成了 2000px或者把2000px变成了1000px，并给它设置了一个合适的缩放大小。

图表、图片拉伸

背景或各种图片按需设置 object-fit: cover;即可

图表如echarts一般推荐使用百分比，且监听窗口变化事件做resize()

结语

再次感慨，大道至简，事情往往没有那么复杂，祝各位前程似锦。

迅速崛起和快速退出

时间回到2014年，此时的 Angular 1.x 习得了多种武林秘籍，左手降龙十八掌、右手六脉神剑，哦不，左手双向数据绑定、右手依赖注入、上能模块化开发、下有模板引擎 和 前端路由, 背后还有Google这个风头无两的带头大哥做技术背书，可以说集万千功能和宠爱于一身，妥妥的主角光环。

而此时的江湖，B端开发正尝到了 SPA 的甜头，积极的从传统的 MVC 开发模式转变为更为方便快捷的单页面应用开发模式，

文章同步在公众号：萌萌哒草头将军，欢迎关注！

一拍即合，强大的一站式单页面开发框架Angular自然而然，就成了公认的武林盟主，江湖一哥。

但是好景不长，2016年9月14日 Angular 2.x 的发布，彻底断送了武林盟主的宝座，

Vue：大哥，你可是真给机会呀！

2.0 使用ts彻底重写（最早支持ts的框架）、放弃了脏检查更新机制，引入了响应式系统、使用现代浏览器标准、加入装饰器语法，和 1.0 完全不兼容。可以从上图看到，此时大家基本上还不太接受ts!

新手面对陡然升高的学习曲线叫苦连连，已经入坑的开发者因为巨大的迁移工作而怨声载道。

此时，默默耕耘了两年的小弟，Vue已经拥有完备的本地化文档和丰富的可选生态，而且作为新手你只要会使用html、css、javascript，就可以上手写项目了。

所以，此时的 Vue 振臂一呼：“王侯将相宁有种乎！”，立马新皇加冕！

积极改变，三拜义父的数据驱动

忆往昔峥嵘岁月稠，恰同学少年，风华正茂；书生意气，挥斥方遒。

一转眼，angular 已经发布第19个大版本了（平均一年两个版本）。

失去武林盟主的Angular，飘零半生，未逢明主，公若不弃，Angular愿拜为义父，

从 脏检查机制 到 响应式系统，再到Signals系统， Angular 历经沧桑的数据驱动方式可以说是前端发展的缩影。

脏检查机制

脏检查机制 是通过拦截异步操作，http setTimeout 用户交互事件等，触发变更检测系统，从根组件开始检查组件中数据是否有更新，有更新时，对应的 $scope 变量会被标记为 脏，然后同步的更新dom的内容，重新开始变更检查，直到稳定后标记为干净，即通过稳定性检查！

<!DOCTYPE html>

<html lang="en" ng-app="myApp">

<head>

    <meta charset="UTF-8">

    <title>AngularJS Counter</title>

    <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.8.2/angular.min.js"></script>

</head>

<body ng-controller="CounterController as ctrl">



<h1>Count: {{ ctrl.count }}</h1>

<h2>Double Count: {{ ctrl.doubleCount() }}</h2>

<button ng-click="ctrl.increment()">+1</button>



<script>

  angular.module('myApp', [])

    .controller('CounterController', function() {

      var vm = this;

      vm.count = 0;



      vm.increment = function() {

        vm.count++;

        console.log('Latest count:', vm.count);

      };



      vm.doubleCount = function() {

        return vm.count * 2;

      };

  });

</script>

</body>

</html>

但是这种检查机制存在缺陷，例如，当数据量十分庞大时，就会触发非常多次的脏检查机制。

响应式系统

响应式系统 没有出现之前，脏检查机制 是唯一的选择，但是响应式系统凭借快速轻便的特点，立马在江湖上引起了不小的轰动，Angular也放弃了笨重的脏检查机制采用了响应式系统!

// app.component.ts

import { Component } from '@angular/core';



@Component({

  selector: 'app-root',

  template: `

    <h1>Count: {{ count }}</h1>

    <h2>Double Count: {{ doubleCount() }}</h2>

    <button (click)="increment()">+1</button>

  `,

})

export class AppComponent {

  count: number = 0;



  increment() {

    this.count++;

    console.log('Latest count:', this.count);

  }



  doubleCount() {

    return this.count * 2;

  }

}

和我们熟知的Vue的响应式不同，Angular的响应式采用双向数据流的设计，这也使得它在面对复杂项目时，性能和维护上不如Vue快捷方便。

所以，为了更好的驾驭双向数据流的响应式系统，Angular也是自创了很多绝学，例如：局部变更检测。

该绝学主要招式：组件级变更检测策略、引入zonejs、OnPush 策略等。

1. 组件级变更检测策略

每个组件都有自己的更新策略，只有组件的属性和文本发生变化时，才会触发变更检测！

2. 引入zonejs

引入zonejs拦截http setTimeout 用户交互事件等异步操作

3. OnPush 策略

默认情况下，整个组件树在变更时更新。

但是开发者可以选择 OnPush 策略，使得组件仅在输入属性发生变化、事件触发或手动调用时才进行变更检测。这进一步大大减少了变更检测的频率，适用于数据变化不频繁的场景。

Signals系统

很快啊，当SolidJS凭借优异的信号系统在江湖上闯出了响亮的名声，这时，大家才意识到，原来还有更优秀的开发方式！signal系统的开发方式，也被公认为新一代的武林绝技！

于是，Angular 16它来了，它带着signal、memo、effect三件套走来了！

当使用signal时，更新仅仅发生在当前组件。

// app.component.ts

import { Component, signal, effect, memo } from '@angular/core';



@Component({

  selector: 'app-root',

  template: `

    <h1>Count: {{ count() }}</h1>

    <h2>Double Count: {{ doubleCount() }}</h2>

    <button (click)="increment()">+1</button>

  `,

  styles: []

})

export class AppComponent {

  // 使用 signal 来管理状态

  count = signal(0);



  // 使用 memo 来计算 doubleCount

  doubleCount = memo(() => this.count() * 2);



  constructor() {

    // 使用 effect 来监听 count 的变化

    effect(() => {

      console.log('Latest count:', this.count());

    });

  }



  increment() {

    // 更新 signal 的值

    this.count.set(this.count() + 1);

  }

}

总结

Angular 虽然在国内市场一蹶不振，但是在国际市场一直默默耕耘 10 年。它作为一站式解决方案的框架，虽然牺牲了灵活性，但是也为开发者提供了沉浸式开发的选择！

且它不断创新、积极拥抱新技术的精神令人十分钦佩！

今天的内容就这些了，如果你觉得还不错，可以关注我。

如果文章中存在问题，欢迎指正！

在 JavaScript 中，使用 debugger 关键字可以在代码执行到该位置时触发断点调试。这可以帮助开发人员进行代码调试和排错。然而，有些网站开发者可能会故意使用 debugger 关键字来阻止调试，从而增加代码的安全性。但仍然有一些方法可以绕过这种防护措施，进行调试和排错。

禁用浏览器debugger

因为 debugger 其实就是对应的一个断点，它相当于用代码显示地声明了一个断点，要解除它，我们只需要禁用这个断点就好了。

禁用全局断点

全局禁用开关位于 Sources 面板的右上角，如下图所示：

点击它，该按钮会被激活，变成蓝色。

这个时候我们再重新点击一下 Resume script execution(恢复脚本执行)按钮，跳过当前断点，页面就不会再进入到无限 debugger 的状态了。

请注意，禁用所有断点可能会导致你错过一些潜在的问题或错误，因为代码将会连续执行而不会在可能的问题点停止。因此，在禁用所有断点之前，请确保你已经理解了代码的行为，并且明白在出现问题时该如何调试。

禁用局部断点

尝试使用另一种方法来跳过这个无限 debugger。在 debugger 语句所在的行的行号上单击鼠标右键，此时会出现一个快捷菜单，操作下图所示：

添加条件断点

在JS代码 debugger 行数位置的最左侧点击右键，添加条件断点（满足条件才会进入断点），将条件设置为false，就是条件永远不成立，永远不会断下来。

添加条件断点还可以监视获取一些变量信息，还是挺好用的。

如果是简单的debugger断点，直接用上边的方式就可以，如果是通过定时器触发的debugger断点，就需要进行Hook处理了。

以上的方案执行完毕之后有时候会跳转空页面，这时候只需要在空页面上打开原先地址即可。

先打开控制台

有时候我们一打开网页，就直接进入空页面，控制台上的js和html文件也随之为空，这时候需要在空白页面，或者F12等键无法打开控制台等，这种可以先打开控制台，然后再在空白页面上打开网站即可。

可以在这个网站上试一下。

替换文件

直接使用浏览器开发者工具替换修改js（Sources面板 --> Overrides），或者通过FD工具替换。

这种方式的核心思路，是替换 JS 文件中的 debugger 关键字，并保存为本地文件，在请求返回的时候、通过正则匹配等方式、拦截并替换返回的 JS 代码，以达到绕过 debugger 的目的。也可以直接删掉相关的debugger代码。

具体实现可参考：2024最新版JavaScript逆向爬虫教程-------基础篇之无限debugger的原理与绕过

快捷方案-使用油猴等插件

使用这种方法，就不需要再打 script 断点。直接安装插件即可。

参考文献

2024最新版JavaScript逆向爬虫教程-------基础篇之无限debugger的原理与绕过

解决浏览器调试无限debugger

这里我们不介绍禁止右键菜单, 禁止F12快捷键和代码混淆方案。

无限debugger

• 前端页面防止调试的方法主要是通过不断 debugger 来疯狂输出断点，因为 debugger 在控制台被打开的时候就会执行


• 由于程序被 debugger 阻止，所以无法进行断点调试，所以网页的请求也是看不到的.

基础方案

(() => {

  function ban() {

    setInterval(() => { debugger; }, 50);

  }

  try {

    ban();

  } catch (err) { }

})();

• 将 setInterval 中的代码写在一行，可以禁止用户断点，即使添加 logpoint 为 false 也无用


• 当然即使有些人想到用左下角的格式化代码，将其变成多行也是没用的

浏览器宽高

根据浏览器宽高、与打开F12后的宽高进行比对，有差值，说明打开了调试，则替换html内容；

• 通过检测窗口的外部高度和宽度与内部高度和宽度的差值，如果差值大于 200，就将页面内容设置为 "检测到非法调试"。


• 通过使用间隔为 50 毫秒的定时器，在每次间隔内执行一个函数，该函数通过创建一个包含 debugger 语句的函数，并立即调用该函数的方式来试图阻止调试器的正常使用。

(() => {

  function block() {

    if (window.outerHeight - window.innerHeight > 200 || window.outerWidth - window.innerWidth > 200) {

      document.body.innerHTML = "检测到非法调试";

    }

    setInterval(() => {

      (function () {

        return false;

      }

      ['constructor']('debugger')

      ['call']());

    }, 50);

  }

  try {

    block();

  } catch (err) { }

})();

关闭断点，调整空页面

在不打开发者工具的情况下，debugger是不会执行将页面卡住，而恰恰是利用debugger的这一点，如果你打开开发者工具一定会被debugger卡住，那么上下文时间间隔就会增加，在对时间间隔进行判断，就能巧妙的知道绝对开了开发者工具，随后直接跳转到空白页，一气呵成。(文心一言采用方案)

setInterval(function () {

  var startTime = performance.now();

  // 设置断点

  debugger;

  var endTime = performance.now();

  // 设置一个阈值，例如100毫秒

  if (endTime - startTime > 100) {

    window.location.href = 'about:blank';

  }

}, 100);

第三方插件

disable-devtool

disable-devtool可以禁用所有一切可以进入开发者工具的方法，防止通过开发者工具进行的代码搬运。

该库有以下特性:

🦂使用🦂

<script disable-devtool-auto src='https://cdn.jsdelivr.net/npm/disable-devtool'>script>

更多使用方法参见官网：disable-devtool

disable-devtool

console-ban禁止 F12 / 审查开启控制台，保护站点资源、减少爬虫和攻击的轻量方案，支持重定向、重写、自定义多种策略。

使用

<head>

  

  <script src="https://cdn.jsdelivr.net/npm/console-ban@5.0.0/dist/console-ban.min.js">script>

  <script>

    // default options

    ConsoleBan.init()

    // custom options

    ConsoleBan.init({

      redirect: '/404'

    })

  script>

head>

在项目中使用：

  yarn add console-ban

import { init } from 'console-ban'



init(options)

重定向

ConsoleBan.init({

  // 重定向至 /404 相对地址

  redirect: '/404',

  // 重定向至绝对地址

  redirect: 'http://domain.com/path'

})

使用重定向策略可以将用户指引到友好的相关信息地址（如网站介绍），亦或是纯静态 404 页面，高防的边缘计算或验证码等页面。

注：若重定向后的地址可以通过 SPA 路由切换或 pjax 局部加载技术等进行非真正意义上的页面切换，则切换后的控制台监测将不会再次生效，对于 SPA 你可以在路由卫士处重新注册本实例，其他情况请引导至真正的其他页面。

重写

var div = document.createElement('div')

div.innerHTML = '不要偷看啦~'



ConsoleBan.init({

  // 重写 body 为字符串

  write: '
 不要偷看啦~ 
',

  // 可传入节点对象

  write: div

})

重写策略可以完全阻断对网站内容的审查，但较不友好，不推荐使用。

回调函数

ConsoleBan.init({

  callback: () => {

    // ...

  }

})

回调函数支持自定义打开控制台后的策略。

参数

注：redirect、write、callback 三种策略只能取其一，优先使用回调函数。

参考文章

禁止别人调试自己的前端页面代码

前端防止恶意调试

禁止调试，阻止浏览器F12开发者工具

前端防止调试技术

结语

需要注意的是，这些技术可以增加攻击者分析和调试代码的难度，但无法完全阻止恶意调试。因此，对于一些敏感信息或关键逻辑，最好的方式是在后端进行处理，而不是完全依赖前端来保护。

下篇文章主要介绍如何破解这些禁止调试的方法。

矛与盾：⚔️不让我在控制台上调试，哼，休想🛠️

表妹问：前端好玩吗？我说好玩，但表妹接下来的回复看哭了我。

是的，回复如下：

这红海血途上，新兵举着 "大前端" 旌旗冲锋，老兵拖着node_modules残躯撤退。资本织机永不停歇，框架版本更迭如暴君换季，留下满地deprecated警告如秋后落叶。

其一、夹缝中的苦力

世人都道前端易，不过调接口、改颜色，仿佛稚童搭积木。却不知那屏幕上寸寸像素之间，皆是血泪。产品拍案，需求朝夕三变，昨日之红蓝按钮，今晨便成黑白圆角。UI稿纸翻飞如雪，设计师手持“用户体验”四字大旗，将五更赶工的代码尽数碾碎。后端端坐高台，接口文档空悬如镜花水月，待到交付时辰，方抛来残缺数据。此时节，前端便成了那补天的女娲，于混沌中捏造虚拟对象，用JSON.parse('{"data": undefined}')这等荒诞戏法，将虚无粉饰成真实。

看这段代码何等悲凉：

// 后端曰：此接口返data字段，必不为空

fetch('api/data').then(res => {

  const { data } = res;

  render(data[0].children[3].value || '默认值'); // 层层掘墓，方见白骨

});

此乃前端日常——在数据废墟里刨食，用||与?.铸成铁锹，掘出三分体面。

其二、技术的枷锁

JavaScript本是脚本小儿，如今却要扛鼎江山。君不见React、Vue、Angular三座大山压顶，每年必有新神像立起。昨日方学得Redux真经，今朝GraphQL又成显学。更有Electron、ReactNative、Flutter诸般法器，教人左手写桌面应用，右手调移动端手势。所谓“大前端”，实乃资本画饼之术，人前跨端写，人后页面仔——既要马儿跑，又言食草易。

且看这跨平台代码何等荒诞：

// 一套代码统治三界（iOS/Android/Web）

<View>

  {Platform.OS === 'web' ? 

    <div onClick={handleWebClick} /> : 

    <TouchableOpacity onPress={handleNativePress} />

  }

</View>

此类缝合怪代码，恰似给长衫打补丁，既失体统，又损性能。待到内存泄漏、渲染卡顿时，众人皆指前端曰："此子学艺不精！"

何人怜悯前端 node18 react19 逐人老，后端写着 java8 看着 java22 笑。

其三、尊严的消亡

领导提拔，必先问尔可懂SpringBoot、MySQL分库分表？纵使前端用WebGL绘出三维宇宙，用WebAssembly重写操作系统，在会议室里仍是“做界面的”。工资单上数字最是直白——同司后端新人起薪一万五，前端老将苦熬三年方摸得此数。更可笑者，产品经理醉酒时吐真言："你们不就是改改CSS么？"

再看这可视化代码何等心酸：

// 用Canvas画十万级数据点

ctx.beginPath();

dataPoints.forEach((point, i) => {

  if (i % 100 === 0) ctx.stroke(); // 分段渲染防卡死

  ctx.lineTo(point.x, point.y);

});

此等精密计算，在他人眼中不过"动画效果"，与美工修图无异。待浏览器崩溃，众人皆曰："定是前端代码劣质！"

技术大会，后端高谈微服务、分布式，高并发，满座掌声如雷，实则系统使用量百十来人也是远矣；前端言及 CSS 栅格、浏览器渲染，众人瞌睡连天。领导抚掌笑曰：“后端者，国之重器；前端者，雕虫小技。” 晋升名单，后端之名列如长蛇，前端者埋没于墙角尘埃。纵使将那界面写出花来，终是 “美工” 二字定终身。

其四、维护者的悲歌

JavaScript本无类型，如野马脱缰。若非经验老道之一，常写出这等代码：

function handleData(data) {

  if (data && typeof data === 'object') { // 万能判断

    return data.map(item => ({

      ...item,

      newProp: item.id * Math.random() // 魔改数据

    }));

  }

  return []; // 默认返回空阵，埋下百处报错

}

此类代码如瘟疫蔓延，领导却言“这些功能实习生也能写！”，却不顾三月后连作者亦不敢相认，只得下任前端难上加难。

而后端有Type大法，编译检查护体，有Swagger契约，有Docker容器，纵使代码如乱麻，只需扩内存、增实例，便可遮掩性能疮疤。

其五、末路者的自白

诸君且看这招聘启事："需精通Vue3+TS+Webpack，熟悉React/Node.js，有Electron/小程序经验，掌握Three.js/WebGL者重点考虑。" 薪资却标着"6-8K"。更有机智者发明"全栈"之名，实欲以一人之躯，承三头六臂之劳。

再看这面试题何等荒谬：

// 手写Promise实现A+规范

class MyPromise {

  // 三千行后，方知自己仍是蝼蚁

}

此等屠龙之术，入职后唯调API用。恰似逼庖丁解牛，却令其日日杀鸡。

或以使用组件库之经验薪资招之，又以写不好组件库之责裁出。

尾声：铁屋中的叩问

前端者，数字化时代的纺织工也。资本织机日夜轰鸣，框架如梭穿行不息。程序员眼底血丝如网。所谓"全栈工程师"，实为包身工雅称；所谓"技术革新"，不过剥削新法。

若仍有少年热血未冷，欲投身此业，且听我一言：君有凌云志，何不学Rust/C++，做那操作系统、数据库等真·屠龙技？莫要困在这CSS牢笼中，为圆角像素折腰，为虚无需求焚膏。前端之路，已是红海血途，望后来者三思，三思！

大家好，我是 Java陈序员。

由于为了生活奔波，常年在外，导致很多关系稍疏远的亲戚之间来往并不多。

因此节假日回家时，往往会搞不清楚哪位亲戚应该喊什么称呼，很容易“社死”。

今天给大家介绍一个亲戚关系计算器，让你快速的计算出正确的亲戚称谓！

关注微信公众号：【Java陈序员】，获取开源项目分享、AI副业分享、超200本经典计算机电子书籍等。

项目介绍

relationship —— 中国亲戚关系计算器，只需简单的输入即可算出称谓。

输入框兼容了不同的叫法，你可以称呼父亲为：“老爸”、“爹地”、“老爷子”等等，方便不同地域的习惯叫法。

快捷输入按键，只需简单的点击即可完成关系输入，算法还支持逆向查找称呼哦～

功能特色：

• 使用别称查询：姥姥的爸爸的老窦 = 外曾外曾祖父


• 使用合称查询：姐夫的双亲 = 姊妹姻父 / 姊妹姻母


• 大小数字混合查询：大哥的二姑妈的七舅姥爷 = 舅曾外祖父


• 不限制祖辈孙辈跨度查询：舅妈的婆婆的外甥的姨妈的侄子 = 舅表舅父


• 根据年龄推导可能性：哥哥的表姐 = 姑表姐 / 舅表姐


• 根据语境确认性别：老婆的女儿的外婆 = 岳母


• 支持古文式表达：吾父之舅父 = 舅爷爷


• 解析某称谓关系链：七舅姥爷 = 妈妈的妈妈的兄弟


• 算两个亲戚间的合称关系：奶奶 + 外婆 = 儿女亲家

项目地址：

https://github.com/mumuy/relationship

在线体验：

https://passer-by.com/relationship/

移动端体验地址：

https://passer-by.com/relationship/vue/

功能体验

1、关系找称呼

2、称呼找关系

3、两者间关系

4、两者的合称

安装使用

1、直接引入安装

<script src="https://passer-by.com/relationship/dist/relationship.min.js">

获取全局方法 relationship.

2、使用 npm 包管理安装

安装依赖：

npm install relationship.js

包引入：

// CommonJS 引入

const relationship = require("relationship.js");

// ES Module 引入

import relationship from 'relationship.js';

3、使用方法：唯一的计算方法 relationship.

• 选项模式 relationship(options)
  
  

  构造函数：

  
  

  var options = {
  
      text:'',		// 目标对象：目标对象的称谓汉字表达，称谓间用‘的’字分隔
  
      target:'',	    // 相对对象：相对对象的称谓汉字表达，称谓间用‘的’字分隔，空表示自己
  
      sex:-1,			// 本人性别：0表示女性,1表示男性
  
      type:'default',	// 转换类型：'default'计算称谓,'chain'计算关系链,'pair'计算关系合称
  
      reverse:false,	// 称呼方式：true对方称呼我,false我称呼对方
  
      mode:'default',	// 模式选择：使用setMode方法定制不同地区模式，在此选择自定义模式
  
      optimal:false,  // 最短关系：计算两者之间的最短关系
  
  };
  
  

  
  

  代码示例：

  
  

  // 如：我应该叫外婆的哥哥什么？
  
  relationship({text:'妈妈的妈妈的哥哥'});
  
  // => ['舅外公']
  
  
  
  // 如：七舅姥爷应该叫我什么？
  
  relationship({text:'七舅姥爷',reverse:true,sex:1});
  
  // => ['甥外孙']
  
  
  
  // 如：舅公是什么亲戚
  
  relationship({text:'舅公',type:'chain'});
  
  // => ['爸爸的妈妈的兄弟', '妈妈的妈妈的兄弟', '老公的妈妈的兄弟']
  
  
  
  // 如：舅妈如何称呼外婆？
  
  relationship({text:'外婆',target:'舅妈',sex:1});
  
  // => ['婆婆']
  
  
  
  // 如：外婆和奶奶之间是什么关系？
  
  relationship({text:'外婆',target:'奶奶',type:'pair'});
  
  // => ['儿女亲家']
  
  

  
  


• 语句模式 relationship(exptession)
  
  

  
  

  参数 exptession 句式可以为：xxx是xxx的什么人、xxx叫xxx什么、xxx如何称呼xxx等。

  
  

  
  

  代码示例：

  
  

  // 如：舅妈如何称呼外婆？
  
  relationship('舅妈如何称呼外婆？');
  
  // => ['婆婆']
  
  
  
  // 如：外婆和奶奶之间是什么关系？
  
  relationship('外婆和奶奶之间是什么关系？');
  
  // => ['儿女亲家']
  
  

  
  

4、其他 API

// 获取当前数据表 

relationship.data



// 获取当前数据量 

relationship.dataCount



// 用户自定义模式 

relationship.setMode(mode_name,mode_data)

最后

推荐的开源项目已经收录到 GitHub 项目，欢迎 Star：

https://github.com/chenyl8848/great-open-source-project

或者访问网站，进行在线浏览：

https://chencoding.top:8090/#/

大家的点赞、收藏和评论都是对作者的支持，如文章对你有帮助还请点赞转发支持下，谢谢！

前言

在家没事的时候刷抖音玩，抖音首页的视频怎么刷也刷不完，经常不知不觉的一刷就到半夜了😅

不禁感叹道 ＂垃圾抖音，费我时间，毁我青春😅＂

这是我的 模仿抖音 系列文章的第二篇，本文将一步步实现抖音首页 视频无限滑动 的效果，干货满满

第一篇：200行代码实现类似Swiper.js的轮播组件

第三篇：Vue 路由使用介绍以及添加转场动画

第四篇：Vue 有条件路由缓存，就像传统新闻网站一样

第五篇：Github Actions 部署 Pages、同步到 Gitee、翻译 README 、 打包 docker 镜像

如果您对滑动原理不太熟悉，推荐先看我的这篇文章：200行代码实现类似Swiper.js的轮播组件

最终效果

在线预览：dy.ttentau.top/

Github地址：github.com/zyronon/dou…

源码：SlideVerticalInfinite.vue

实现原理

无限滑动的原理和虚拟滚动的原理差不多，要保持 SlideList 里面永远只有 N 个 SlideItem，就要在滑动时不断的删除和增加 SlideItem。

滑动时调整 SlideList 的偏移量 translateY 的值，以及列表里那几个 SlideItem 的 top 值，就可以了

为什么要调整 SlideList 的偏移量 translateY 的值同时还要调整 SlideItem 的 top 值呢？

因为 translateY 只是将整个列表移动，如果我们列表里面的元素是固定的，不会变多和减少，那么没关系，只调整　translateY 值就可以了，上滑了几页就减几页的高度，下滑同理

但是如果整个列表向前移动了一页，同时前面的 SlideItem 也少了一个，，那么最终效果就是移动了两页...因为 塌陷 了一页

这显然不是我们想要的，所以我们还需要同时调整 SlideItem 的 top 值，加上前面少的 SlideItem 的高度，这样才能显示出正常的内容

步骤

定义

virtualTotal：页面中同时存在多少个 SlideItem，默认为 5。

//页面中同时存在多少个SlideItem

virtualTotal: {

  type: Number,

  default: () => 5

},

设置这个值可以让外部组件使用时传入，毕竟每个人的需求不同，有的要求同时存在 10 条，有的要求同时存在 5 条即可。

不过同时存在的数量越大，使用体验就越好，即使用户快速滑动，我们依然有时间处理。

如果只同时存在 5 条，用户只需要快速滑动两次就到底了(因为屏幕中显示第 3 条，刚开始除外)，我们可能来不及添加新的视频到最后

render：渲染函数，SlideItem内显示什么由render返回值决定

render: {

  type: Function,

  default: () => {

    return null

  }

},

之所以要设定这个值，是因为抖音首页可不只有视频，还有图集、推荐用户、广告等内容，所以我们不能写死显示视频。

最好是定义一个方法，外部去实现，我们内部去调用，拿到返回值，添加到 SlideList 中

list：数据列表，外部传入

list: {

  type: Array,

  default: () => {

    return []

  }

},

我们从 list 中取出数据，然后调用并传给 render 函数，将其返回值插入到 SlideList中

初始化

watch(

  () => props.list,

  (newVal, oldVal) => {

    //新数据长度比老数据长度小，说明是刷新

    if (newVal.length < oldVal.length) {

      //从list中取出数据，然后调用并传给render函数，将其返回值插入到SlideList中

      insertContent()

    } else {

      //没数据就直接插入

      if (oldVal.length === 0) {

        insertContent()

      } else {

        // 走到这里，说明是通过接口加载了下一页的数据，

        // 为了在用户快速滑动时，无需频繁等待请求接口加载数据，给用户更好的使用体验

        // 这里额外加载3条数据。所以此刻，html里面有原本的5个加新增的3个，一共8个dom

        // 用户往下滑动时只删除前面多余的dom，等滑动到临界值（virtualTotal/2+1）时，再去执行新增逻辑

      }

    }

  }

)

用 watch 监听 list 是因为它一开始不一定有值，通过接口请求之后才有值

同时当我们下滑 加载更多 时，也会触发接口请求新的数据，用 watch 可以在有新数据时，多添加几条到 SlideList 的最后面，这样用户快速滑动也不怕了

如何滑动

这里就不再赘述，参考我的这篇文章：200行代码实现类似Swiper.js的轮播组件

滑动结束

判断滑动的方向

当我们向上滑动时,需要删除最前面的 dom ，然后在最后面添加一个 dom

下滑时反之

slideTouchEnd(e, state, canNext, (isNext) => {

  if (props.list.length > props.virtualTotal) {

    //手指往上滑(即列表展示下一条视频)

    if (isNext) {

      //删除最前面的 `dom` ，然后在最后面添加一个 `dom`  

    } else {

      //删除最后面的 `dom` ，然后在最前面添加一个 `dom`  

    }

  }

})

手指往上滑(即列表展示下一条视频)

• 首先判断是否要加载更多，快到列表末尾时就要加载更多数据了


• 再判断是否符合 腾挪 的条件，即当前位置要大于 half，且小于列表长度减 half。


• 在最后面添加一个 dom


• 删除最前面的 dom


• 将所有 dom 设置为最新的 top 值(原因前面有讲，因为删除了最前面的 dom，导致塌陷一页，所以要加上删除 dom 的高度)

let half = (props.virtualTotal - 1) / 2



//删除最前面的 `dom` ，然后在最后面添加一个 `dom`  

if (state.localIndex > props.list.length - props.virtualTotal && state.localIndex > half) {

  emit('loadMore')

}



//是否符合 `腾挪` 的条件

if (state.localIndex > half && state.localIndex < props.list.length - half) {

  //在最后面添加一个 `dom`  

  let addItemIndex = state.localIndex + half

  let res = slideListEl.value.querySelector(`.${itemClassName}[data-index='${addItemIndex}']`)

  if (!res) {

    slideListEl.value.appendChild(getInsEl(props.list[addItemIndex], addItemIndex))

  }



  //删除最前面的 `dom` 

  let index = slideListEl.value

    .querySelector(`.${itemClassName}:first-child`)

    .getAttribute('data-index')

  appInsMap.get(Number(index)).unmount()



  slideListEl.value.querySelectorAll(`.${itemClassName}`).forEach((item) => {

    _css(item, 'top', (state.localIndex - half) * state.wrapper.height)

  })

}

手指往下滑(即列表展示上一条视频)

逻辑和上滑都差不多，不过是反着来而已

• 再判断是否符合 腾挪 的条件，和上面反着


• 在最前面添加一个 dom


• 删除最后面的 dom


• 将所有 dom 设置为最新的 top 值

//删除最后面的 `dom` ，然后在最前面添加一个 `dom`

if (state.localIndex >= half && state.localIndex < props.list.length - (half + 1)) {

  let addIndex = state.localIndex - half

  if (addIndex >= 0) {

    let res = slideListEl.value.querySelector(`.${itemClassName}[data-index='${addIndex}']`)

    if (!res) {

      slideListEl.value.prepend(getInsEl(props.list[addIndex], addIndex))

    }

  }

  let index = slideListEl.value

    .querySelector(`.${itemClassName}:last-child`)

    .getAttribute('data-index')

  appInsMap.get(Number(index)).unmount()



  slideListEl.value.querySelectorAll(`.${itemClassName}`).forEach((item) => {

    _css(item, 'top', (state.localIndex - half) * state.wrapper.height)

  })

}

其他问题

为什么不直接用 v-for直接生成 SlideItem 呢?

如果内容不是视频就可以。要删除或者新增时，直接操作 list 数据源，这样省事多了

如果内容是视频，修改 list 时，Vue 会快速的替换 dom，正在播放的视频，突然一下从头开始播放了😅😅😅

如何获取 Vue 组件的最终 dom

有两种方式，各有利弊

• 用 Vue 的 render 方法
  
  
  
  • 优点：只是渲染一个 VNode 而已，理论上讲内存消耗更少。
  
  
  • 缺点：但我在开发中，用了这个方法，任何修改都会刷新页面，有点难蚌😅
  
  
  
  


• 用 Vue 的 createApp 方法再创建一个 Vue 的实例
  
  
  
  • 和上面相反😅
  
  
  
  

import { createApp, onMounted, reactive, ref, render as vueRender, watch } from 'vue'



/**

 * 获取Vue组件渲染之后的dom元素

 * @param item

 * @param index

 * @param play

 */

function getInsEl(item, index, play = false) {

  // console.log('index', cloneDeep(item), index, play)

  let slideVNode = props.render(item, index, play, props.uniqueId)

  const parent = document.createElement('div')

  //TODO 打包到线上时用这个，这个在开发时任何修改都会刷新页面

  if (import.meta.env.PROD) {

    parent.classList.add('slide-item')

    parent.setAttribute('data-index', index)

    //将Vue组件渲染到一个div上

    vueRender(slideVNode, parent)

    appInsMap.set(index, {

      unmount: () => {

        vueRender(null, parent)

        parent.remove()

      }

    })

    return parent

  } else {

    //创建一个新的Vue实例，并挂载到一个div上

    const app = createApp({

      render() {

        return <SlideItem data-index={index}>{slideVNode}</SlideItem>

      }

    })

    const ins = app.mount(parent)

    appInsMap.set(index, app)

    return ins.$el

  }

}

总结

原理其实并不难。主要是一开始可能会用 v-for 去弄，折腾半天发现不行。v-for 不行，就只能想想怎么把 Vue 组件搞到 html 里面去，又去研究如何获取 Vue 组件的最终 dom，又查了半天资料，Vue 官方文档也不写，还得去翻 api ，麻了

结束

以上就是文章的全部内容，感谢看到这里，希望对你有所帮助或启发！创作不易，如果觉得文章写得不错，可以点赞收藏支持一下，也欢迎关注我的公众号 前端张余让，我会更新更多实用的前端知识与技巧，期待与你共同成长~

需求

先来看这样一个场景，拿一个网站举例

这里有一个常见的网站 banner 图容器，大小为为1910*560，看起来背景图完美的充满了宽度，但是图片原始大小时，却是：

它的宽度只有 1440，且 background-size 设置的是 contain ，即等比例缩放，那么可以断定它两边的蓝色是依靠背景色填充的。

那么问题来了，这是一个 轮播banner，如果希望添加一张不是蓝色的图片呢？难道要给每张图片提前标注好背景颜色吗？这显然是非常死板的做法。

所以需要从图片中提取到图片的主题色，当然这对于 js 来说，也不是什么难事，市面上已经有众多的开源库供我们使用。

探索

首先在网络上找到了以下几个库：

• color-thief 这是一款基于 JavaScript 和 Canvas 的工具，能够从图像中提取主要颜色或代表性的调色板


• vibrant.js 该插件是 Android 支持库中 Palette 类的 JavaScript 版本，可以从图像中提取突出的颜色


• rgbaster.js 这是一段小型脚本，可以获取图片的主色、次色等信息，方便实现一些精彩的 Web 交互效果

我取最轻量化的 rgbaster.js（此库非常搞笑，用TS编写，npm 包却没有指定 types） 来测试后发现，它给我在一个渐变色图片中，返回了七万多个色值，当然，它准确的提取出了面积最大的色值，但是这个色值不是图片边缘的颜色，导致设置为背景色后，并不能完美的融合。

另外的插件各位可以参考这几篇文章：

• 文章1：blog.csdn.net/weixin_4299…


• 文章2：juejin.cn/post/684490…


• 文章3：http://www.zhangxinxu.com/wordpress/2…

可以发现，这些插件主要功能就是取色，并没有考虑实际的应用场景，对于一个图片颜色分析工具来说，他们做的很到位，但是在大多数场景中，他们往往是不适用的。

在文章 2 中，作者对比了三款插件对于图片容器背景色的应用，看起来还是 rgbaster 效果好一点，但是我们刚刚也拿他试了，它并不能适用于颜色复杂度高的、渐变色的图片。

思考

既然又又又没有人做这件事，正所谓我不入地狱谁入地狱，我手写一个

整理一下需求，我发现我希望得到的是：

这样一来，就已经可以覆盖大部分需求了，1+2 可以生成相关的 主题 TAG、主题背景，3 可以使留白的图片容器完美融合。

开搞

⚠⚠ 本小节内容非常硬核，如果不想深究原理可以直接跳过，文章末尾有用法和效果图 ⚠⚠

思路

首先需要避免上面提到的插件的缺点，即对渐变图片要做好处理，不能取出成千上万的颜色，体验太差且实用性不强，对于渐变色还有一点，即在渐变路径上，每一点的颜色都是不一样的，所以需要将他们以一个阈值分类，挑选出一众相近色，并计算出一个平均色，这样就不会导致主题色太精准进而没有代表性。

对于背景色，需要按情况分析，如果只是希望做一个协调的页面，那么大可以直接使用主题色做渐变过渡或蒙层，也就是类似于这种效果

但是如果希望背景与图片完美衔接，让人看不出图片边界的感觉，就需要单独对边缘颜色取色了。

最后一个问题，如果图片分辨率过大，在遍历像素点时会非常消耗性能，所以需要降低采样率，虽然会导致一些精度上的丢失，但是调整为一个合适的值后应该基本可用。

剩余的细节问题，我会在下面的代码中解释

使用 JaveScript 编码

接下来我将详细描述 autohue.js 的实现过程，由于本人对色彩科学不甚了解，如有解释不到位或错误，还请指出。

首先编写一个入口主函数，我目前考虑到的参数应该有：

export default async function colorPicker(imageSource: HTMLImageElement | string, options?: autoColorPickerOptions)

type thresholdObj = { primary?: number; left?: number; right?: number; top?: number; bottom?: number }

interface autoColorPickerOptions {

  /**

   * - 降采样后的最大尺寸（默认 100px）

   * - 降采样后的图片尺寸不会超过该值，可根据需求调整

   * - 降采样后的图片尺寸越小，处理速度越快，但可能会影响颜色提取的准确性

   **/

  maxSize?: number

  /**

   * - Lab 距离阈值（默认 10）

   * - 低于此值的颜色归为同一簇，建议 8~12

   * - 值越大，颜色越容易被合并，提取的颜色越少

   * - 值越小，颜色越容易被区分，提取的颜色越多

   **/

  threshold?: number | thresholdObj

}

概念解释 Lab ，全称：CIE L*a*b ，CIE L*a*b* 是CIE XYZ色彩模式的改进型。它的“L”（明亮度），“a”（绿色到红色）和“b”（蓝色到黄色）代表许多的值。与XYZ比较，CIE L*a*b*的色彩更适合于人眼感觉的色彩，正所谓感知均匀

然后需要实现一个正常的 loadImg 方法，使用 canvas 异步加载图片

function loadImage(imageSource: HTMLImageElement | string): Promise<HTMLImageElement> {

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

    let img: HTMLImageElement

    if (typeof imageSource === 'string') {

      img = new Image()

      img.crossOrigin = 'Anonymous'

      img.src = imageSource

    } else {

      img = imageSource

    }

    if (img.complete) {

      resolve(img)

    } else {

      img.onload = () => resolve(img)

      img.onerror = (err) => reject(err)

    }

  })

}

这样我们就获取到了图片对象。

然后为了图片过大，我们需要进行降采样处理

// 利用 Canvas 对图片进行降采样，返回 ImageData 对象

function getImageDataFromImage(img: HTMLImageElement, maxSize: number = 100): ImageData {

  const canvas = document.createElement('canvas')

  let width = img.naturalWidth

  let height = img.naturalHeight

  if (width > maxSize || height > maxSize) {

    const scale = Math.min(maxSize / width, maxSize / height)

    width = Math.floor(width * scale)

    height = Math.floor(height * scale)

  }

  canvas.width = width

  canvas.height = height

  const ctx = canvas.getContext('2d')

  if (!ctx) {

    throw new Error('无法获取 Canvas 上下文')

  }

  ctx.drawImage(img, 0, 0, width, height)

  return ctx.getImageData(0, 0, width, height)

}

概念解释，降采样：降采样（Downsampling）是指在图像处理中，通过减少数据的采样率或分辨率来降低数据量的过程。具体来说，就是在保持原始信息大致特征的情况下，减少数据的复杂度和存储需求。这里简单理解为将图片强制压缩为 100*100 以内，也是 canvas 压缩图片的常见做法。

得到图像信息后，就可以对图片进行像素遍历处理了，正如思考中提到的，我们需要对相近色提取并取平均色，并最终获取到主题色、次主题色。

那么问题来了，什么才算相近色，对于这个问题，在 常规的 rgb 中直接计算是不行的，因为它涉及到一个感知均匀的问题

概念解释，感知均匀：XYZ系统和在它的色度图上表示的两种颜色之间的距离与颜色观察者感知的变化不一致，这个问题叫做感知均匀性(perceptual uniformity)问题，也就是颜色之间数字上的差别与视觉感知不一致。由于我们需要在颜色簇中计算出平均色，那么对于人眼来说哪些颜色是相近的？此时，我们需要把 sRGB 转化为 Lab 色彩空间（感知均匀的），再计算其欧氏距离，在某一阈值内的颜色，即可认为是相近色。

所以我们首先需要将 rgb 转化为 Lab 色彩空间

// 将 sRGB 转换为 Lab 色彩空间

function rgbToLab(r: number, g: number, b: number): [number, number, number] {

  let R = r / 255,

    G = g / 255,

    B = b / 255

  R = R > 0.04045 ? Math.pow((R + 0.055) / 1.055, 2.4) : R / 12.92

  G = G > 0.04045 ? Math.pow((G + 0.055) / 1.055, 2.4) : G / 12.92

  B = B > 0.04045 ? Math.pow((B + 0.055) / 1.055, 2.4) : B / 12.92



  let X = R * 0.4124 + G * 0.3576 + B * 0.1805

  let Y = R * 0.2126 + G * 0.7152 + B * 0.0722

  let Z = R * 0.0193 + G * 0.1192 + B * 0.9505



  X = X / 0.95047

  Y = Y / 1.0

  Z = Z / 1.08883



  const f = (t: number) => (t > 0.008856 ? Math.pow(t, 1 / 3) : 7.787 * t + 16 / 116)

  const fx = f(X)

  const fy = f(Y)

  const fz = f(Z)

  const L = 116 * fy - 16

  const a = 500 * (fx - fy)

  const bVal = 200 * (fy - fz)

  return [L, a, bVal]

}

这个函数使用了看起来很复杂的算法，不必深究，这是它的大概解释：

接下来实现聚类算法

/**

 * 对满足条件的像素进行聚类

 * @param imageData 图片像素数据

 * @param condition 判断像素是否属于指定区域的条件函数（参数 x, y）

 * @param threshold Lab 距离阈值，低于此值的颜色归为同一簇，建议 8~12

 */

function clusterPixelsByCondition(imageData: ImageData, condition: (x: number, y: number) => boolean, threshold: number = 10): Cluster[] {

  const clusters: Cluster[] = []

  const data = imageData.data

  const width = imageData.width

  const height = imageData.height

  for (let y = 0; y < height; y++) {

    for (let x = 0; x < width; x++) {

      if (!condition(x, y)) continue

      const index = (y * width + x) * 4

      if (data[index + 3] === 0) continue // 忽略透明像素

      const r = data[index]

      const g = data[index + 1]

      const b = data[index + 2]

      const lab = rgbToLab(r, g, b)

      let added = false

      for (const cluster of clusters) {

        const d = labDistance(lab, cluster.averageLab)

        if (d < threshold) {

          cluster.count++

          cluster.sumRgb[0] += r

          cluster.sumRgb[1] += g

          cluster.sumRgb[2] += b

          cluster.sumLab[0] += lab[0]

          cluster.sumLab[1] += lab[1]

          cluster.sumLab[2] += lab[2]

          cluster.averageRgb = [cluster.sumRgb[0] / cluster.count, cluster.sumRgb[1] / cluster.count, cluster.sumRgb[2] / cluster.count]

          cluster.averageLab = [cluster.sumLab[0] / cluster.count, cluster.sumLab[1] / cluster.count, cluster.sumLab[2] / cluster.count]

          added = true

          break

        }

      }

      if (!added) {

        clusters.push({

          count: 1,

          sumRgb: [r, g, b],

          sumLab: [lab[0], lab[1], lab[2]],

          averageRgb: [r, g, b],

          averageLab: [lab[0], lab[1], lab[2]]

        })

      }

    }

  }

  return clusters

}

函数内部有一个 labDistance 的调用，labDistance 是计算 Lab 颜色空间中的欧氏距离的

// 计算 Lab 空间的欧氏距离

function labDistance(lab1: [number, number, number], lab2: [number, number, number]): number {

  const dL = lab1[0] - lab2[0]

  const da = lab1[1] - lab2[1]

  const db = lab1[2] - lab2[2]

  return Math.sqrt(dL * dL + da * da + db * db)

}

概念解释，欧氏距离：Euclidean Distance，是一种在多维空间中测量两个点之间“直线”距离的方法。这种距离的计算基于欧几里得几何中两点之间的距离公式，通过计算两点在各个维度上的差的平方和，然后取平方根得到。欧氏距离是指n维空间中两个点之间的真实距离，或者向量的自然长度（即该点到原点的距离）。

总的来说，这个函数采用了类似 K-means 的聚类方式，将小于用户传入阈值的颜色归为一簇，并取平均色(使用 Lab 值)。

概念解释，聚类算法：Clustering Algorithm 是一种无监督学习方法，其目的是将数据集中的元素分成不同的组（簇），使得同一组内的元素相似度较高，而不同组之间的元素相似度较低。这里是将相近色归为一簇。

概念解释，颜色簇：簇是聚类算法中一个常见的概念，可以大致理解为 "一类"

得到了颜色簇集合后，就可以按照count大小来判断哪个是主题色了

  // 对全图所有像素进行聚类

  let clusters = clusterPixelsByCondition(imageData, () => true, threshold.primary)

  clusters.sort((a, b) => b.count - a.count)

  const primaryCluster = clusters[0]

  const secondaryCluster = clusters.length > 1 ? clusters[1] : clusters[0]

  const primaryColor = rgbToHex(primaryCluster.averageRgb)

  const secondaryColor = rgbToHex(secondaryCluster.averageRgb)

现在我们已经获取到了主题色、次主题色 🎉🎉🎉

接下来，我们继续计算边缘颜色

按照同样的方法，只是把阈值设小一点，我这里直接设置为 1 （threshold.top 等都是1）

  // 分别对上、右、下、左边缘进行聚类

  const topClusters = clusterPixelsByCondition(imageData, (_x, y) => y < margin, threshold.top)

  topClusters.sort((a, b) => b.count - a.count)

  const topColor = topClusters.length > 0 ? rgbToHex(topClusters[0].averageRgb) : primaryColor



  const bottomClusters = clusterPixelsByCondition(imageData, (_x, y) => y >= height - margin, threshold.bottom)

  bottomClusters.sort((a, b) => b.count - a.count)

  const bottomColor = bottomClusters.length > 0 ? rgbToHex(bottomClusters[0].averageRgb) : primaryColor



  const leftClusters = clusterPixelsByCondition(imageData, (x, _y) => x < margin, threshold.left)

  leftClusters.sort((a, b) => b.count - a.count)

  const leftColor = leftClusters.length > 0 ? rgbToHex(leftClusters[0].averageRgb) : primaryColor



  const rightClusters = clusterPixelsByCondition(imageData, (x, _y) => x >= width - margin, threshold.right)

  rightClusters.sort((a, b) => b.count - a.count)

  const rightColor = rightClusters.length > 0 ? rgbToHex(rightClusters[0].averageRgb) : primaryColor

这样我们就获取到了上下左右四条边的颜色 🎉🎉🎉

这样大致的工作就完成了，最后我们将需要的属性导出给用户，我们的主函数最终长这样：

/**

 * 主函数：根据图片自动提取颜色

 * @param imageSource 图片 URL 或 HTMLImageElement

 * @returns 返回包含主要颜色、次要颜色和背景色对象（上、右、下、左）的结果

 */

export default async function colorPicker(imageSource: HTMLImageElement | string, options?: autoColorPickerOptions): Promise<AutoHueResult> {

  const { maxSize, threshold } = __handleAutoHueOptions(options)

  const img = await loadImage(imageSource)

  // 降采样（最大尺寸 100px，可根据需求调整）

  const imageData = getImageDataFromImage(img, maxSize)



  // 对全图所有像素进行聚类

  let clusters = clusterPixelsByCondition(imageData, () => true, threshold.primary)

  clusters.sort((a, b) => b.count - a.count)

  const primaryCluster = clusters[0]

  const secondaryCluster = clusters.length > 1 ? clusters[1] : clusters[0]

  const primaryColor = rgbToHex(primaryCluster.averageRgb)

  const secondaryColor = rgbToHex(secondaryCluster.averageRgb)



  // 定义边缘宽度（单位像素）

  const margin = 10

  const width = imageData.width

  const height = imageData.height



  // 分别对上、右、下、左边缘进行聚类

  const topClusters = clusterPixelsByCondition(imageData, (_x, y) => y < margin, threshold.top)

  topClusters.sort((a, b) => b.count - a.count)

  const topColor = topClusters.length > 0 ? rgbToHex(topClusters[0].averageRgb) : primaryColor



  const bottomClusters = clusterPixelsByCondition(imageData, (_x, y) => y >= height - margin, threshold.bottom)

  bottomClusters.sort((a, b) => b.count - a.count)

  const bottomColor = bottomClusters.length > 0 ? rgbToHex(bottomClusters[0].averageRgb) : primaryColor



  const leftClusters = clusterPixelsByCondition(imageData, (x, _y) => x < margin, threshold.left)

  leftClusters.sort((a, b) => b.count - a.count)

  const leftColor = leftClusters.length > 0 ? rgbToHex(leftClusters[0].averageRgb) : primaryColor



  const rightClusters = clusterPixelsByCondition(imageData, (x, _y) => x >= width - margin, threshold.right)

  rightClusters.sort((a, b) => b.count - a.count)

  const rightColor = rightClusters.length > 0 ? rgbToHex(rightClusters[0].averageRgb) : primaryColor



  return {

    primaryColor,

    secondaryColor,

    backgroundColor: {

      top: topColor,

      right: rightColor,

      bottom: bottomColor,

      left: leftColor

    }

  }

}

还记得本小节一开始提到的参数吗，你可以自定义 maxSize（压缩大小，用于降采样）、threshold（阈值，用于设置簇大小）

为了用户友好，我还编写了 threshold 参数的可选类型：number | thresholdObj

type thresholdObj = { primary?: number; left?: number; right?: number; top?: number; bottom?: number }

可以单独设置主阈值、上下左右四边阈值，以适应更个性化的情况。

autohue.js 诞生了

名字的由来：秉承一贯命名习惯，auto 家族成员又多一个，与颜色有关的单词有好多个，我取了最短最好记的一个 hue(色相)，也比较契合插件用途。

此插件已在 github 开源：GitHub autohue.js

npm 主页：NPM autohue.js

在线体验：autohue.js 官方首页

安装与使用

pnpm i autohue.js

import autohue from 'autohue.js'



autohue(url, {

  threshold: {

    primary: 10,

    left: 1,

    bottom: 12

  },

  maxSize: 50

})

  .then((result) => {

    // 使用 console.log 打印出色块元素s

    console.log(`%c${result.primaryColor}`, 'color: #fff; background: ' + result.primaryColor, 'main')

    console.log(`%c${result.secondaryColor}`, 'color: #fff; background: ' + result.secondaryColor, 'sub')

    console.log(`%c${result.backgroundColor.left}`, 'color: #fff; background: ' + result.backgroundColor.left, 'bg-left')

    console.log(`%c${result.backgroundColor.right}`, 'color: #fff; background: ' + result.backgroundColor.right, 'bg-right')

    console.log(`%clinear-gradient to right`, 'color: #fff; background: linear-gradient(to right, ' + result.backgroundColor.left + ', ' + result.backgroundColor.right + ')', 'bg')

    bg.value = `linear-gradient(to right, ${result.backgroundColor.left}, ${result.backgroundColor.right})`

  })

  .catch((err) => console.error(err))

最终效果

复杂边缘效果

纵向渐变效果（这里使用的是 left 和 right 边的值，可能使用 top 和 bottom 效果更佳）

纯色效果（因为单独对边缘采样，所以无论图片内容多复杂，纯色基本看不出边界）

突变边缘效果（此时用css做渐变蒙层应该效果会更好）

横向渐变效果（使用的是 left 和 right 的色值），基本看不出边界

参考资料

• zhuanlan.zhihu.com/p/370371059


• baike.baidu.com/item/%E5%9B…


• baike.baidu.com/item/%E6%A0…


• zh.wikipedia.org/wiki/%E6%AC…


• blog.csdn.net/weixin_4256…


• zh.wikipedia.org/wiki/K-%E5%…


• blog.csdn.net/weixin_4299…


• juejin.cn/post/684490…

番外

Auto 家族的其他成员

• Auto-Plugin/autofit.js autofit.js 迄今为止最易用的自适应工具


• Auto-Plugin/autolog.js autolog.js 轻量化小弹窗


• Auto-Plugin/autouno autouno 直觉的UnoCSS预设方案


• Auto-Plugin/autohue.js 本品 一个自动提取图片主题色让图片和背景融为一体的工具

看到Matt Pocock 在 X 上的一个帖子提到不使用 .d.ts 文件的说法。

你赞同么？是否也应该把 .d.ts 文件都替换为 .ts 文件呢？

我们一起来看看~

.d.ts 文件的用途

首先，我们要澄清的是，.d.ts 文件并不是毫无用处的。

.d.ts 文件的用途主要用于为 JavaScript 代码提供类型描述。

.d.ts 文件是严格的蓝图，用于表示你的源代码可以使用的类型。最早可以追溯到2012年。其设计受到头文件、接口描述语言（IDL）、JSDoc 等实践的启发，可以被视为 TypeScript 版本的头文件。

.d.ts 文件只能包含声明，所以让我们通过一个代码示例来看看声明和实现之间的区别。假设我们有一个函数，它将两个数字相加：

// 声明 (.d.ts)

export function add(num1: number, num2: number): number;

// 实现 (.ts)

export function add(num1: number, num2: number): number {

  return num1 + num2;

}

正如你所见，add 函数的实现实际上展示了加法的执行过程，并返回结果，而声明则没有。

那么 .d.ts 文件在实践中是如何使用的呢？

假设我们有一个 add 函数，分别在两个文件中存储声明和实现：add.d.ts 和 add.js。

现在我们创建一个新文件 index.js，它将实际使用 add 函数：

import { add } from "./x";



const result = add(1, 4);

console.log(result); // 输出：5

请注意，在这个 JS 文件中，add 函数具有类型安全性，因为函数在 add.d.ts 中被标注了类型声明。

替换方案 .ts 文件

我们已经了解了 .d.ts 文件的工作原理以及它们的用途。Matt 之所以认为不需要.d.ts 文件，是因为它也可以放在一个 .ts 文件中直接创建带有类型标注的实现。也就是说，拥有一个包含声明和实现的单个 add.ts 文件，等同于分别定义了 add.d.ts 和 add.js 文件。

这意味着你无需担心将声明文件与其对应的实现文件分开组织。

不过，针对类库，将 .d.ts 文件与编译后的 JavaScript 源代码一起使用，比存储 .ts 文件更高效，因为你真正需要的只是类型声明，以便用户在使用你的库时能够获得类型安全性。

这确实没错，需要强调的是，更推荐自动生成。通过更改 package.json 和 tsconfig.json 文件中的几个设置，从 .ts 文件自动生成 .d.ts 文件：

• tsconfig.json：确保添加 declaration: true，以支持 .d.ts 文件的生成。

{

  "compilerOptions": {

    "declaration": true,

    "target": "ES6",

    "module": "commonjs",

    "outDir": "./dist",

    "strict": true

  },

  "include": ["src/**/*"]

}

• package.json：确保将 types 属性设置为生成的 .d.ts 文件，该文件位于编译后的源代码旁边。

{

  "name": "stop using d.ts",

  "version": "1.0.0",

  "main": "dist/index.js",

  "types": "dist/index.d.ts",

  "scripts": {

    "build": "tsc"

  }

}

结论

.d.ts 文件中可以做到的一切，都可以在 .ts 文件中完成。

在 .ts 文件中使用 declare global {} 语法时，花括号内的内容将被视为全局环境声明，这本质上就是 .d.ts 文件的工作方式。

所以即使不使用.d.ts文件，也可以拥有全局可访问的类型。.ts文件在功能上既可以包含代码实现，又可以包含类型声明，而且还能实现全局的类型声明，从而在开发过程中可以更加方便地管理和使用类型，避免了在.d.ts文件和.ts文件之间进行复杂的协调和组织，提高了开发效率和开发体验。

另外需要注意的是，在大多数项目中，开发者会在 TypeScript 的配置文件（tsconfig.json）中将 skipLibCheck 选项设置为 true。skipLibCheck 的作用是跳过对库文件（包括 .d.ts 文件）的类型检查。当设置为 true 时，TypeScript 编译器不会对这些库文件进行严格的类型检查，从而加快编译速度。但这也会影响项目中自己编写的 .d.ts 文件。这意味着，即使 .d.ts 文件中定义的类型存在错误，TypeScript 编译器也不会报错，从而失去了类型安全性的保障。

而我们直接使用 .ts 文件，就不会有这个问题了，同事手动编写 .d.ts 文件，也会更加安全和高效。

因此，.d.ts 文件确实没有必要编写。在 99% 的情况下，.ts 文件更适合使用，可以改善开发体验，并降低库代码中出现类型错误的可能性。

怎么样？？你同意他的看法么？

前言

最近在公司改bug，突然发现上一个前端留下的毛病不少，页面存在各种适配问题，为此甲方爸爸时常提出宝贵意见！

你的页面是不是时常是这样：

侧边栏未收缩时：

收缩后：

这样（缩小挤成一坨）：

又或是这样：

那么废话不多说，今天由我不是程序猿kk为大家讲解一些前端必备知识：适配工作。

流式布局

学会利用相对单位（例如百分比，vh或是vw），而不是只会用px一类固定单位设计布局，前言中提到的收缩后多出一大块空白，就是由于写死了宽度，例如1000px或是89vw，那么当侧边栏进行收缩，右边内容宽度还是只有89个vw，因此我们可以将其更改为100%，这样不论侧边栏是否收缩，内容都会占满屏幕的全部。

.map {

  width: 100%;

  height: 90vh;

  position: relative;

}

rem和第三方插件

什么是rem

rem与em不同，rem会根据html的根节点字体大小进行变换，例如1rem就是一个字体大小那么大，比如根大小font size为12px，那么1rem即12px，大家可以在网上寻找单位换算工具进行换算（从设计稿的px到rem）或是下载相关插件例如gulp-px3rem，这样在不同分辨率，不同缩放比的电脑下都能够轻松应对了。

使用

第三方插件，例如做移动端适配的flexible.js，lib-flexible库，其核心原理就是rem,我们需要做的就是根据不同屏幕计算出不同的fontsize，而页面中元素都是用rem做单位，据此实现了自适应

源码：

;(function(win, lib) {

    var doc = win.document;

    var docEl = doc.documentElement;

    var metaEl = doc.querySelector('meta[name="viewport"]');

    var flexibleEl = doc.querySelector('meta[name="flexible"]');

    var dpr = 0;

    var scale = 0;

    var tid;

    var flexible = lib.flexible || (lib.flexible = {});

    

    if (metaEl) {

        console.warn('将根据已有的meta标签来设置缩放比例');

        var match = metaEl.getAttribute('content').match(/initial-scale=([d.]+)/);

        if (match) {

            scale = parseFloat(match[1]);

            dpr = parseInt(1 / scale);

        }

    } else if (flexibleEl) {

        var content = flexibleEl.getAttribute('content');

        if (content) {

            var initialDpr = content.match(/initial-dpr=([d.]+)/);

            var maximumDpr = content.match(/maximum-dpr=([d.]+)/);

            if (initialDpr) {

                dpr = parseFloat(initialDpr[1]);

                scale = parseFloat((1 / dpr).toFixed(2));    

            }

            if (maximumDpr) {

                dpr = parseFloat(maximumDpr[1]);

                scale = parseFloat((1 / dpr).toFixed(2));    

            }

        }

    }



    if (!dpr && !scale) {

        var isAndroid = win.navigator.appVersion.match(/android/gi);

        var isIPhone = win.navigator.appVersion.match(/iphone/gi);

        var devicePixelRatio = win.devicePixelRatio;

        if (isIPhone) {

            // iOS下，对于2和3的屏，用2倍的方案，其余的用1倍方案

            if (devicePixelRatio >= 3 && (!dpr || dpr >= 3)) {                

                dpr = 3;

            } else if (devicePixelRatio >= 2 && (!dpr || dpr >= 2)){

                dpr = 2;

            } else {

                dpr = 1;

            }

        } else {

            // 其他设备下，仍旧使用1倍的方案

            dpr = 1;

        }

        scale = 1 / dpr;

    }



    docEl.setAttribute('data-dpr', dpr);

    if (!metaEl) {

        metaEl = doc.createElement('meta');

        metaEl.setAttribute('name', 'viewport');

        metaEl.setAttribute('content', 'initial-scale=' + scale + ', maximum-scale=' + scale + ', minimum-scale=' + scale + ', user-scalable=no');

        if (docEl.firstElementChild) {

            docEl.firstElementChild.appendChild(metaEl);

        } else {

            var wrap = doc.createElement('div');

            wrap.appendChild(metaEl);

            doc.write(wrap.innerHTML);

        }

    }



    function refreshRem(){

        var width = docEl.getBoundingClientRect().width;

        if (width / dpr > 540) {

            width = 540 * dpr;

        }

        var rem = width / 10;

        docEl.style.fontSize = rem + 'px';

        flexible.rem = win.rem = rem;

    }



    win.addEventListener('resize', function() {

        clearTimeout(tid);

        tid = setTimeout(refreshRem, 300);

    }, false);

    win.addEventListener('pageshow', function(e) {

        if (e.persisted) {

            clearTimeout(tid);

            tid = setTimeout(refreshRem, 300);

        }

    }, false);



    if (doc.readyState === 'complete') {

        doc.body.style.fontSize = 12 * dpr + 'px';

    } else {

        doc.addEventListener('DOMContentLoaded', function(e) {

            doc.body.style.fontSize = 12 * dpr + 'px';

        }, false);

    }

    



    refreshRem();



    flexible.dpr = win.dpr = dpr;

    flexible.refreshRem = refreshRem;

    flexible.rem2px = function(d) {

        var val = parseFloat(d) * this.rem;

        if (typeof d === 'string' && d.match(/rem$/)) {

            val += 'px';

        }

        return val;

    }

    flexible.px2rem = function(d) {

        var val = parseFloat(d) / this.rem;

        if (typeof d === 'string' && d.match(/px$/)) {

            val += 'rem';

        }

        return val;

    }



})(window, window['lib'] || (window['lib'] = {}));

大家如果对相关原理感兴趣，可以阅读：flexible.js如何实现rem自适应-前端开发博客

在实际开发中应用场景不同效果不同，因此不能写死px。

在PC端适配我们可以自动转换rem适配方案（postcss-pxtorem、amfe-flexible）,这里以vue3+vite为例子。事实上amfe-flexible是lib-flexible的升级版。

注意： 行内样式px不会转化为rem

npm install postcss postcss-pxtorem --save-dev  // 我试过了反正我报错了，版本太高 大家可以指定5.1.1

npm install postcss-pxtorem@^5.1.1 

npm i amfe-flexible --save

记得在main.js中引入amfe-flexible

import "amfe-flexible"

相关配置

媒体查询

通过查询不同的宽度来执行不同的css代码，最终以达到界面的配置。

在 CSS 中使用 @media 查询来检测屏幕宽度。当屏幕宽度小于 1024px 时，增加 margin-top 以向下移动表格。

.responsive-table {

  transition: margin-top 0.3s; /* 添加过渡效果 */

}



@media (max-width: 1024px) {

  .responsive-table {

    margin-top: 200px; /* 向下移动的距离 */

  }

}

弹性布局

创建一个响应式的卡片布局，当屏幕宽度减小时，卡片会自动换行。

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

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

    <title>Flexbox Example</title>

    <style>

        body {

            display: flex;

            justify-content: center;

            align-items: center;

            flex-wrap: wrap;

            margin: 0;

            height: 100vh;

            background-color: #f0f0f0;

        }



        .card-container {

            display: flex;

            flex-wrap: wrap;

            justify-content: center;

            width: 90%;

        }



        .card {

            background-color: white;

            border: 1px solid #ccc;

            border-radius: 5px;

            padding: 20px;

            margin: 10px;

            flex: 1 1 300px; /* 基于300px，允许增长和收缩 */

            box-shadow: 0 2px 10px rgba(0, 0, 0, 0.1);

            transition: transform 0.3s;

        }



        .card:hover {

            transform: translateY(-5px);

        }

    </style>

</head>

<body>

    <div class="card-container">

        <div class="card">Card 1</div>

        <div class="card">Card 2</div>

        <div class="card">Card 3</div>

        <div class="card">Card 4</div>

        <div class="card">Card 5</div>

    </div>

</body>

</html>

小结

还是多提一嘴，应该不会有小伙伴把字体大小的单位也用rem吧？

在制作一个页面时，如何兼容PC端和手机端是一个重要的设计决策。这个决策通常有两个选择：分别制作两个页面，或者只制作一个自适应页面。以下是我选择后者的理由，以及如何实现自适应设计的相关内容。

选择自适应设计的理由

如何实现自适应设计

总结

在制作兼容PC端和手机端的页面时，选择制作一个自适应页面是更为高效和经济的方案。它不仅能提高开发效率和维护成本，还能提供一致的用户体验，增强SEO效果。此外，现代的CSS技术使得实现自适应设计变得更加简单。因此，采用自适应设计是现代Web开发的最佳实践之一。

一款成功的APP不仅仅取决于其功能性，更取决于用户体验，这其中，UI设计又至关重要。优秀的UI设计能够为用户带来直观、愉悦的交互体验，甚至让用户“一见钟情”，从而大大提高产品吸引力。

然而，有很多设计师在追求创新与美观的同时，往往会不经意间“踩雷”，忽略了一些普通用户更在意的问题和痛点。本文，笔者将谈谈UI设计中的常见误区，同时展示了优秀的UI设计例子，还分享一些行业内推荐的设计工具，希望能助你在设计的道路上更加得心应手~

UI设计常见误区

1、过度设计

设计大师 Dieter Rams 说过一句话：“好的设计是尽可能简单的设计。”

不过，说起来容易做起来难。产品经理和设计师总是不自觉地让产品过于复杂，今天想在产品中再添加一个功能，明天想在页面上再增加一个元素。

尤其是新手设计师，总希望通过增加视觉元素、动画效果和复杂的交互来提升用户体验。然而，这种做法往往适得其反，一个简洁、清晰且直观的界面一定比一个装饰过多、功能复杂的界面更能吸引用户。设计师应该专注于APP的核心功能，避免不必要的元素，确保设计美观又实用。

简约风接单APP界面

http://www.mockplus.cn/example/rp/…

2、忽视用户反馈

有时候，设计师可能过于相信自己的设计，忽略了用户的意见和反馈。这种情况下，即使设计再怎么创新或美观，如果不符合用户的实际需求和使用习惯，也难以获得用户的认可。

毕竟，UI设计不是艺术创作，用户反馈是设计迭代过程中的宝贵资源，它可以帮助设计师了解用户的真实体验，了解设计的不足，从而进行针对性的优化改进。

FARFETCH APP界面

http://www.mockplus.cn/example/rp/…

3、色彩搭配不合适

色彩搭配不合适是UI设计中一个常见的误区。有的设计师会自动倾向于选择那些自己喜欢的颜色，而不是基于用户的偏好和产品特征、背景等来选择颜色。有时，颜色的过度使用或不恰当的搭配会分散用户的注意力，甚至造成视觉疲劳。

另外，为了让用户能看清UI设计的各个方面，需要有足够的对比度。这就是为什么黑色文字配上白色背景效果那么好 —— 文字非常清晰，易于理解。

插画风APP界面

http://www.mockplus.cn/example/rp/…

4、忽略可访问性

对一个APP来说，所有用户，无论是有视觉障碍的人还是老年用户，都应该能够轻松地使用APP。设计如果不考虑这些用户群体的需要，会无意中排除一大部分潜在用户。

为了提高APP的可访问性，设计师应该考虑到字体大小、颜色对比度、语音读出功能等，确保所有用户都能舒适地使用。

社交类APP界面

http://www.mockplus.cn/example/rp/…

5、布局空滤不全面

有的产品界面过多，布局考虑不够全面几乎是常常发生的事。布局不合适有很多种情况，比如元素过于密集、排版杂乱、组件没有对齐、文本大小间距不合适等等。这种情况会导致信息展示不清晰或用户操作不便，非常影响用户的使用体验和效率。

一个美观舒适的布局应该合理利用空间，确保信息的层次清晰，充分考虑元素的大小和间距，让界面既清晰又易于操作，用户可以轻松地找到他们关心的内容。

想要避免这一误区的，在设计初期就需要考虑用户的需求和行为模式，不断迭代优化布局设计，找到最佳的解决方案。

加密货币钱包APP界面

http://www.mockplus.cn/example/rp/…

了解了上述UI设计的常见误区后，接下来是选择合适的设计工具来提升设计效率和质量。目前，市面上有很多优秀的UI设计工具，但以下几款因其强大的功能和良好的用户体验受到设计师的广泛推荐，一起来看看！

UI工具推荐

1、摹客 DT

摹客DT（http://www.mockplus.cn/dt）是一款国内很多UI设计师都爱用的工具，它提供了一整套完整的专业矢量编辑功能，丰富的图层样式选项，可以轻松创建高质量的App设计，并且还能在线实时协同，搞定团队资产管理难题不是问题。

主要功能点和亮点：

1）所有功能完全免费（参与它们的小活动还能永久免费使用），包含所有高级功能、导出能力等；

2）颜色、文本样式、图层样式都可以保存为资源，复用到其他设计元素；

3）支持导出SVG、JPG、PNG、webP、PDF格式文件，适配不同使用场景；

4）具有完善的团队协作和项目管理能力，改变传统设计流程，降低成本，提升效率。

**价格：**完全免费

**学习难度：**简单，新手上手无难度

**使用环境：**Web/客户端/Android/iOS

**推荐理由：**摹客DT，是一款更适合中国设计师的UI/UX设计工具。与一些老牌设计工具（Photoshop、XD等），它的学习门槛更低，上手更简单，社区和实时客户支持更迅速友好；作为Web端工具，摹客DT支持多人实时编辑，大大提高了团队设计效率。

推荐评级：⭐⭐⭐⭐⭐

2、Figma

Figma（http://www.figma.com/）是现在最流行的UI设…

主要功能点及亮点：

1）丰富的功能和工具：提供了全面的工具和功能来设计界面，包括矢量图形工具、网格和布局指导等。

2）设计组件和样式库：支持创建可复用的设计组件和样式库，节省时间和工作量。

3）插件生态系统：有丰富的插件生态系统，可以通过插件扩展功能，增加额外的设计工具和集成，以满足特定需求。

**价格：**提供免费版和付费版（12美元/月起）

**学习难度：**对新手相对友好，操作简单。

**使用环境：**Figma是基于Web的平台，通过浏览器即可使用。

推荐理由：

Figma设计功能强大，提供了丰富的插件和集成，还有有一个庞大的社区交流学习，是一款非常适合团队协作的工具。遗憾的是，Figma作为一款国外设计工具，在国内使用还是存在一定的劣势，比如网络访问限制、数据隐私和安全、本地化支持等，所以只能给到四星。

推荐评级：⭐⭐⭐⭐

3、Sketch

Sketch（http://www.sketch.com/）是一款专业的UI/U…

主要功能及亮点：

3）Sketch支持众多插件和第三方资源，使得其生态系统非常丰富，能够更好地满足设计师的需求。

**价格：**标准订阅 $10/月/人（按年付费），$12/月/人（按月付费）

**使用环境：**macOS操作系统

推荐理由：

Sketch被广泛应用于移动应用、网页设计和用户界面设计等领域。它友好的界面、丰富的设计资源使设计师们能够快速创建出符合良好用户体验和视觉效果要求的设计。可惜的是，它只支持macOS系统，限制了部分用户使用。

**推荐评级：**⭐⭐⭐⭐

4、Adobe XD

Adobe XD（helpx.adobe.com/support/xd.…

主要功能及亮点：

1）丰富的设计和布局功能：设计师可以借助这些功能，轻松创建响应式设计，预览在不同设备上的效果，确保设计的一致性和灵活性。

2）丰富的交互动画和过渡效果：可以创建十分流畅的交互体验，用来更好地展示APP或网站的交互逻辑。

3）共享和协作：支持团队协作，用户可以轻松地共享设计文件，协同编辑，以及通过实时协作功能进行设计评审。

**价格：**提供免费试用，提供付费订阅 $9.99/月

**学习难度：**中

**使用环境：**Windows、macOS

**推荐理由：**Adobe XD与Adobe Creative Cloud紧密集成，十分方便同时使用Adobe其他软件的用户。不过有个问题是，Adobe xd已经官宣停止更新，只向老用户提供服务了，如果是之前没有使用Adobe XD的用户，最好选择其他产品。

**推荐评级：**⭐️⭐️⭐️

五、Principle

Principle是一款专门用于UI/UX设计的软件，它的设计理念是想要让设计师能够轻松创建出高质量、富有吸引力的产品界面效果。

主要功能及亮点：

1）高级动画控制：软件支持创建复杂的动画效果，包括过渡、转换和多状态动画。这对于展示复杂的交互过程和动态效果非常有用。

2）实时预览：Principle允许设计师实时预览他们的工作成果，这意味着可以即时查看和测试动画效果，确保设计的交互体验符合预期。

3）组件和重复使用：设计师可以创建可重复使用的组件，这大大提高了工作效率，特别是在处理具有相似元素或布局的多个界面时。

价格：$129

**学习难度：**中

**使用环境：**MacOS

推荐理由：

设计师通过Principle可以快速地制作出具有丰富交互的产品界面设计，并且它能和Sketch进行无缝链接，可以快速导入你在Sketch里已经做好的图，

推荐评级：⭐️⭐️⭐️⭐️

好的UI设计不仅仅是视觉上的享受，更是能让用户能够轻松、愉快地使用APP。避免上述UI设计误区，选择合适的设计工具，可以帮助我们设计出既美观又实用的产品。

希望本文章能为UI设计师/准UI设计师们有所帮助，创作出更多优秀的设计作品~

看到这里的读者朋友有福啦！本人吐血搜集整理，全网最全产品设计学习资料！

只要花1分钟填写**问卷**就能免费领取以下超值礼包：

1、产品经理必读的100本书 包含：产品思维、大厂案例、技能提升、数据分析、项目管理等各类经典书籍，从产品入门到精通一网打尽！ 2、UI/UX设计师必读的115本书 包含：UI/UX设计、平面设计、版式设计、设计心理学、设计思维等各类经典书籍，看完你就是设计大神！ 3、30G互联网人知识礼包 包含：

• 10GPM礼包，产品案例、大咖分享、行业报告等应有尽有


• 10GUI/UE资源，优秀设计案例、资料包、源文件免费领


• 5G运营资料包，超全产品、电商、新媒体、活动等运营技能


• 5G职场/营销资料包，包含产品设计求职面试、营销增长等

4、50G热门流行的AI学习大礼包

包含：AI绘画、AIGC精选课程、AI职场实用教程等

5、30G职场必备技能包

包含：精选PPT模板、免费可商用字体包、各岗位能力模型、Excel学习资料、求职面试、升职加薪、职场写作和沟通等实用资源。

礼包资源持续更新，互联网行业知识一网打尽！礼包领取地址：

docs.qq.com/form/page/D…

前言

后端开发忙，不给你接口？

后端抱怨你在测试过程中，频繁的给脏数据？

后端修个接口很慢没法测试？

有了 mockjs ，这些问题将迎刃而解。不要 998，pnpm i 带回家！

真这么丝滑？

请看我的使用方式：

当后端接口无法满足要求，且不能及时更改时。例如后端返回

{

  "err_no": 0,

  "err_msg": "success",

  "data": [

    {

      "comment_id": "7337487924836287242",

      "user_info": {

        "user_name": "陈陈陈_",

      }

    }

  ],

}

但我此时希望增加一个 user_type 来确定页面的展示。

那我就直接起一个文件：user.js，把刚才的响应 copy 过来，并追加改动

myMock('/api/v1/user', 'post', () => {

  return {

      "err_no": 0,

      "err_msg": "success",

      "data": [

        {

          "comment_id": "7337487924836287242",

          "user_info": {

            "user_name": "陈陈陈_",

            "user_type": "admin",

          }

        }

      ],

  }

});

如此一来，这个请求就被无缝替换为了我们的 mock，可以随便测试了。

如何接入 mockjs

有的同学就要问了，主播主播，你的 mockjs 确实很方便，怎么接入比较好呀。别急，我们一步一步来

1. 安装 mockjs

pnpm i mockjs

如果是使用 ts 的同学，可能需要额外安装 type 类型包：@types/mockjs

2. 新建一个 mock 文件夹，在 mock/index.ts 放入基本路径

// 各种 mock 的文件，视条件而定，我这里有俩文件就引入了俩

import './login/user.js';

import './model/model.js';

并且在你的项目入口 ts 中引入 mock/index.ts

import './mock/index'; // 引入 mock 配置

3. 导出一个 myMock 方法，并追加一个 baseUrl 方便直接联动你的 axios

import { ENV_TEST } from '@/api/config/interceptor';

import Mock from 'mockjs';



export const myMock = (

  path: string,

  method: 'get' | 'post',

  callback: (options: any) => any

) => {

  Mock.mock(`${ENV_TEST}${path}`, method, callback);

};

如此一来，你就可以在 mock 文件夹下去搞了，比如：

我想新增一个服务模块的各类接口的 mock，那么我就新增一个 service 文件夹，在其下增加一个 index.ts，并对对应路径进行 mock

myMock('/api/v1/service', 'get', () => {

  return {

    code: 0,

    msg: 'hello service',

    data: null,

  };

});

另外，别忘了在 mock/index.ts 引入文件

不显示在 network 中？

需要说明的是，这样走 mock 是不会触发真正的请求的，相当于 xhr 直接被 mock 拦截了下来并给了你返回值。所以你无法在 network 中看到你的请求。

这是个痛点，目前比较好的解决方案还是起一个单独的服务来 mock。但这样也就意味着，需要另起一个项目来单独做 mock，太不优雅了。

有没有什么办法，既可以走上述简单的mock，又可以在需要的时候起一个服务来查看 network，并且不需要额外维护两套配置呢？

有的兄弟，有的。

import express from 'express';

import bodyParser from 'body-parser';

import Mock from 'mockjs';

import './login/user.js';

import './model/model.js';

import { ENV_TEST } from './utils/index.js';



const app = express();

const port = 3010;



// 使用中间件处理请求体和CORS

app.use(bodyParser.json());



// 设置CORS头部

app.use(( _ , res, next) => {

  res.header('Access-Control-Allow-Origin', '*');

  res.header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');

  res.header('Access-Control-Allow-Headers', 'Content-Type, Authorization');

  next();

});



// 设置Mock路由的函数

const setupMockRoutes = () => {

  const mockApis = Mock._mocked || {};



  // 遍历每个Mock API，并生成对应的路由

  Object.keys(mockApis).forEach((key) => {

    const { rurl, rtype, template } = mockApis[key];

    const route = rurl.replace(ENV_TEST, ''); // 去掉环境前缀



    // 根据请求类型（GET, POST, 等）设置路由

    app[rtype.toLowerCase()](route, (req, res) => {

      const data =

        typeof template === 'function' ? template(req.body || {}) : template;

      res.json(Mock.mock(data)); // 返回模拟数据

    });

  });

};



// 设置Mock API路由

setupMockRoutes();



// 启动服务器

app.listen(port, () => {

  process.env.NODE_ENV = 'mock'; // 设置环境变量

  console.log(`Mock 服务已启动，访问地址: http://localhost:${port}`);

});

直接在 mock 文件夹下追加这个启动文件，当你需要看 network 的时候，将环境切换为 mock 环境即可。本质是利用了 Mock._mocked 可以拿到所有注册项，并用 express 起了一个后端服务响应这些注册项来实现的。

在拥有了这个能力的基础上，我们就可以调整我们的命令

  "scripts": {

    "dev": "cross-env NODE_ENV=test vite",

    "mock": "cross-env NODE_ENV=mock vite & node ./src/mock/app.js"

  },

顺便贴一下我的 env 配置：

export const ENV_TEST = 'https://api-ai.com/fuxi';

export const ENV_MOCK = 'http://localhost:3010/';



let baseURL: string = ENV_TEST;



console.log('目前环境为：' + process.env.NODE_ENV);

switch (process.env.NODE_ENV) {

  case 'mock':

    baseURL = ENV_MOCK;

    break;

  case 'test':

    baseURL = ENV_TEST;

    break;

  case 'production':

    break;

  default:

    baseURL = ENV_TEST;

    break;

}



export { baseURL };

这样一来，如果你需要看 network ，就 pnpm mock，如果不需要，就直接 pnpm dev，完全不需要其他心智负担。

三个字：

参数相关

具体的 api 可查阅：github.com/nuysoft/Moc… 相关的文章也非常多，就不展开说明了。

如果这篇文章对你有帮助，不妨点个赞吧~

作者：imoo
来源：juejin.cn/post/7460091261762125865

相信很多人和我一样，好奇无虚拟DOM版的Vue为什么叫Vue Vapor。之前看过一个很新颖的观点：Vue1时代就没有虚拟DOM，而那个时代恰好处于前端界的第一次工业革命，也就是以声明式代替命令式的写法。所以无虚拟DOM版Vue让人感觉梦回Vue1，于是就采取了Vapor这个名字。

Vapor是蒸汽的意思，第一次工业革命开创了以机器代替手工劳动的时代，该革命以蒸汽机作为动力机被广泛使用为标志。

不过这个说法并非来自官方，虽然乍一听还挺有道理的，但总感觉官方并不一定是这么想的。事实也的确如此，在官方的Vue Conf中，Vue Vapor的作者出面说明了Vapor这个名字的含义：

由于无虚拟DOM的特性，纯Vapor模式下可以去掉很多代码，比如VDom Diff。所以Vue Vapor的包体积可以做的更加的轻量化，像水蒸气一样轻。

（前面那段话是官方说的，这段话是我说的）当然不是说Vapor模式就不需要diff算法了，我看过同为无虚拟DOM框架的Svelte和Solid源码，无虚拟DOM只是不需要vDom间的Diff算法了，列表之间还是需要diff的。毕竟再怎么编译，你从后端获取到的数组，编译器也不可能预测得到。

那具体能轻量多少呢？官方给出的数据是比虚拟DOM版Vue小33.6%：

Vapor的名字除了想表示轻量化之外还有一个另外一个原因，那就是Solid。可能有人会说这关Solid什么事啊？实际上Vapor的灵感正是来自于Solid（尤雨溪亲口承认）而Solid代表固体：

为了跟Solid有个趣味联动，那无虚拟DOM就是气体好了：

以上就是Vue Vapor作者告诉大家为什么叫Vapor的两大原因。

性能

之前都说虚拟DOM是为了性能，怎么现在又反向宣传了？无虚拟DOM怎么又逆流而上成为了性能的标杆了呢？这个话题我们留到下一篇文章去讲，本篇文章我们只看数据：

从左到右依次为：

• 原生JS：1.01


• Solid：1.09


• Svelte：1.11


• 无虚拟DOM版Vue：1.24


• 虚拟DOM版Vue：1.32


• React：1.55

数字越小代表性能越高，但无论再怎么高都不可能高的过手动优化过的原生JS，毕竟无论什么框架最终打包编译出来的还是JS。不过框架的性能其实已经挺接近原生的了，尤其是以无虚拟DOM著称的Solid和Svelte。但无虚拟DOM版Vue和虚拟DOM版Vue之间并没有拉开什么很大的差距，1.24和1.32这两个数字证明了其实二者的性能差距并不明显，这又是怎么一回事呢？

一个原因是Vue3本来就做了许多编译优化，包括但不限于静态提升、大段静态片段将采用innerHTML渲染、编译时打标记以帮助虚拟DOM走捷径等… 由于本来的性能就已经不错了，所以可提升的空间自然也没多少。

看完上述原因肯定有人会说：可提升的空间没多少可以理解，那为什么还比同为无虚拟DOM的Solid和Svelte差那么多？如果Vapor和Solid性能差不多的话，那可提升空间小倒是说得过去。但要是像现在这样差的还挺多的话，那这个理由是不是就有点站不住脚了？之所以会出现这样的情况是因为Vue Vapor的作者在性能优化和快速实现之间选择了后者，毕竟尤雨溪第一次公布要开始做无虚拟DOM版Vue的时间是在2020年：

而如今已经是2025年了。也就是说如果一个大一新生第一次满心欢喜的听到无虚拟DOM版Vue的消息后，那么他现在大概率已经开始毕业工作了都没能等到无虚拟DOM版Vue的发布。这个时间拖的有点太长了，甚至从Vue2到Vue3都没用这么久。

所以现在的首要目标是先实现出来一版能用的，后面再慢慢进行优化。我们工作不也是这样么？先优先把功能做出来，优化的事以后再说。那么具体该怎么优化呢：

现在的很多渲染逻辑继承自原版Vue3，但无虚拟DOM版Vue可以采用更优的渲染逻辑。而且现在的Vapor是跟着原版Vue的测试集来做的，这也是为了实现和原版Vue一样的行为。但这可能并不是最优解，之后会慢慢去掉一些不必要的功能，尤其是对性能产生较大影响的功能。

往期精彩文章：

《尤雨溪：从Vue1到Vue3.6》

来源 Netflix Removed React?

Netflix 删除了 React

"Netflix 删除了 React,网站加载时间减少了 50%!"

这条爆炸性新闻在推特炸开了锅。这不禁让人想起半年前"微软应该禁止所有新项目使用 React" 的新闻 - 两大科技巨头相继 "抛弃" React,难道这预示着什么?

"React 心智负担重、性能差、bundle 体积大...". 一时间，各种唱衰 React 的声音此起彼伏。有人甚至信誓旦旦地表示:"只要像 Netflix 一样干掉 React,你的网站性能立马提升 50%!"

这条发布于 2024 年 10 月 27 日的推文有着惊人的 150 万浏览量。但是，这大概率是 AI 生成的假新闻。
事实上，我们去 Netflix 的官网打开 react-devtools，发现他们依然在使用 React 构建他们的网站。

Netflix 的真实案例

这篇 AI 生成的假新闻灵感来自 2017 年 Netflix 工程师在 hack news 上发布的一篇文章 - Netflix: Removing client-side React.js improved performance by 50%

他直接移除了这篇文章最重要的部分 - client-side React.js, 也就是客户端的 React.js 代码。

实际的情况是，Netflix 团队在 2017 年的时候在使用 React 构建他们的 landing page。

为什么在一个简单的 landing page 上要使用 React 呢？因为在 landing page 上

• Netflix 需要处理大量的 AB 测试


• 支持近 200 个国家的本地化


• 根据用户设备、地理位置等因素动态调整内容


• 需要服用现有的 React 组件

基于上述需求的考虑，Netflix 团队选择了使用 React 来构建他们的 landing page。

为了优化页面加载性能，他们采用了服务端渲染的方案。同时，为了保证后续交互的流畅性，系统会预先加载（pre-fetch）后续流程所需的 React/Redux 相关代码。

从架构上看，这个 landing page 本质上仍然是一个单页面应用（SPA），保持了 SPA 快速响应的优势。不同之处在于首次访问时，页面内容是由服务端直接生成的，这样可以显著提升首屏加载速度。

这样做的缺点

显然，Netflix 在 2017 年这么做是有原因的,他们当时的确也没有更好的方案。在 2025 年的今天，
再来回顾这个方案，显然有以下缺点：

数据重复获取

在首屏渲染时，服务端需要获取数据来生成 HTML，而在客户端激活（hydration）后，为了保持交互性，往往又需要重新获取一遍相同的数据。
这种重复的数据获取不仅浪费资源，还可能带来不必要的性能开销。

客户端代码体积膨胀

因为本质上，Netflix 的 landing page 是一个还是一个 SPA,那么不可避免的，所有可能的 UI 状态都需要打包，
即使用户只需要其中的一部分代码。例如，在一个很常见的 tabs 页面

  <Tabs

    defaultActiveKey="1"

    items={[

      {

        label: 'Tab 1',

        key: '1',

        children: 'Tab 1',

      },

      {

        label: 'Tab 2',

        key: '2',

        children: 'Tab 2',

        disabled: true,

      },

    ]}

  />

即使用户只点击了 Tab 1, 即使 Tab 2 没有被渲染，但是 Tab 2 的代码也会被打包。

如何解决这些问题

React Server Components (RSC) 为上述问题提供了优雅的解决方案：

避免数据重复获取

使用 RSC，组件可以直接在服务器端获取数据并渲染，客户端只接收最终的 HTML 结果。不再需要在客户端重新获取数据。

智能代码分割

RSC 允许我们选择性地决定哪些组件在服务器端运行，哪些在客户端运行。例如：

function TabContent({ tab }: { tab: string }) {

  // 这部分代码只在服务器端运行，不会打包到客户端

  return <div>{tab} 内容</div>

}



// 客户端组件

'use client'

function TabWrapper({ children }) {

  const [activeTab, setActiveTab] = useState('1')

  return (

    <div>

      {/* Tab 切换逻辑 */}

      {children}

    </div>

  )

}

在这个例子中：

• TabContent 的所有可能状态都在服务器端预渲染


• 只有实际需要交互的 TabWrapper 会发送到客户端


• 用户获得了更小的 bundle 体积和更快的加载速度

这不就是 PHP?

经常会看到有人说:"Server Components 不就是重新发明了 PHP 吗?都是在服务端生成 HTML。"

显然，PHP 与现在的 Server Components 在开发体验上有本质的区别。

1. 细粒度的服务端-客户端混合

与 PHP 不同,RSC 允许我们在组件级别决定渲染位置，用一个购物车的例子来说明：

// 服务端组件

function ProductDetails({ id }: { id: string }) {

  // 在服务器端获取数据和渲染

  const product = await db.products.get(id);

  return <div>{product.name}</div>;

}



// 客户端组件

'use client'

function AddToCart({ productId }: { productId: string }) {

  // 在客户端处理交互

  return <button onClick={() => addToCart(productId)}>加入购物车</button>;

}



// 混合使用

function ProductCard({ id }: { id: string }) {

  return (

    <div>

      <ProductDetails id={id} />

      <AddToCart productId={id} />

    </div>

  );

}

这种设计充分利用了服务端和客户端各自的优势 - 在服务端可以直接访问数据库获取 ProductDetails 所需的数据,而在客户端则能更好地处理 AddToCart 这样的用户交互。这不仅提升了性能,也让代码结构更加清晰合理。

2. 保持组件的可复用性

RSC 最强大的特性之一是组件的可复用性不受渲染位置的影响:

// 这个组件可以在服务端渲染

function UserProfile({ id }: { id: string }) {

  return <ProfileCard id={id} />;

}



// 同样的组件也可以在客户端动态加载

'use client'

function UserList() {

  const [selectedId, setSelectedId] = useState(null);

  return selectedId ? <ProfileCard id={selectedId} /> : null;

}

因为都是 React 组件，区别仅仅是渲染位置的不同，同一个组件可以：

• 在服务端预渲染时使用


• 在客户端动态加载时使用


• 在流式渲染中使用

这种统一的组件模型是 PHP 等传统服务端渲染所不具备的。

3. 智能的序列化

RSC 还提供了智能的序列化机制，可以自动将组件的 props 和 state 序列化，从而在服务端和客户端之间传递。
避免了重复获取数据的问题。

// 服务端组件

async function Comments({ postId }: { postId: string }) {

  // 1. 获取评论数据

  const comments = await db.comments.list(postId);

  

  // 2. 传递给客户端组件

  return <CommentList initialComments={comments} />;

}



// 客户端组件

'use client'

function CommentList({ initialComments }) {

  // 3. 直接使用服务端数据,无需重新请求

  const [comments, setComments] = useState(initialComments);

  

  return (

    // 渲染评论列表

  );

}

4. 渐进式增强

RSC 还提供了渐进式增强的能力，可以在服务端和客户端之间无缝过渡。

• 首次访问时返回完整的 HTML


• 按需加载客户端交互代码


• 保持应用的可访问性

这让我们能够构建既有良好首屏体验,又能提供丰富交互的现代应用，完美解决了在 2017 年 Netflix 所提出的问题。

总结

通过对上面这些案例的分析，我们可以看出

1. 不要轻信网络传言

网络上充斥着各种技术传言。虽然像上面这种完全虚构的假新闻容易识破，但有些传言会巧妙地利用真实数据和案例，通过夸张的描述来误导技术选型和决策，这类信息需要我们格外谨慎分辨。
例如：

svelte 放弃 TypeScript 改用 JSdoc 进行类型检查

这个确实是一个真的新闻，但是并不代表着 Typescript 的没落，实际上

• Svelte 团队选择 JSDoc 是为了减少编译时间


• 这是针对框架源码的优化，而不是面向使用者的建议


• Svelte 依然完整支持 TypeScript，用户代码可以继续使用 .ts/.ts

tauri 打包后的体积比 electron 小多了，我们应该放弃 electron 使用 tauri

技术选型不能仅仅看单一指标。虽然 tauri 的打包体积确实小于 electron，但在开发体验、性能、稳定性、生态和社区支持等关键维度上都存在明显短板。

如果你尝试用 tauri 开发复杂应用，很可能会因为生态不完善、社区支持不足而陷入困境。当你遇到问题去 GitHub 寻找解决方案时，看到许多库已经一年未更新，就会明白为什么大多数团队仍在选择 electron。

2. 历史的选择

2017 年的 Netflix 面临着复杂的业务需求,他们选择了当时最佳的解决方案 - 服务端渲染 + 客户端激活。这个方案虽然解决了问题,但也带来了一些困扰:

• 数据需要在服务端和客户端重复获取


• JavaScript bundle 体积过大

3. RSC 带来的改变

React Server Components 为这些历史遗留问题带来了全新的解决思路:

• 服务端渲染与客户端渲染完美融合


• 智能的代码分割,最小化客户端 bundle 体积


• 数据获取更高效,避免重复请求


• 渐进式增强,提供流畅的用户体验

4. 技术演进的启示

从 Netflix 2017 年的实践到今天的 RSC,我们可以看到:

• 技术方案在不断进化,过去的最佳实践可能已不再适用


• RSC 不是简单的"回归服务端",而是开创了全新的开发模式


• 性能与开发体验不再是非此即彼的选择

RSC 代表了现代前端开发的新趋势 - 既保持了 React 强大的组件化能力,又通过创新的架构设计解决了历史难题。这让我们终于可以在性能和开发体验之间找到完美平衡。

前言

在公司中，前端使用了统一的组件element-ui，但是有一些页面大家并没有达成共识，造成了不同的团队开发出来的页面不同，公司决定在24年8月的迭代进行统一调整。在这个中间，我遇到了很多意料之外的问题，希望未来的你遇到了类似的问题，可以尽量避免

为什么会产生这个问题

这个问题我也思考过，大概有以下原因

项目背景

参与人：UI设计师、前端开发、产品（主要负责审核，并没参与讨论）、测试

牵头人：UI设计师
职责：找出问题点，整理为在线文档

解决者：前端
职责：整理问题点、改公告组件、输出文档

主要问题如下

弹窗组件大小不一

弹窗大小不统一部分截图