在一些前端开发场景中，需要在本地创建 https 服务，Node.js 提供了 https 模块帮助开发者快速创建 https 的服务器，示例代码如下：

const https = require('https')

const fs = require('fs')

const options = {

  key: fs.readFileSync('key.pem'),

  cert: fs.readFileSync('cert.pem'),

}

const server = https.createServer(options, (req, res) => {

  res.writeHead(200)

  res.end('hello world\n')

})

server.listen(8080)

与创建 http 服务最大的区别在于：https 服务需要证书。因此需要在 options 选项中提供 key 和 cert 两个字段。大部分前端不知道如何创建 key 和 cert，虽然网上能查到一些 openssl 命令，但也不知道是什么含义。所谓授人以鱼不如授人以渔，这里先从一些基本概念讲起，然后一步步教大家如何创建一个可以被浏览器绝对信任的自签名证书。

密码学知识

首先要知道加密学中非常重要的一个算法：公开密钥算法（Public Key Cryptography），也称为非对称加密算法（Asymmetrical Cryptography），算法的密钥是一对，分别是公钥（public key）和私钥（private key），一般私钥由密钥对的生成方（比如服务器端）持有，避免泄露，而公钥任何人都可以持有，也不怕泄露。

一句话总结：公钥加密、私钥解密。

公私钥出了用于加解密之外，还能用于数字签名。因为私钥只有密钥对的生成者持有，用私钥签署（注意不是加密）一条消息，然后发送给任意的接收方，接收方只要拥有私钥对应的公钥，就能成功反解被签署的消息。

一句话总结：私钥加签、公钥验证。

由于只有私钥持有者才能“签署”消息，如果不考虑密钥泄露的问题，就不能抵赖说不是自己干的。

数字签名和信任链

基于数字签名技术，假设 A 授权给 B，B 授权给 C，C 授权给 D，那么 D 就相当于拿到了 A 的授权，这就形成了一个完整的信任链。因此：

• 信任链建立了一条从根证书颁发机构（Root CA）到最终证书持有人的信任路径


• 每个证书都有一个签名，验证这个签名需要使用颁发该证书的机构的公钥


• 信任链的作用是确保接收方可以验证数字签名的有效性，并信任签名所代表的身份

以 https 证书在浏览器端被信任为例，整个流程如下：

可以看到，在这套基础设施中，涉及到很多参与方和新概念，例如：

• 服务器实体：需要申请证书的实体（如某个域名的拥有者）


• CA机构：签发证书的机构


• 证书仓库：CA 签发的证书全部保存到仓库中，证书可能过期或被吊销。


• 证书校验方：校验证书真实性的软件，例如浏览器、客户端等。

这些参与方、概念和流程的集合被称为公钥基础设施（Public Key Infrastructure）

X.509 标准

为了能够将这套基础设施跑通，需要遵循一些标准，最常用的标准是 X.509，其内容包括：

• 如何定义证书文件的结构（使用 ANS.1 来描述证书）


• 如何管理证书（申请证书的流程，审核身份的标准，签发证书的流程）


• 如何校验证书（证书签名校验，校验实体属性，比如的域名、证书有效期等）


• 如何对证书进行撤销（包括 CRL 和 OCSP 协议等概念）

X.509标准在网络安全中广泛使用，特别是在 TLS/SSL 协议中用于验证服务器和客户端的身份。在 Node.js 中，当 tls 通道创建之后，可以通过下面两个方法获取客户端和服务端 X.509 证书：

• 获取本地 X.509 证书：getX509Certificate


• 获取对方 X.509 证书：getPeerX509Certificate

生成证书

要想生成证书，首要有一个私钥（private key），私钥的生成方式为：

$ openssl genrsa -out key.pem 2048

会生成一个 key.pem 文件，内容如下：

-----BEGIN PRIVATE KEY-----

MIIEvgIBADANBgkqhkiG9w0BAQEFAASCB....

-----END PRIVATE KEY-----

然后，还需要一个与私钥相对应的公钥（public key），生成方式：

$ openssl req -new -sha256 -key key.pem -out csr.pem

按照提示操作即可，下面是示例输入（中国-浙江省-杭州市-西湖-苏堤-keliq）：

You are about to be asked to enter information that will be incorporated

int0 your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [AU]:CN

State or Province Name (full name) [Some-State]:Zhejiang

Locality Name (eg, city) []:Hangzhou

Organization Name (eg, company) [Internet Widgits Pty Ltd]:West Lake

Organizational Unit Name (eg, section) []:Su Causeway

Common Name (e.g. server FQDN or YOUR name) []:keliq

Email Address []:email@example.com   



Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:123456

An optional company name []:XiHu

生成的文件内容如下：

-----BEGIN CERTIFICATE REQUEST-----

MIIDATCCAekCAQAwgY8xCzAJBgNVBAYTAkNOMREw...

-----END CERTIFICATE REQUEST-----

公钥文件创建之后，接下来有两个选择：

• 将其发送给 CA 机构，让其进行签名


• 自签名

自签名

如果是本地开发，我们选择自签名的方式就行了，openssl 同样提供了命令：

$ openssl x509 -req -in csr.pem -signkey key.pem -out cert.pem

Certificate request self-signature ok

subject=C = CN, ST = Zhejiang, L = Hangzhou, O = West Lake, OU = Su Causeway, CN = keliq, emailAddress = email@example.com

最终得到了 cert.pem，内容如下：

-----BEGIN CERTIFICATE-----

MIIDpzCCAo8CFAf7LQmMUweTSW+ECkjc7g1uy3jCMA0...

-----END CERTIFICATE-----

到这里，所有环节都走完了，再来回顾一下，总共生成了三个文件，环环相扣：

• 首先生成私钥文件 key.pem


• 然后生成与私钥对应的公钥文件 csr.pem


• 最后用公私钥生成证书 cert.pem

实战——信任根证书

用上面自签名创建的证书来创建 https 服务：

const options = {

  key: fs.readFileSync('key.pem'),

  cert: fs.readFileSync('cert.pem'),

}

启动之后，如果你在浏览器中访问，会发现出错了：

命名是 https 服务，为什么浏览器说不是私密连接呢？因为自签名证书默认是不被浏览器信任的，只需要将 cert.pem 拖到钥匙里面即可，然后修改为「始终信任」，过程中需要验证指纹或者输入密码：

如果你觉得上述流程比较繁琐，可以用下面的命令行来完成：

$ sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain cert.pem

实战——指定主题备用名称

然而，即使添加了钥匙串信任，问题似乎并没有解决，报错还是依旧：

仔细看，其实报错信息发生了变化，从原来的 NET::ERR_CERT_AUTHORITY_INVALID 变成了 NET::ERR_CERT_COMMON_NAME_INVALID，这又是怎么回事呢？我们点开高级按钮看一下详细报错：

这段话的意思是：当前网站的 SSL 证书中的通用名称（Common Name）与实际访问的域名不匹配。

证书中会包含了一个通用名称字段，用于指定证书的使用范围。如果证书中的通用名称与您访问的域名不匹配，浏览器会出现NET::ERR_CERT_COMMON_NAME_INVALID错误。

一句话描述，证书缺少了主题备用名称（subjectAltName），而浏览器校验证书需要此字段。为了更好的理解这一点，我们可以用下面的命令查看证书的完整信息：

$ openssl x509 -in cert.pem -text -noout

输出结果如下：

Certificate:

    Data:

        Version: 1 (0x0)

        Serial Number:

            07:fb:2d:09:8c:53:07:93:49:6f:84:0a:48:dc:ee:0d:6e:cb:78:c2

        Signature Algorithm: sha256WithRSAEncryption

        Issuer: C = CN, ST = Zhejiang, L = Hangzhou, O = West Lake, OU = Su Causeway, CN = keliq, emailAddress = email@example.com

        Validity

            Not Before: Nov 15 06:29:36 2023 GMT

            Not After : Dec 15 06:29:36 2023 GMT

        Subject: C = CN, ST = Zhejiang, L = Hangzhou, O = West Lake, OU = Su Causeway, CN = keliq, emailAddress = email@example.com

        Subject Public Key Info:

            Public Key Algorithm: rsaEncryption

                Public-Key: (2048 bit)

                Modulus:

                    00:ac:63:b1:f1:7a:69:aa:84:ef:9d:0e:be:c1:f7:

                    80:3f:6f:59:e1:7d:c5:c6:db:ff:2c:f3:99:12:7f:

                    ...

                Exponent: 65537 (0x10001)

    Signature Algorithm: sha256WithRSAEncryption

    Signature Value:

        70:d9:59:10:46:dc:7b:b3:19:c8:bd:4b:c5:70:4f:89:b6:6a:

        53:1c:f2:35:27:c8:0a:ed:a8:0a:13:1f:46:3e:e7:a7:ff:1f:

        ...

我们发现，这个证书并没有 Subject Alternative Name 这个字段，那如何增加这个字段呢？有两种方式：

指定 extfile 选项

$ openssl x509 -req \

  -in csr.pem \

  -signkey key.pem \

  -extfile <(printf "subjectAltName=DNS:localhost") \

  -out cert.pem

再次用命令查看证书详情，可以发现 Subject Alternative Name 字段已经有了：

...

X509v3 extensions:

    X509v3 Subject Alternative Name: 

        DNS:localhost

    X509v3 Subject Key Identifier: 

        21:65:8F:93:49:BC:DF:8C:17:1B:6C:43:AC:31:3C:A9:34:3C:CB:77

...

用新生成的 cert.pem 启动 https 服务，再次访问就正常了，可以点击小锁查看证书详细信息：

但是如果把 localhost 换成 127.0.0.1 的话，访问依然被拒绝，因为 subjectAltName 只添加了 localhost 这一个域名，所以非 localhost 域名使用此证书的时候，浏览器就会拒绝。

新建 .cnf 文件

这次我们新建一个 ssl.cnf 文件，并在 alt_names 里面多指定几个域名：

[req]

prompt = no

default_bits = 4096

default_md = sha512

distinguished_name = dn

x509_extensions = v3_req



[dn]

C=CN

ST=Zhejiang

L=Hangzhou

O=West Lake

OU=Su Causeway

CN=keliq

emailAddress=keliq@example.com



[v3_req]

keyUsage = nonRepudiation, digitalSignature, keyEncipherment

subjectAltName=@alt_names



[alt_names]

DNS.1 = localhost

IP.2 = 127.0.0.1

IP.3 = 0.0.0.0

然后一条命令直接生成密钥和证书文件：

$ openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 \

  -config openssl.cnf \

  -keyout key.pem \

  -out cert.pem 

再次查看证书详情，观察 Subject Alternative Name 字段：

...

X509v3 extensions:

      X509v3 Key Usage: 

          Digital Signature, Non Repudiation, Key Encipherment

      X509v3 Subject Alternative Name: 

          DNS:localhost, IP Address:127.0.0.1, IP Address:0.0.0.0

      X509v3 Subject Key Identifier: 

          B6:FC:1E:68:CD:8B:97:D0:80:0E:F1:18:D3:39:86:29:90:0B:9D:1F

...

这样无论是访问 localhost 还是 127.0.0.1 或者 0.0.0.0，浏览器都能够信任。

这个功能放在之前是不可能实现的，因为考虑到用户的隐私，但是最近有一个新的api可以做到这一点。下面来进行一个简单的功能实现。

如何选择文件夹

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <title>Title</title>

</head>

<body>

  <button>打开文件夹</button>

  <script>

    var btn = document.querySelector('button');

    btn.onclick=function() {

        showDirectoryPicker()

    }

  </script>

</body>



</html>

我们调用showDirectoryPicker这个函数就可以实现一个选择文件夹的功能。

showDirectoryPicker()

• options 可选
  
  

  选项对象，包含以下属性：id通过指定 ID，浏览器能够记住不同 ID 所对应的目录。当使用相同的 ID 打开另一个目录选择器时，选择器会打开相同的目录。mode字符串，默认为 "read"，可对目录进行只读访问。设为 "readwrite" 可对目录进行读写访问。startIn一个 FileSystemHandle 对象或者代表某个众所周知的目录的字符串（如："desktop"、"documents"、"downloads"、"music"、"pictures"、"videos"）。用于指定选择器的起始目录。

返回值

一个 Promise 对象，会兑现一个 FileSystemDirectoryHandle (en-US) 对象。

异常

• AbortError
  
  

  当用户直接关闭了目录选择器或选择的目录是敏感目录时将会抛出 AbortError。

如何得到文件夹中的文件/子文件夹

首先对于上面所写的东西，我们进行try catch的优化

try {

  // 获得文件夹的句柄

  const handle = await showDirectoryPicker();

}

catch {

  //用户拒绝查看文件

  alert('访问失败')

}

之后我们来看一下这个headler打印出来是什么

句柄的简单解释

对于“句柄”，在下一直停留在一知半解的认识层面，近日在下学习Windows编程，决定趁此机会将句柄彻底搞清楚。查阅了一些网络上的资料，发现网络上的讲解大概可以分为两类：一种是以比喻、类比的方式说明，这种方法虽然形象易懂，但并没有从原理上、本质上加以揭示，让人仍然想问“为什么？”、“怎么实现？”。另一种是给出源代码，无可厚非，这当然是最本质的说明了，但这样一来，又显得不够直观，初学者理解起来有一定的难度。鉴于此，在下尽微末之能，结合自己的愚见，在两者之间折中，用图解的方式来将原理呈现出来，做到一目了然。

这里需要说明：

1.这里将句柄所能标识的所有东西（如窗口、文件、画笔等）统称为“对象”。

2.图中一个小横框表示一定大小的内存区域，并不代表一个字节，如标有0X00000AC6的横框表示4个字节。

3.图解的目的是为了直观易懂，所以不一定与源码完全对应，会有一定的简化。

让我们先看图，再解释。

其中，图1是程序运行到某时刻时的内存快照，图2是程序往后运行到另一时刻时的内存快照。红色部分标出了两次的变化。

简单解释：

Windows是一个以虚拟内存为基础的操作系统，很多时候，进程的代码和数据并不全部装入内存，进程的某一段装入内存后，还可能被换出到外存，当再次需要时，再装入内存。两次装入的地址绝大多数情况下是不一样的。也就是说，同一对象在内存中的地址会变化。（对于虚拟内存不是很了解的读者，可以参考有关操作系统方面的书籍）那么，程序怎么才能准确地访问到对象呢？为了解决这个问题，Windows引入了句柄。

系统为每个进程在内存中分配一定的区域，用来存放各个句柄，即一个个32位无符号整型值（32位操作系统中）。每个32位无符号整型值相当于一个指针，指向内存中的另一个区域（我们不妨称之为区域A）。而区域A中存放的正是对象在内存中的地址。当对象在内存中的位置发生变化时，区域A的值被更新，变为当前时刻对象在内存中的地址，而在这个过程中，区域A的位置以及对应句柄的值是不发生变化的。这种机制，用一种形象的说法可以表述为：有一个固定的地址（句柄），指向一个固定的位置（区域A），而区域A中的值可以动态地变化，它时刻记录着当前时刻对象在内存中的地址。这样，无论对象的位置在内存中如何变化，只要我们掌握了句柄的值，就可以找到区域A，进而找到该对象。而句柄的值在程序本次运行期间是绝对不变的，我们（即系统）当然可以掌握它。这就是以不变应万变，按图索骥，顺藤摸瓜。

**所以，我们可以这样理解Windows **句柄：

数值上，是一个32位无符号整型值（32位系统下）；逻辑上，相当于指针的指针；形象理解上，是Windows中各个对象的一个唯一的、固定不变的ID；作用上，Windows使用句柄来标识诸如窗口、位图、画笔等对象，并通过句柄找到这些对象。

下面，关于句柄，再交代一些关键性细节：

1.所谓“唯一”、“不变”是指在程序的一次运行中。如果本次运行完，关闭程序，再次启动程序运行，那么这次运行中，同一对象的句柄的值和上次运行时比较，一般是不一样的。

其实这理解起来也很自然，所谓“一把归一把，这把是这把，那把是那把，两者不相干”（“把”是形象的说法，就像打牌一样，这里指程序的一次运行）。

2.句柄是对象生成时系统指定的，属性是只读的，程序员不能修改句柄。

3.不同的系统中，句柄的大小（字节数）是不同的，可以使用sizeof()来计算句柄的大小。

4.通过句柄，程序员只能调用系统提供的服务（即API调用），不能像使用指针那样，做其它的事。

再回归正题。

处理句柄函数

async function processHandler(handle) {

  if (handle.kind==='file'){

    return handle

  }

    handle.children=[]

    const iter = await handle.entries();//获得文件夹中的所有内容

    //iter:异步迭代器

    for await (const info of iter){

      var subHandle = await processHandler(info[1]);

      handle.children.push(subHandle)

    }

    return handle

}

如何得到文件内容

const root = await processHandler(handle);

//   获得文件内容

 const file = await root.children[1].getFile();

 const reader = new FileReader();

 reader.onload=e=>{

   // 读取结果

   console.log(e.target.result)

 }

 reader.readAsText(file,'utf-8')

这里用到的就是一个很简单的文件读了。

下面是完整的代码

<!DOCTYPE html>

<html lang="en">

<head>

    <meta charset="UTF-8">

    <title>Title</title>

</head>

<body>

  <button>打开文件夹</button>

  <script>

    var btn = document.querySelector('button');

    btn.onclick=async function() {



      try {

         // 获得文件夹的句柄

         const handle = await showDirectoryPicker();

         const root = await processHandler(handle);

       //   获得文件内容

        const file = await root.children[1].getFile();

        const reader = new FileReader();

        reader.onload=e=>{

          // 读取结果

          console.log(e.target.result)

        }

        reader.readAsText(file,'utf-8')

       }

       catch {

         //用户拒绝查看文件

         alert('访问失败')

       }

    }

    async function processHandler(handle) {

      if (handle.kind==='file'){

        return handle

      }

        handle.children=[]

        const iter = await handle.entries();//获得文件夹中的所有内容

        //iter:异步迭代器

        for await (const info of iter){

          var subHandle = await processHandler(info[1]);

          handle.children.push(subHandle)

        }

        return handle

    }

  </script>

</body>



</html>

1. 分享目标：

2. 什么是微前端？

故事开始于三年前…

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

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

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

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

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

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

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

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

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

3. 主流技术方向分类

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

3.1. 革新派 qiankun

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

3.1.1. 原理：

3.1.1.1. 基于 single-spa

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

3.1.1.2. 样式隔离

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

1. 默认模式。

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

2. 严格模式。

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

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

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

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

3. 实验模式。

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

3.1.1.3. JS 沙箱

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

1. 快照沙箱（ snapshotSandbox ）

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

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

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

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

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

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

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

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

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

3.1.2. 优势：

3.1.2.1. 具有先发优势

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

3.1.2.2. 开箱即用

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

3.1.2.3. 对 umi 用户更加友好

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

3.1.3. 劣势：

3.1.3.1. vite 支持性差

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

const jsCode = `

(function(window, self, globalThis){

    with(this){

      // your code

      window.a = 1;

      b = 2

      ...

	}

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

` 

eval(jsCode)

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

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

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

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

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

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

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

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

3.2. 改良派 wujie

3.2.1. 原理：

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

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

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

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

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

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

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

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

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

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

3.2.2. 优势：

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

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

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

3.2.2.2. vite 兼容性好

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

3.2.2.3. iframe 沙箱隔离性好

3.2.3. 劣势：

3.2.3.1. 坑比较多

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

  具体问题描述见下图：

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

手动的解决方案：

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

3.2.3.2. 长期维护性一般。

3.2.3.3. 内存开销较大

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

3.3. 中间派 micro-app

3.3.1. 原理：

京东的大前端团队出品。

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

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

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

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

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

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

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

3.3.2. 优势：

3.3.2.1. 支持的功能最丰富。

3.3.2.2. 接入成本低。

3.3.2.3. 文档完善。

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

3.3.3. 劣势：

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

3.3.3.2. 静态资源补全问题。

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

4. 选型建议

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

1. 刚性建议。

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

2. 综合推荐。

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

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

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

最后

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

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

如果您听说过Service Mesh并尝试过Istio，您可能会有以下问题：

本文将带您了解 Kubernetes 和 Istio 的内部工作原理。另外，我还会介绍 Kubernetes 中的负载均衡方法，并解释为什么有了 Kubernetes 还需要 Istio。

Kubernetes 本质上是通过声明性配置进行应用程序生命周期管理，而服务网格本质上是提供应用程序间流量、安全管理和可观察性。如果你已经使用 Kubernetes 搭建了一个稳定的应用平台，那么如何为服务之间的调用设置负载均衡和流量控制呢？这就是服务网格发挥作用的地方。

Envoy 引入了 xDS 协议，该协议受到各种开源软件的支持，例如Istio、MOSN等。Envoy 将 xDS 贡献给服务网格或云原生基础设施。Envoy 本质上是一个现代版本的代理，可以通过 API 进行配置，并基于它衍生出许多不同的使用场景——例如 API 网关、服务网格中的 sidecar 代理和边缘代理。

本文包含以下内容：

• kube-proxy 作用的描述。


• Kubernetes 对于微服务管理的局限性。


• 介绍 Istio 服务网格的功能。


• Kubernetes、Envoy 和 Istio 服务网格中一些概念的比较。

Kubernetes 与服务网格

下图展示了 Kubernetes 和 Service Mesh（每个 pod 一个 sidecar 模型）中的服务访问关系。

流量转发

Kubernetes 集群中的每个节点都会部署一个 kube-proxy 组件，该组件与 Kubernetes API Server 通信，获取集群中服务的信息，然后设置 iptables 规则，将服务请求直接发送到对应的 Endpoint（属于该集群的 pod）。同一组服务）。

服务发现

Istio 可以跟随 Kubernetes 中的服务注册，还可以通过控制平面中的平台适配器与其他服务发现系统对接；然后使用数据平面的透明代理生成数据平面配置（使用 CRD，存储在 etcd 中）。数据平面的透明代理作为sidecar容器部署在每个应用服务的pod中，所有这些代理都需要请求控制平面同步代理配置。代理是“透明的”，因为应用程序容器完全不知道代理的存在。该进程中的 kube-proxy 组件也需要拦截流量，只不过 kube-proxy 拦截进出 Kubernetes 节点的流量，而 sidecar 代理拦截进出 pod 的流量。

服务网格的缺点

由于 Kubernetes 每个节点上运行有很多 pod，将原有的 kube-proxy 路由转发功能放在每个 pod 中会增加响应延迟（由于 sidecar 拦截流量时的跳数更多）并消耗更多资源。为了以细粒度的方式管理流量，将添加一系列新的抽象。这会进一步增加用户的学习成本，但随着技术的普及这种情况会慢慢得到缓解。

服务网格的优点

kube-proxy 设置是全局的，无法对每个服务进行精细控制，而服务网格通过 sidecar 代理将流量控制从 Kubernetes 的服务层中取出，从而实现更大的弹性。

Kube-Proxy 的缺点

首先，如果转发的 Pod 无法正常服务，它不会自动尝试另一个 Pod。每个 pod 都有健康检查机制，当 pod 出现健康问题时，kubelet 会重启 pod，kube-proxy 会删除相应的转发规则。此外，nodePort 类型的服务无法添加 TLS 或更复杂的消息路由机制。

Kube-proxy 实现了 Kubernetes 服务的多个 pod 实例之间的流量负载均衡，但是如何对这些服务之间的流量进行细粒度控制——例如将流量按百分比划分到不同的应用程序版本（这些版本都是同一个应用程序的一部分）服务但在不同的部署上），或者进行灰度发布和蓝绿发布？

Kubernetes 社区提供了一种使用 Deployment 进行灰度发布方法，这本质上是一种通过修改 pod 标签将不同 pod 分配给部署服务的方法。

Kubernetes Ingress 与 Istio 网关

如上所述，kube-proxy 只能在 Kubernetes 集群内路由流量。Kubernetes 集群的 Pod 位于 CNI 创建的网络中。入口（在 Kubernetes 中创建的资源对象）是为了集群外部的通信而创建的。它由位于 Kubernetes 边缘节点上的入口控制器驱动，负责管理南北流量。Ingress 必须对接各种 Ingress Controller，例如nginx ingress 控制器。Ingress仅适用于HTTP流量，使用简单。它只能通过匹配有限数量的字段（例如服务、端口、HTTP 路径等）来路由流量。这使得无法路由 MySQL、Redis 和各种 RPC 等 TCP 流量。这就是为什么你会看到人们在入口资源注释中编写 nginx 配置语言。直接路由南北流量的唯一方法是使用服务的 LoadBalancer 或 NodePort，前者需要云供应商支持，后者需要额外的端口管理。

Istio Gateway 的功能与 Kubernetes Ingress 类似，负责进出集群的南北向流量。Istio Gateway 描述了一种负载均衡器，用于承载进出网格边缘的连接。该规范描述了一组开放端口以及这些端口使用的协议、用于负载均衡的 SNI 配置等。 Gateway 是一个 CRD 扩展，它也重用了 sidecar 代理的功能；详细配置请参见Istio 网站。

Envoy

Envoy 是 Istio 中默认的 sidecar 代理。Istio 基于 Enovy 的 xDS 协议扩展了其控制平面。在谈论 Envoy 的 xDS 协议之前，我们需要先熟悉一下 Envoy 的基本术语。以下是 Envoy 中的基本术语及其数据结构列表；请参阅Envoy 文档了解更多详细信息。

基本术语

以下是您应该了解的 Enovy 基本术语。

• Downstream：下游主机连接 Envoy，发送请求，接收响应；即发送请求的主机。


• Upstream：上游主机接收来自 Envoy 的连接和请求并返回响应；即接收请求的主机。


• Listener：Listener 是一个命名的网络地址（例如端口、UNIX 域套接字等）；下游客户端可以连接到这些侦听器。Envoy 向下游主机公开一个或多个侦听器以进行连接。


• Cluster：集群是 Envoy 连接的一组逻辑上相同的上游主机。Envoy 通过服务发现来发现集群的成员。或者，可以通过主动健康检查来确定集群成员的健康状态。Envoy 通过负载均衡策略决定集群中的哪个成员来路由请求。

Envoy 中可以设置多个监听器，每个监听器可以设置一个过滤器链（过滤器链表），并且过滤器是可扩展的，以便我们可以更轻松地操纵流量的行为——例如设置加密、私有 RPC 等。

xDS 协议由 Envoy 提出，是 Istio 中默认的 sidecar 代理，但只要实现了 xDS 协议，理论上就可以在 Istio 中用作 sidecar 代理——比如蚂蚁集团开源的MOSN。

Istio 是一个功能非常丰富的服务网格，包括以下功能。

• 流量管理：这是Istio最基本的功能。


• 策略控制：启用访问控制系统、遥测捕获、配额管理、计费等。


• 可观察性：在 sidecar 代理中实现。


• 安全身份验证：Citadel 组件执行密钥和证书管理。

Istio 中的流量管理

Istio 中定义了以下 CRD 来帮助用户进行流量管理。

• 网关：网关描述了运行在网络边缘的负载均衡器，用于接收传入或传出的 HTTP/TCP 连接。


• VirtualService：VirtualService 实际上将 Kubernetes 服务连接到 Istio 网关。它还可以执行其他操作，例如定义一组在寻址主机时应用的流量路由规则。


• DestinationRule：DestinationRule 定义的策略决定流量经过路由后的访问策略。简而言之，它定义了流量的路由方式。其中，这些策略可以定义为负载均衡配置、连接池大小和外部检测（用于识别并驱逐负载均衡池中不健康的主机）配置。


• EnvoyFilter：EnvoyFilter 对象描述代理服务的过滤器，可以自定义 Istio Pilot 生成的代理配置。这种配置一般初级用户很少使用。


• ServiceEntry：默认情况下，Istio 服务网格中的服务无法发现网格之外的服务。ServiceEntry 允许将其他条目添加到 Istio 内的服务注册表中，从而允许网格中自动发现的服务访问并路由到这些手动添加的服务。

Kubernetes、xDS、Istio

回顾了 Kubernetes 的 kube-proxy 组件、xDS 和 Istio 中流量管理的抽象之后，现在让我们仅在流量管理方面对这三个组件/协议进行比较（请注意，这三个组件并不完全相同）。

要点

• Kubernetes 的本质是应用程序生命周期管理，特别是部署和管理（伸缩、自动恢复、发布）。


• Kubernetes 为微服务提供了可扩展且高弹性的部署和管理平台。


• 服务网格基于透明代理，通过 sidecar 代理拦截服务之间的流量，然后通过控制平面配置管理它们的行为。


• 服务网格将流量管理与 Kubernetes 解耦，无需 kube-proxy 组件来支持服务网格内的流量；通过提供更接近微服务应用程序层的抽象来管理服务间流量、安全性和可观察性。


• xDS 是服务网格配置的协议标准之一。


• 服务网格是 Kubernetes 中服务的更高级别抽象。

概括

如果说 Kubernetes 管理的对象是 Pod，那么 Service Mesh 管理的对象就是服务，所以只要用 Kubernetes 来管理微服务，然后应用 Service Mesh 就可以了。如果您甚至不想管理服务，那么可以使用像Knative这样的无服务器平台z。

最近五阳遇到了线上资损问题，我开始重视分布式事务的数据一致性问题，拿我擅长的场景分析下。

举个🌰例子

在付费会员场景，用户购买会员后享受会员权益。在会员售后场景，用户提交售后，系统需要冻结权益并且原路赔付退款。

系统如何保证冻结权益和订单退款的数据一致性呢？当无法保证数据一致时，会导致什么问题呢？

通过这个例子可以看到电商场景中，数据不一致可能会导致资金损失。这是电商场景对数据一致性要求高的原因，很多资损（资金损失）问题都是源于数据不一致。

如何理解数据一致性，一致性体现在哪里?

狭义上的数据一致是指：数据完全相同，在数据库主从延迟场景，主从数据一致是指：主数据副本和从数据副本，数据完全相同，客户端查询主库和查询从库得到的结果是相同的，也就是一致的。

除数据多副本场景使用数据一致性的概念之外，扩展后其他场景也使用这个概念。例如分布式事务中，多个事务参与者各自维护一种数据，当多种数据均处于合法状态且符合业务逻辑的情况下，那就可以说整体处于数据一致了。（并不像副本场景要求数据完全相同）

例如会员订单有支付状态和退款状态，会员优惠券有未使用状态和冻结状态。 在一次分布式事务执行前后，订单和优惠券的状态是一致的，即会员订单退款、会员券冻结；会员订单未退款，会员券状态为可使用；

此外还有异构数据一致性，超时一致。异构数据一致性是指同一种数据被异构到多种存储中间件。例如本地缓存、Redis缓存和数据库，即三级缓存的数据一致性。还有搜索场景，需要保证数据库数据和 ElasticSearch数据一致性，这也是分布式事务问题。

一致性和原子性的区别

原子性 指的是事务是一个不可分割的最小工作单元，事务中的操作要么全部成功，要么全部失败。

一致性 指的是事务执行前后，所有数据均处于一致性状态，一致性需要原子性的支持。如果没有实现原子性，一致性也无法实现。一致性在原子性的基础上，还要求实现数据的正确性。例如在同一个事务中实现多商品库存扣减，多个SQL除了保证同时成功同时失败外，还需要保证操作的正确性。如果所有SQL都返回成功了，但是数据是错误的，这无法接受。这就是一致性的要求。

由此可见，数据一致性本身就要求了数据是正确的。

隔离性是指：其他事务并发访问同一份数据时，多个事务之间应该保持隔离性。隔离性级别：如读未提交、‌读已提交、‌可重复读和串行化。

隔离性强调的是多个事务之间互不影响的程度，一致性强调的是一个事务前后，数据均处于一致状态。

什么是强一致性

在分布式事务场景，强一致性是指：任何一个时刻，看到各个事务参与者的数据都是一致的。系统不存在不一致的情况。

值得一提的是，CAP理论指出，数据存在多副本情况下，要保证强一致性（在一个绝对时刻，两份数据是完全一致的）需要牺牲可用性。

也就是说系统发现自身处于不一致状态时，将向用户返回失败状态。直至数据一致后，才能返回最新数据，这将牺牲可用性。

为了保证系统是可用的，可以返回旧的数据，但是无法保证强一致性。

会员售后能保证强一致性吗？

会员售后关键的两个动作：权益冻结和订单退款。 两者能保证强一致性吗？答案是不能。假设权益冻结是一个本地事务性操作，但是订单退款包括订单状态流程、支付系统资金流转等等。

如此复杂的流程难以保证任意一个绝对时刻，用户看到权益冻结后，资金一定到账了；这是售后场景 无法达到强一致性的根本原因。

最终一致性和强一致性

最终一致性不要求系统在任意一个时刻，各参与方数据都是一致的，它要求各参与方数据在一定时间后处于一致状态。

最终一致性没有明确这个时间是多长，所以有人说最终一致性就是没有一致性，谁知道多久一定能保证一致呢。

保证最终一致性的手段有哪些？

TCC

TCC 包含 Try、Confirm 和 Cancel 三个操作。

需要说明，如果Confirm执行失败，需要不停不重试Confirm，不得执行Cancel。 按照TCC的语义 Try操作已经锁定了、预占了资源。 Confirm在业务上一定是可以成功的。

TCC的问题在于 分布式事务的任意一个操作都应该提供三个接口，每个参与者都需要提供三个接口，整体交互协议复杂，开发成本高。当发生嵌套的分布式事务时，很难保证所有参与者都实现TCC规范。

为什么TCC 方案包含Try

如果没有Try阶段，只有Confirm和 Cancel阶段，如果Confirm失败了，则调用Cancel回滚。为什么Tcc不这样设计呢？

引入Try阶段，为保证不发生状态回跳的情况。

Try阶段是预占资源阶段，还未实际修改资源。设想资金转账场景， A账户向B账户转账100元。 在Try阶段 A账户记录了预扣100元，B 账户记录了预收100元。 如果A账户不足100元，那么Try阶段失败，调用Cancel回滚，这种情况，在任意时刻，A、B用户视角转账是失败的。

Try阶段成功，则调用Confirm接口，最终A账户扣100元，B收到100元。虽然这无法保证在某个时刻，A、B账户资金绝对一致。但是如果没有Try阶段，那么将发生 状态回跳的情况；

状态回跳：即A账户操作成功了，但是B账户操作失败，A账户资金又被回滚了。那么用户A 看到自己的账户状态就是 钱被扣了，但是过一会钱又回来了。

同理B账户也可能遇到收到钱了，但是过一会钱又没了。在转账场景，这种回跳情况几乎是不能接受的。

引入了Try阶段，就能保证不发生状态回跳的情况。

最大努力通知

最大努力通知是指通知方通过一定的机制最大努力将业务处理结果通知到接收方。一般用于最终一致性时间敏感度低的场景，并且接收方的结果不会影响到发起方的结果。即接收方处理失败时，发送方不会跟随回滚。

在电商场景，很多场景使用最大努力通知型作为数据一致性方案。

会员售后如何保证最终一致性？

回到开头的问题，以下是数据不一致的两种情况。

平台资损难以追回，当发生容易复现的平台资损时，会引来更多的用户“薅羊毛”，资损问题将进一步放大，所以平台资损一定要避免。

当发生用户资损时，用户可以通过客服向平台追诉，通过人工兜底的方式，可以保证“最终”数据是一致的。

所以基于这个大的原则，大部分系统都是优先冻结会员权益，待用户权益明确冻结后，才根据实际冻结情况，向用户退款。这最大程度上保证了售后系统的资金安全。

会员售后整体上是最大努力通知一致性方案。当权益冻结后，系统通过可重试的消息触发订单退款，且务必保证退款成功（即便是人工介入情况下）。虽说是最大努力通知型，但不代表一致性弱，事实上支付系统的稳定性要求是最高级别的，订单退款成功的可靠性是能得到保证的。

如果权益冻结是分布式事务，如何保证一致性

一开始我们假设权益冻结是一个本地事务，能保证强一致性，这通常与实际不符。权益包含很多玩法，例如优惠券、优惠资格、会员日等等，权益冻结并非是本地事务，而是分布式事务，如何保证一致性呢？

方案1 TCC方案

假设 权益系统包含三个下游系统，身份系统（记录某个时间段是会员）、优惠券系统、优惠资格系统。 TCC方案将要求三方系统均实现 Try、Confirm、Cancel接口。开发成本和上下游交付协议比较复杂。

方案2 无Try 的 TCC方案

假设无Try阶段，直接Confirm修改资源，修改失败则调用Cancel，那么就会出现状态跳回情况，即优惠券被冻结了，但是后面又解冻了。

这种情况下，系统只需要实现扣减资源和回滚资源 两种接口。 系统设计大大简化

方案3 Prepare + Confirm

Prepare: 检查接口，即检查资源是否可以被修改，但是不会锁定资源。

Confirm: 修改资源接口，实际修改资源状态。

如果Prepare失败，则返回执行失败，由于未预占用资源，所以无需回滚资源。在Prepare成功后，则立即调用Confirm。如果Confirm执行失败，则人工介入。

一定需要回滚吗？

在一致性要求高的场景，需要资源回滚能力，保证系统在一定时间后处于一致状态。如果没有回滚，势必导致在某些异常情况下，系统处于不一致状态，且无法自动恢复。

会员售后场景虽然对资金较为敏感，但不需要资源回滚。理由如下

在上述方案3中，先通过Prepare阶段验证了参与方都是可以冻结的，在实际Confirm阶段这个状态很难发生改变。所以大概率Confirm不会失败的。

只有极低的概率发生Confirm失败的情况，即用户在权益冻结的一瞬间，使用优惠券，这将导致资源状态发生改变。

解决此类问题，可以在权益冻结后，评估冻结结果，根据实际的冻结结果，决定如何赔付用户，赔付用户多少钱。所以用户并发用券，也不会影响资金安全。

人工兜底与数据一致性

程序员应该在业务收益、开发成本、数据不一致风险等多个角度评估系统设计的合理性。

会员售后场景，看似数据一致性要求高，仿佛数据不一致，就会产生严重的资损问题。但实际分析后，系统并非需要严格的一致性。

越是复杂的系统设计，系统稳定性越差。越是简洁的系统设计，系统稳定性越高。当选择了复杂的系统设计提高数据一致性，必然需要付出更高的开发成本和维护成本。往往适得其反。

当遇到数据一致性挑战时，不妨跳出技术视角，尝试站在产品视角，思考能否适当调整一下产品逻辑，容忍系统在极端情况下，有短暂时间数据不一致。人工兜底处理极端情况。

大多数情况下，产品经理会同意。

Docker容器日志过大？有没有比较简单的方式解决？

1. 问题描述

当我们尝试查看特定 Docker 容器的日志时，通常会使用 docker logs <容器名称> 命令。然而，有时候会发现控制台持续输出日志信息，持续时间可能相当长，直到最终打印完成。这种现象往往源自对 Docker 容器日志长时间未进行处理，导致日志积累过多，占用了系统磁盘空间。因此，为了释放磁盘空间并优化系统性能，我们可以采取一些简单而有效的方法来处理这些庞大的日志文件。

2. docker日志处理机制

需要处理问题，那我们肯定要先了解docker的日志处理机制，了解了基本的机制，能够帮助我们更好的理解问题并解决问题。

2.1 日志查看

docker logs <容器名称>可以查看docker容器的输出日志，但是这里的日志主要包含标准输出和标准错误输出，一些容器可能会把日志输出到某个日志文件中，比如tomcat，这样使用docker logs <容器名称>命令是无法查看的。

注意docker logs命令查看的是容器的全部日志，当日志量很大时会对容器的运行造成影响，可以通过docker logs --tail N container name查看最新N行的数据，N是一个整数。

2.2 处理机制

当我们启动一个docker容器时，实际上时作为docker daemon的一个子进程运行的，docker daemon可以拿到容器里进程的标准输出与标准错误输出，并通过docker的log driver模块来处理，大致图示如下：

上面图中所列举的就是所支持的Log Driver：

• none：容器没有日志，docker logs不输出任何内容


• local：日志以自定义格式存储


• json-file：日志以json格式存储，默认的Log Driver


• syslog：将日志写入syslog。syslog守护程序必须在主机上运行


• journald：将日志写入journald。journald守护程序必须在主机上运行


• gelf：将日志写入Graylog Extended Log Format端点，如Graylog或Logstash


• fluentd：将日志写入fluentd。fluentd守护程序必须在主机上运行


• awslogs：将日志写入Amazon CloudWatch Logs


• splunk：通过HTTP Event Collector将日志写入splunk


• etwlogs：将日志作为ETW（Event Tracing for Windows）事件写入。只在Windows平台可用


• gcplogs：将日志写入Google Cloud Platform Logging


• logentries：将日志写入Rapid7 Logentries

可以使用命令docker info | grep "Logging Driver"

2.3 默认的json-file

json-file Log Driver是Docker默认启用的Driver，将容器的STDOUT/STDERR输出以json的格式写到宿主机的磁盘，日志文件路径为 /var/lib/docker/containers/{container_id}/{container_id}-json.log

格式是这样的：

json-file将每一行日志封装到一个json字符串中。

json-file支持如下配置：

• max-size：单个日志文件的最大大小，单位可以为k、m、g，默认是-1，表示日志文件可以无限大。


• max-file：最多可以存多少个日志文件，默认数量是1，当默认数量大于1时，每个日志文件达到最大存储大小，且数量达到设置数量，产生新日志时会删除掉最旧的一个日志文件。


• labels：指定日志所使用到的标签，使用逗号分割。比如traceId,message两个标签。


• env：指定与日志相关的环境变量，使用逗号分割


• env-rejex：一个正则表达式来匹配与日志相关的环境变量


• compress：是否压缩日志文件

3. 如何解决？

3.1 查看日志大小

我们可以通过如下脚本获取当前所有容器的日志大小，这里时使用docker默认的json-file的形式：

#!/bin/sh 

echo "======== docker containers logs file size ========"  



logs=$(find /var/lib/docker/containers/ -name *-json.log)



for log in $logs

do

    ls -lh $log

done

执行脚本：

json-file的命令开头的一小串字符时容器的id。

例如我有一个docker容器id是2de6f164ee11，我们可以适当修改shell脚本，查看某一个容器的日志大小。

logs=$(find /var/lib/docker/containers/ -name *-json.log | grep "2de6f164ee11")

3.2 删除日志

如果docker容器正在运行，使用rm -rf的方式删除日志后，磁盘空间并没有释放。原因是在Linux或者Unix系统中，通过rm -rf或者文件管理器删除文件，将会从文件系统的目录结构上解除链接（unlink）。如果文件是被打开的（有一个进程正在使用），那么进程将仍然可以读取该文件，磁盘空间也一直被占用。

正确的方式是直接使用命令改写日志文件。

cat /dev/null > *-json.log

• cat: 是一个命令，用于连接文件并打印它们的内容到标准输出（通常是终端）。


• /dev/null: 是一个特殊的设备文件，向它写入的内容会被丢弃，读取它将会立即返回结束符。


• >: 是重定向操作符，将命令的输出重定向到文件。


• *-json.log: 是通配符，用于匹配当前目录中所有以 -json.log 结尾的文件。

可以使用如下脚本，直接处理所有的日志文件：

#!/bin/sh 

echo "======== start clean docker containers logs ========"  



logs=$(find /var/lib/docker/containers/ -name *-json.log)



for log in $logs

        do

                echo "clean logs : $log"  

                cat /dev/null > $log

        done



echo "======== end clean docker containers logs ========"

注意，虽然使用这种方式可以删除日志，释放磁盘，但是过一段时间后，日志又会涨回来，所以要从根本上解决问题，只需要添加两个参数。没错！就是上面所讲到的max-size和max-file。

3.3 治本操作

在运行docker容器时，添加上max-size和max-file可以解决日志一直增长的问题。

docker run -it --log-opt max-size=10m --log-opt max-file=3 alpine ash

这段启动命令表示总共有三个日志文件，每个文件的最大大小时10m，这样就能将该容器的日志大小控制在最大30m。

4. 总结

在运行容器时，我们就应该优先考虑如何处理日志的问题，后面不必为容器运行后所产生的巨大日志而手足无措。

当然需要删除无用日志可以通过3.1，3.2的操作完成，建议在运行容器的时候加上max-size和max-file参数或者至少加上max-size参数。

❝

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

一、文档站点内网部署

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

以elementPlus为例：

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

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

    server {

        listen       9800;

        server_name  localhost;



        location / {

            root   html/element-plus-gh-pages;

            index  index.html index.htm;

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

        }



        error_page   500 502 503 504  /50x.html;

        location = /50x.html {

            root   html;

        }

    }

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

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

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

二、USB跨屏穿越器数据线

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

购买

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

使用

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

三、手机投屏

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

✨亮点

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


• 表演 （30~60fps）


• 质量 （1920×1080或以上）


• 低延迟 （70~100ms）


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


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


• 不需要 ROOT


• 有线无线都可连接


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


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


• 支持多设备同时投屏


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


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


• 手机电脑共享剪贴板


• 自动检测USB连接的设备


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


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


• 支持设备别名


• 支持中英两种语言


• Tray menu


• 等等等...

安装

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

使用

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

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

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

1、手机复制文本到电脑

2、电脑复制文本到手机

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

快捷键

使用小技巧

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

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

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

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

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

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

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

衍生项目

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

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


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


• guiscrcpy 另一个scrcpy的gui界面。


• scrcpy-docker docker版本的scrcpy。


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

总结

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

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

独立开发者解放思维，开放眼界真的很有必要。就算自己一时没有好的 idea，也可以多观察学习一些（成功的）非主流的独立产品。我之前写文说过独立开发有死亡加速三件套：笔记、记账、todo。但是不得不说我还是保守了，俗话说的好：勇敢的人先享受世界。既然我单个产品都没优势，那我 all in one，把笔记、记账、待办都做到一个 app 里行不行？

直觉上我感觉这样不行吧？但是，啊？

原来真有人吃粉会点全家福啊。于是我想你做是能做但是用户就会喜欢吗？

我直接一个好家伙，两千多评价，4.7分！

嫉妒使我面目全非了。看了一下会员价格，买断28。这个 app 在没有苹果推荐的情况下，做到了两千多评价，我估计用户数大于 5 万。我看了一下上线时间，这个 app 前后开发持续了一年多的时间。如果我按照付费转化10%算，那么这个 app 扣掉 15% 苹果渠道费后收入大概有 12 万（50000 * 10% * 28 * 0.85）。但是这个 app 如果运营得当，后面还是会有新用户进来。因为app是极简（没有设计师的委婉说法），设计成本几乎没有。以当下的数据看，算是回本了。后面再来的增长都是利润了。

定位分析：笔记、待办、记账是很主流的用户需求，但是也有很多入门用户都只有很轻度的需求，垂直的 app 都太专业了，如果我想要这些数据在一起，很轻量，没有广告，设计简洁，又一次买断，那么市场上就没有对应的产品。

完成这个app 有两个难点：首先你要判断市场有这么一块空白，第二个难点，因为任何一个单点都没有优势，怎样触达目标用户。

我看了作者的小红书，他选择了一个很新颖的切入点：学生群体。他有一个宣传口号是“专注学生自律养成的工具 app”。学生群体不会有特别重度的需求，又集中，因为付费转化有限所以垂类专业app都不太考虑学生群体，在这个用户定位这个app又找到了独特的切入点。

这个定位有多重要呢，这个帖子带来的用户下载量就能达到 10000。

总的来说，这个 app 给我带来了很大的震撼。希望也能给大家带来启发。

前言

最近闲来没事，一直在掘金上摸鱼，看了不少高并发相关的文章，突然有感而发，想到了几年前做的一个项目，也多少和高并发有点关系。

这里我一边回忆落地细节一边和大家分享下，兴许能给大家带来点灵感。

正文

需求及背景

先来介绍下需求，首先项目是一个志愿填报系统。

核心功能是两块，一是给考试填报志愿，二是给老师维护考生数据。

本来这个项目不是我们负责，奈何去年公司负责这个项目的组遭到了甲方严重的投诉，说很多考生用起来卡顿，甚至把没填上志愿的责任归到系统上。

甲方明确要求，如果这年再出现这种情况，公司在该省的所有项目将面临被替换的风险。

讨论来讨论去，最后公司将任务落到我们头上时，已经是几个月后的事了，到临危受命阶段，剩下不到半年时间。

虽然直属领导让我们不要有心理负担，做好了表扬，做不好锅也不是我们的，但明显感觉到得到他的压力，毕竟一个不小心就能上新闻。

分析

既然开始做了，再说那些有的没的就没用了，直接开始分析需求。

首先，业务逻辑并不算复杂，难点是在并发和数据准确性上。与客户沟通后，大致了解了并发要求后，于是梳理了下。

方案研讨

接下来我会从当时我们切入问题的点开始，从前期设计到项目落地整个过程的问题及思考，一步步去展示这个项目如何实现的

首先，我们没有去设计表，没有去设计接口，而是先去测试。测试什么？测试我们需要用到或可能用到的中间件是否满足需求

MySQL

首先是MySQL，单节点MySQL测试它的读和取性能，新建一张user表。

向里面并发插入数据和查询数据，得到的TPS大概在5k，QPS大概在1.2W。

查询的时候是带id查询，索引列的查询不及id查询，差距大概在1k。

insert和update存在细微并发差距，但基本可以忽略，影响更新性能目前最大的问题是索引。

如果表中带索引，将降低1k-1.5k的TPS。

目前结论是，mysql不能达到要求，能不能考虑其他架构，比如mysql主从复制，写和读分开。

测试后，还是放弃，主从复制结构会影响更新，大概下降几百，而且单写的TPS也不能达到要求。

至此结论是，mysql直接上的方案肯定是不可行的

Redis

既然MySQL直接查询和写入不满足要求，自然而然想到加入redis缓存。于是开始测试缓存，也从单节点redis开始测试。

get指令QPS达到了惊人的10w，set指令TPS也有8W，意料之中也惊喜了下，仿佛看到了曙光。

但是，redis容易丢失数据，需要考虑高可用方案

实现方案

既然redis满足要求，那么数据全从redis取，持久化仍然交给mysql，写库的时候先发消息，再异步写入数据库。

最后大体就是redis + rocketMQ + mysql的方案。看上去似乎挺简单，当时我们也这样以为 ，但是实际情况却是，我们过于天真了。

这里主要以最重要也是要求最高的保存志愿信息接口开始攻略

故障恢复

第一个想到的是，这些个节点挂了怎么办？

mysql挂了比较简单，他自己的机制就决定了他即使挂掉，重启后仍能恢复数据，这个可以不考虑。

rocketMQ一般情况下挂掉了可能会丢失数据，经过测试发现，在高并发下，确实存在丢消息的现象。

原因是它为了更加高效，默认采用的是异步落盘的模式，这里为了保证消息的绝对不丢失，修改成同步落盘模式。

然后是最关键的redis，不管哪种模式，redis在高并发下挂掉，都会存在丢失数据的风险。

数据丢失对于这个项目格外致命，优先级甚至高于并发的要求。

于是，问题难点来到了如何保证redis数据正确，讨论过后，决定开启redis事务。

保存接口的流程就变成了以下步骤：

1.redis 开启事务，更新redis数据

2.rocketMQ同步落盘

3.redis 提交事务

4.mysql异步入库

我们来看下这个接口可能存在的问题。

第一步，如果redis开始事务或更新redis数据失败，页面报错，对于数据正确性没有影响

第二步，如果rocketMQ落盘报错，那么就会有两种情况。

情况一，落盘失败，消息发送失败，好像没什么影响，直接报错就可。

情况二，如果发送消息成功，但提示发送失败（无论什么原因），这时候将导致mysql和redis数据的最终不一致。

如何处理？怎么知道是redis的有问题还是mysql的有问题？出现这种情况时，如果考生不继续操作，那么这条错误的数据必定无法被更新正确。

考虑到这个问题，我们决定引入一个时间戳字段，同时启动一个定时任务，比较mysql和redis不一致的情况，并自主修复数据。

首先，redis中记录时间戳，同时在消息中也带上这个时间戳并在入库时记录到表中。

然后，定时任务30分钟执行一次，比较redis中的时间戳是否小于mysql，如果小于，便更新redis中数据。如果大于，则不做处理。

同时，这里再做一层优化，凌晨的时候执行一个定时任务，比较redis中时间戳大于mysql中的时间戳，连续两天这条数据都存在且没有更新操作，将提示给我们手动运维。

然后是第三步，消息提交成功但是redis事务提交失败，和第二步处理结果一致，将被第二个定时任务处理。

这样看下来，即使redis崩掉，也不会丢失数据。

第一轮压测

接口实现后，当时怀着期待，信息满满的去做了压测，结果也是当头棒喝。

首先，数据准确性确实没有问题，不管突然kill掉哪个环节，都能保证数据最终一致性。

但是，TPS却只有4k不到的样子，难道是节点少了？

于是多加了几个节点，但是仍然没有什么起色。问题还是想简单了。

重新分析

经过这次压测，之后一个关键的问题被提了出来，影响接口TPS的到底是什么？？？

一番讨论过后，第一个结论是：一个接口的响应时间，取决于它最慢的响应时间累加，我们需要知道，这个接口到底慢在哪一步或哪几步？

于是用arthas看了看到底慢在哪里？

结果却是，最慢的竟然是redis修改数据这一步！这和测试的时候完全不一样。于是针对这一步，我们又继续深入探讨。

结论是：

redis本身是一个很优秀的中间件，并发也确实可以，选型时的测试没有问题。

问题出在IO上，我们是将考生的信息用json字符串存储到redis中的（为什么不保存成其他数据结构，因为我们提前测试过几种可用的数据结构，发现redis保存json字符串这种性能是最高的），

而考生数据虽然单条大小不算大，但是在高并发下的上行带宽却是被打满的。

于是针对这种情况，我们在保存到redis前，用gzip压缩字符串后保存到redis中。

为什么使用gzip压缩方式，因为我们的志愿信息是一个数组，很多重复的数据其实都是字段名称，gzip和其他几个压缩算法比较后，综合考虑到压缩率和性能，在当时选择了这种压缩算法。

针对超过限制的字符串，我们同时会将其拆封成多个（实际没有超过三个的）key存储。

继续压测

又一轮压测下来，效果很不错，TPS从4k来到了8k。不错不错，但是远远不够啊，目标2W，还没到它的一半。

节点不够？加了几个节点，有效果，但不多，最终过不了1W。

继续深入分析，它慢在哪？最后发现卡在了rocketMQ同步落盘上。

同步落盘效率太低？于是压测一波发现，确实如此。

因为同步落盘无论怎么走，都会卡在rocketMQ写磁盘的地方，而且因为前面已经对字符串压缩，也没有带宽问题。

问题到这突然停滞，不知道怎么处理rocketMQ这个点。

同时，另一个同事在测试查询接口时也带来了噩耗，查询接口在1W2左右的地方就上不去了，原因还是卡在带宽上，即使压缩了字符串，带宽仍被打满。

怎么办？考虑许久，最后决定采用较常规的处理方式，那就是数据分区，既然单个rocketMQ服务性能不达标，那么就水平扩展，多增加几个rocketMQ。

不同考生访问的MQ不一样，同时redis也可以数据分区，幸运的是正好redis有哈希槽的架构支持这种方式。

而剩下的问题就是如何解决考生分区的方式，开始考虑的是根据id进行求余的分区，但后来发现这种分区方式数据分布及其不均匀。

后来稍作改变，根据正件号后几位取余分区，数据分布才较为均匀。有了大体解决思路，一顿操作后继续开始压测。

一点小意外

压测之后，结果再次不如人意，TPS和QPS双双不增反降，继续通过arthas排查。

最后发现，redis哈希槽访问时会在主节点先计算key的槽位，而后再将请求转到对应的节点上访问，这个计算过程竟然让性能下降了20%-30%。

于是重新修改代码，在java内存中先计算出哈希槽位，再直接访问对应槽位的redis。如此重新压测，QPS达到了惊人的2W，TPS也有1W2左右。

不错不错，但是也只到了2W，在想上去，又有了瓶颈。

不过这次有了不少经验，马上便发现了问题所在，问题来到了nginx，仍然是一样的问题，带宽！

既然知道原因，解决起来也比较方便，我们将唯一有大带宽的物理机上放上两个节点nginx，通过vip代理出去，访问时会根据考生分区信息访问不同的地址。

压测

已经记不清第几轮压测了，不过这次的结果还算满意，主要查询接口QPS已经来到了惊人的4W，甚至个别接口来到6W甚至更高。

胜利已经在眼前，唯一的问题是，TPS上去不了，最高1W4就跑不动了。

什么原因呢？查了每台redis主要性能指标，发现并没有达到redis的性能瓶颈（上行带宽在65%，cpu使用率也只有50%左右）。

MQ呢？MQ也是一样的情况，那出问题的大概率就是java服务了。分析一波后发现，cpu基本跑到了100%，原来每个节点的最大链接数基本占满，但带宽竟然还有剩余。

静下心来继续深入探讨，连接数为什么会满了？原因是当时使用的SpringBoot的内置容器tomcat，无论如何配置，最大连接数最大同时也就支持1k多点。

那么很简单的公式就能出来，如果一次请求的响应时间在100ms，那么1000 * 1000 / 100 = 10000。

也就是说单节点最大支持的并发也就1W，而现在我们保存的接口响应时间却有300ms，那么最大并发也就是3k多，目前4个分区，看来1W4这个TPS也好像找到了出处了。

接下来就是优化接口响应时间的环节，基本是一步一步走，把能优化的都优化了一遍，最后总算把响应时间控制在了100ms以内。

那么照理来说，现在的TPS应该会来到惊人的4W才对。

再再次压测

怀着忐忑又激动的心情，再一次进入压测环节，于是，TPS竟然来到了惊人的2W5。

当时真心激动了一把，但是冷静之后却也奇怪，按正常逻辑，这里的TPS应该能达到3W6才对。

为了找到哪里还有未发现的坑（怕上线后来惊喜），我们又进一步做了分析，最后在日志上找到了些许端倪。

个别请求在链接redis时报了链接超时，存在0.01%的接口响应时间高于平均值。

于是我们将目光投向了redis连接数上，继续一轮监控，最终在业务实现上找到了答案。

一次保存志愿的接口需要执行5次redis操作，分别是获取锁、获取考生信息、获取志愿信息、修改志愿信息、删除锁，同时还有redis的事务。

而与之相比，查询接口只处理了两次操作，所以对于一次保存志愿的操作来看，单节点的redis最多支持6k多的并发。

为了验证这个观点，我们尝试将redis事务和加锁操作去掉，做对照组压测，发现并发确实如预期的一样有所提升（其实还担心一点，就是抢锁超时）。

准备收工

至此，好像项目的高并发需求都已完成，其他的就是完善完善细节即可。

于是又又又一次迎来了压测，这一次不负众望，重要的两个接口均达到了预期。

这之后便开始真正进入业务实现环节，待整个功能完成，在历时一个半月带两周的加班后，终于迎来了提测。

提测后的问题

功能提测后，第一个问题又又又出现在了redis，当高并发下突然kill掉redis其中一个节点。

因为用的是哈希槽的方式，如果挂掉一个节点，在恢复时重新算槽将非常麻烦且效率很低，如果不恢复，那么将严重影响并发。

于是经过讨论之后，决定将redis也进行手动分区，分区逻辑与MQ的一致。

但是如此做，对管理端就带来了一定影响，因为管理端是列表查询，所以管理端获取数据需要从多个节点的redis中同时获取。

于是管理端单独写了一套获取数据分区的调度逻辑。

第二个问题是管理端接口的性能问题，虽然管理端的要求没考生端高，但扛不住他是分页啊，一次查10个，而且还需要拼接各种数据。

不过有了前面的经验，很快就知道问题出在了哪里，关键还是redis的连接数上，为了降低链接数，这里采用了pipeline拼接多个指令。

上线

一切准备就绪后，就准备开始上线。说一下应用布置情况，8+4+1+2个节点的java服务，其中8个节点考生端，4个管理端，1个定时任务，2个消费者服务。

3个ng，4个考生端，1个管理端。

4个RocketMQ。

4个redis。

2个mysql服务，一主一从，一个定时任务服务。

1个ES服务。

最后顺利上线，虽然发生了个别线上问题，但总体有惊无险，

而真是反馈的并发数也远没有到达我们的系统极限，开始准备的水平扩展方案也没有用上，无数次预演过各个节点的宕机和增加分区，一般在10分钟内恢复系统，不过好在没有排上用场。

最后

整个项目做下来感觉越来越偏离面试中的高并发模式，说实在的也是无赖之举，

偏离的主要原因我认为是项目对数据准确性的要求更高，同时需要完成高并发的要求。

但是经过这个项目的洗礼，在其中也收获颇丰，懂得了去监控服务性能指标，然后也加深了中间件和各种技术的理解。

做完之后虽然累，但也很开心，毕竟在有限的资源下去分析性能瓶颈并完成项目要求后，还是挺有成就感的。

再说点题外话，虽然项目成功挽回了公司在该省的形象，也受到了总公司和领导表扬，但最后也就这样了，

实质性的东西一点没有，这也是我离开这家公司的主要原由。不过事后回想，这段经历确实让人难忘，也给我后来的工作带来了很大的帮助。

从以前的crud，变得能去解决接口性能问题。这之前一遇上，可能两眼茫然或是碰运气，现在慢慢的会根据蛛丝马迹去探究优化方案。

不知道我在这个项目的经历是否能引起大家共鸣？希望这篇文章能对你有所帮助。

前言

想着给自己的博客每年一个置顶帖子，于是便有了此文。

1. 博主的自我介绍

我是一名Java开发工作者，20年大学毕业，专业：计算机科学与技术。

当年高考填报志愿的时候，计算机是一个新兴的蓬勃发展的行业，当时选择这个专业的原因时：一是想着毕业之后进入到这个行业从事相关工作，二是想着这个专业在公务员报考中能报考的岗位也很多。但是大四规划未来人生方向的时候，市场给我们开了一个大大的玩笑，互联网行业乱成了一锅粥，有一句话叫做万物皆可转码，再加之培训班疯狂的向社会输送程序员，市场乱象频频发生，培训班出来的新人能把自己包装成4年5年工作经验，然后各个公司为了能降低用人成本，也为了节省培养新人的时间和开支，也是只招聘工作经验大于3、4年以上的程序员，导致市场对于应届生的接收程度极差，都不愿意招聘应届生，班里的很多学生该培训的培训，该考研考公的备考，该转行的转行....

这个时期能走的路只有三条

• 考研 毕业成为大厂码农 （幻想的）


• 考公


• 和现在就成为码农。

考研呢，也考了，大四下半学期备战了半年，怎么说呢，结果不意外，对自己的认知有偏差，如果能报考一个相对稳妥的双非本科，现在说必定也是一个失业的研究生呢，但是收获最少我把计算机四大件（数据结构、计算机网络、操作系统、计算机组成原理）背了个底朝天，也算是在将近毕业的时候努力的学习了一把大学专业基础的知识。

考公呢，那时候我莫名觉得考公绝对不行，当时运筹帷幄，指点江山，告知自己，现在体制内的各种发生的事情和情况导致未来的公务员绝对不是铁饭碗，加之公务员工资毕竟不像成为程序员肉眼可见的工资那么可观，于是果断的放弃了考公务员，真的，现在有巴掌我第一个扇回去。当时可是20年呀，公务员真的不是很卷，你看看现在，后悔 ....

考研失败之后还是找了个互联网的厂子，现在从事这个行业也有三四年时间了，但是行业的前景却并不像七八年前那样的好。

2、2023年

2023年对我来说绝对是人生最重要的一年之一。

上半年是我老婆人生中最重要的时期之一，她面临着毕业压力（一度让她面临抑郁和崩溃，可能你们会说不就是毕业嘛，哪有那么夸张，我只能说每个人的情况不一样，希望你们一辈子也不要遇见像她导师那样的人...）。

正在外边商场吃饭，然后接到导师电话开始开临时组会。

我们如履薄冰，战战兢兢度过了这段时间。终于，在六月份，她顺利毕业了（万幸）。

（顺利毕业）

（surprise）

七月，她也找到了人生中的第一份工作，我们的生活开始步入正轨。

同样七月终于拥有了人生第一辆车。

（开心）

在家人和我们自己的决定下，我们如期在十月订婚了。这对我们来说是非常重要的一步。

（去银行买的金条，打的金镯子，很划算哈 ~）

（自己买的订婚现场的装饰，pdd 买的，至今为止，我还是觉得我布置的最好看。）

（怎么样呀？jym）

（家人们，教你们一招 五粮液、软华子直接拿下老丈人）

（订婚现场，主持人是我一个妹妹，这张图能看清我桌子上都摆了啥，当天我没拍桌子。）

（订婚书一签，你可不就是我的人了 ~）

（直接拿下）

（小样，还想跑）

（往后余生，我们一起走）

本以为人生会一帆风顺地继续下去，但工作没多久，因为是制造业，厂里的有毒气体使得她呼吸道和身体都在变差，她不得不选择辞职（裸辞）。23年的社会结构变迁使得学历贬值，大学生人数的激增导致工作变得更加稀缺，失业潮开始席卷。

老婆从失业到现在一直住在我租的小房间里，但是我相信人生不可能总是一帆风顺的。

3、技术成长

除了完成基本的工作业务（今年也上线了 3个web网站 和 3个小程序）之外的技术栈扩充：

• 学习了 SpringBoot3.0 和 对应的 Spring 的生态。比如 SpringSecurity 6.0 以上 ...


• 还有 Java 17 的一些新特性和性能。


• 学习了 C# 和 .Net (只能说和 Java 很像，补全版的Java)，正在用C# 做了一个对接 OpenAI的一个类似 ChatGpt 一样的对话类的网站。（还不是很熟，但是能写了，面向百度编程）


• 学习了 领域驱动 DDD ，真的感觉要长脑子了，很多系统性的东西在慢慢融合。


• 接触了 Vue3 和 TypeScript （嗯，万物都在往面向对象发展 ~）


• 可以从 需求制定，域名、服务器、云服务 产品的选型，技术选型，前后端开发，部署上线，性能优化，中间件搭建，后期的运维测试。都能自己一个人搞下来了。（还是勉勉强强，但是按照我们现在这种模式的话，稍微简单一点的服务还是没啥问题的、单体服务就更没问题了。没错，我就是小公司全能手）


• 现在 Python 和 Shell 脚本 玩得 6 的一 。（脚本真方便，而且这种解释器语言真好用~）

4、个人成长

这一年中，有一丝丝的人生感悟，分享给大家。

在工作上，大家都知道，写代码到一定程度会有质的飞跃。今年我在工作方面有了一些感悟，但随着对知识的深入，我也意识到自己所不知道的更多。我从最基础的 Java、数据库和 Web 开发开始，逐渐深入研究技术，包括 Java、系统设计和架构、各种数据库进阶以及项目管理，然后扩展到安全与性能优化、沟通能力、业务和行业理解，以及技术趋势和新技术。然而，最近我意识到，一切都归结于一个道理：先做人，再做事。懂得做人，任何问题都能迎刃而解。我对此有些许领悟。

在工作中，技术的学习和提升固然至关重要，但随着不断的实践，我逐渐意识到成功并不仅取决于技术能力，更关键的是人格魅力和人际交往能力。我开始认识到要从意识开始转变。

从最开始的技术基础学习，到技术的深入研究，再到全面提升，这是职业发展的必经之路。但是当在职场中积累了一定经验后，我渐渐明白技术只是成功的一部分。在实际工作中，需要与人打交道、管理团队、协调资源，这些都需要更多的人际关系、沟通技巧和领导力。虽然我现在还在追求进步，但这是必经之路。

要学会做人，在职场上就意味着有坚定的原则和良好的职业道德。这意味着以诚实、正直、宽容的态度对待他人，学会尊重和理解他人的不同，善于倾听，愿意分享和帮助他人。

此外，学会做人也包括与同事的良好合作、与上级的有效沟通、与下属的关心和激励。建立良好的人际关系，培养团队合作精神。

我曾听过这样一段话，我们这一代，因为互联网的高速发展，能轻易接触到信息，就以为自己掌握了很多，但这个世界上真正有价值的东西都需付出等价的代价。先学会做人，再学做事。

5、总结与展望

新的一年：

• 常回家看看，暂时定的两个月最少回去一次吧。


• 好好给老婆准备明年春招。


• 好好写一些博客，将自己的技术分享出来。将自己的博客好好运营一下。


• 好好吃饭、锻炼，我实在是太瘦了，身体是革命的本钱。


• 交易，看看大A水有多深。兄弟们 2700 抄底了~


• 攒点钱，再去一次 汉中-留坝县自驾游。


• 抽时间把婚纱照拍了~

什么都会过去的，抓住现在，不是吗？

（我的头像，在汉中狮子沟牧场拍的）

（开心最重要，不是吗？）

（去年全球总决赛[ wbg vs t1]的时候线下场馆拍的，笑死 ~）

（前几天下雪 恐龙 vs 鸭子）

就这些，希望明年年度总结的时候可以将这些都完成 ~

引用《人世间》种的一句话：

从你出生的那一刻起, 端什么碗,吃什么饭, 经历什么事,什么时候和谁结婚, 都是定数。 别太难为自己,顺其自然就好。 人生的剧本, 你早在天堂就看过了, 你之所以选择这个剧本是因为, 这一生中有你认为值得的地方。

jym 加油 ！

背景

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

示例代码

<!DOCTYPE html>

<html lang="en">

  <head>

    <meta charset="UTF-8" />

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

    <style>

      * {

        margin: 0;

        padding: 0;

        box-sizing: border-box;

      }



      body {

        font-family: Arial, sans-serif;

      }



      .flex {

        display: flex;

      }

      .item {

        margin-right: 10px;

        padding: 10px;

        font-size: 13px;

        line-height: 1;

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

      }

      .active {

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

        font-size: 14px;

        border: 0.5px solid ;

      }

    </style>

  </head>

  <body>

    <div class="flex">

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

        active

      </div> -->

      <div class="item">

        item1

      </div>

      <div class="item">

        item2

      </div>

      <div class="item">

        item3

      </div>

    </div>

  </body>

</html>

在没active的情况下

他们的内容都是占13px

在有active的情况下

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

再来看看item

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

为啥border是1px呢

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

浏览器渲染机制

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

设备像素比

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


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

解决办法

方法一：使用伪类和定位

.active {

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

  font-size: 14px;

  position: relative;

}

.active::after {

  content: "";

  pointer-events: none;

  display: block;

  position: absolute;

  left: 0;

  top: 0;

  transform-origin: 0 0;

  border: 1px #ff892e solid;

  box-sizing: border-box;

  width: 100%;

  height: 100%;

}

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

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

.active2 {

  margin-left: 10px;

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

  font-size: 14px;

  position: relative;

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

}

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

<div class="active">

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

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

  </svg>

  active

</div>

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

<div class="active">

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

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

    </svg>

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

</div>

.active {

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

  font-size: 14px;

  position: relative;

  display: inline-block; 

}

.active svg {

  position: absolute;

  top: 0;

  left: 0;

  width: 100%;

  height: 100%;

  pointer-events: none; 

  box-sizing: border-box;

}

.active .content {

  position: relative;

  z-index: 1; 

}

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

<div class="border-container">

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

</div>



.border-container {

  display: inline-block;

  padding: 0.5px; 

  background-color: #ff892e; 

}



.active {

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

  font-size: 14px;

  background-color: white; 

}

最后

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

1、背景

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

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

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

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

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

我：那中，管管管。

2、调研

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

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


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


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

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

接下来有几种选择：

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


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

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

3、实现

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

先初始化一个vue工程

 npm create vue@latest

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

安装model-viewer依赖：

npm i three // 前置依赖

npm i @google/model-viewer

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

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

​

import { defineConfig } from 'vite'

import vue from '@vitejs/plugin-vue'

​

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

export default defineConfig({

  plugins: [

    vue({

      template: {

        // 添加以下内容

        compilerOptions: {

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

        }

      }

    })

  ],

  resolve: {

    alias: {

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

    }

  },

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

})

​

新建 src/components/LolProgress.vue

<template>

  <div class="progress-container">

    <model-viewer

      :src="hero.src"

      disable-zoom

      shadow-intensity="1"

      :camera-orbit="hero.cameraOrbit"

      class="model-viewer"

      :style="heroPosition"

      :animation-name="animationName"

      :camera-target="hero.cameraTarget"

      autoplay

      ref="modelViewer"

    ></model-viewer>

    <div

      class="progress-bar"

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

    >

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

    </div>

  </div>

</template>

​

<script setup lang="ts">

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

/** 类型 */

interface Hero {

  src: string

  cameraOrbit: string

  progressAnimation: string

  finishAnimation: string

  finishAnimationIn: string

  cameraTarget: string

  finishDelay: number

}

type HeroName = 'yasuo' | 'yi'

​

type Heros = {

  [key in HeroName]: Hero

}

const props = defineProps({

  hero: {

    type: String as PropType<HeroName>,

    default: 'yasuo'

  },

  percentage: {

    type: Number,

    default: 100

  },

  strokeWidth: {

    type: Number,

    default: 10

  },

  heroSize: {

    type: Number,

    default: 150

  }

})

​

const modelViewer = ref(null)

​

const heros: Heros = {

  yasuo: {

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

    cameraOrbit: '-90deg 90deg',

    progressAnimation: 'Run2',

    finishAnimationIn: 'yasuo_skin02_dance_in',

    finishAnimation: 'yasuo_skin02_dance_loop',

    cameraTarget: 'auto auto 0m',

    finishDelay: 2000

  },

  yi: {

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

    cameraOrbit: '-90deg 90deg',

    progressAnimation: 'Run',

    finishAnimationIn: 'Dance',

    finishAnimation: 'Dance',

    cameraTarget: 'auto auto 0m',

    finishDelay: 500

  }

}

​

const heroPosition = computed(() => {

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

  return {

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

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

    height: props.heroSize + 'px',

    width: props.heroSize + 'px'

  }

})

​

const currentPercentStyle = computed(() => {

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

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

})

​

const hero = computed(() => {

  return heros[props.hero]

})

​

const animationName = ref('')

​

watch(

  () => props.percentage,

  (percentage) => {

    if (percentage < 100) {

      animationName.value = hero.value.progressAnimation

    } else if (percentage === 100) {

      animationName.value = hero.value.finishAnimationIn

      setTimeout(() => {

        animationName.value = hero.value.finishAnimation

      }, hero.value.finishDelay)

    }

  }

)

onMounted(() => {

  setTimeout(() => {

    console.log(modelViewer.value.availableAnimations)

  }, 2000)

})

</script>

<style scoped>

.progress-container {

  position: relative;

  width: 100%;

}

.model-viewer {

  position: relative;

  background: transparent;

}

.progress-bar {

  border: 1px solid #fff;

  background-color: #666;

  width: 100%;

}

.progress-percent {

  background-color: aqua;

  height: 100%;

  transition: width 100ms ease;

}

</style>

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

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


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


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


• 额外的细节处理。
  
  

  最后修改 app.vue:

  
  

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

  
  

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

老板：换个女枪的看看。

我：好嘞。

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

4、总结

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

老板招个UI妹子吧。

在线体验：github-pages

前言

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

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

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

分析瀑布流

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

这里有两个难点：

• 卡片高度如何确定？


• 堆叠布局如何实现？

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

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

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

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

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

从问题到代码

第一个问题——图片高度

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

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

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

const realImageHeight = imageWidth / imageHeight * cardContentWidth;  

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

第二个问题——文字高度

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

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

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


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

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

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

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

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

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

function createDiv(style: string): HTMLDivElement {  

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

    div.style.cssText = style;  

    document.body.appendChild(div);  

    return div;  

}  

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

/**  

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

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

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

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

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

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

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

*/  

export function calculateTextLines(  

    texts: string[],  

    fontSize: number,  

    lineHeight: number,  

    containerWidth: number,  

    maxLine?: number  

): number[] {  

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

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

    const results: number[] = [];  

    texts.forEach((text) => {  

        div.textContent = text;  

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

        const divHeight = div.offsetHeight;  

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

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

    });  

  

    // 清理 div  

    removeElement(div);  



    return results;  

}  

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

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

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

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

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

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

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

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

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

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

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

// 返回的盒子信息  

export interface Box {  

    x: number;  

    y: number;  

    height: number;  

}  

// 盒子堆叠的方法类  

export class BoxPacker {  

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

    private boxes: Box[] = [];  

    // 大盒子宽度  

    private width: number;  

    // 小盒子宽度  

    private stackWidth: number;  

    // 小盒子间隔  

    private gap: number;  



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

    this.width = width;  

    this.stackWidth = stackWidth;  

    this.gap = gap;  

    this.boxes = [];  

}  

// 添加单个盒子  

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

    return this.addBoxes([height]);  

}  

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

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

    isReset && (this.boxes = [])  

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



    for (const height of heights) {  

        const position = this.findBestPosition();  

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

        this.boxes.push(newBox);  

    }  

    return this.boxes;  

}  

// 查找定位函数  

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

    let bestX = 0;  

    let bestY = Number.MAX_VALUE;  



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

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

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

            bestX = x;  

            bestY = currentY;  

        }  

    }  



    return { x: bestX, y: bestY };  

}  

  

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

    return this.boxes  

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

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

}  

}