今日三荐：malloc 的桶、路由优先级与 HTML 片段 (2026)

程序向系统要一块内存的时候，真正决定这一百字节放在哪儿的是分配器。

请求进到服务端之前，决定它交给哪个后端的是代理。

界面点一下之后，决定哪一块 HTML 被换掉的是前端库里的一个默认值。

三件事分别发生在堆、网络入口和浏览器里。每一处都有一个替你做的决定，也都留着一个口子，能把它打印出来。

三个项目都在过去四天里发了新版本。

下面的命令和数字都跑在同一台机器上：Linux x86_64、8 核、gcc 14.2、Node 22.13、Chromium 156.0.8078.73。三个项目用的都是官方发布物或官方包管理器里的包。

1. mimalloc：一次 malloc 先被换成桶号

仓库：microsoft/mimalloc · C · MIT · 13,526 星

为什么今天看

3.6.1 在北京时间 10 月 31 日 05:50 发布（UTC 2026-10-30T21:50Z）。上一版 3.6.0 停在 10 月 24 日 07:38，中间隔了七天。1 2

发布页的正文只有一句「Binary and source releases」，改了什么都得去看提交。1

3.6.0 到 3.6.1 之间是 95 个提交、88 个文件。3

主线是让分配器在 CHERI 平台上跑对。CHERI 的指针带 provenance、能加边界，自由链表里存下一个指针的位置要保留这些属性，页元数据的指针也要做边界检查。3

同一批提交里还有两处普通机器能用上的：fork 之后的子进程清理改走通用路径，page_reclaim_on_free 改回默认 0。3

这个项目的自我描述一直很具体：大约 12,000 行 C，可以直接顶替 malloc。4

最值得拆的机制

100 字节先被换成一个桶号。 分配器不按你要的字节数干活，按桶的尺寸干活。
一个 page 只放一种尺寸的块。 64 位系统上通常 64 KiB。4
每个 page 有自己的自由链表。 同一段时间申请的东西因此挨在一起。4
每个 page 上有两条链。 一条给申请的线程自己 free，一条给别的线程 free。4
跨线程 free 是一条 CAS。 释放的一方不用和申请的线程商量。4
page 空了就标记给系统回收。 长跑的服务内存不会一路往上涨。4

最后两条是整套设计的支点，也是 mimalloc 那篇技术报告的题目：free list sharding。5

glibc 的 malloc 走另一条路。每个线程有自己的 arena，A 线程申请的内存被 B 线程释放，这块内存回不到 A 手里。

本机实测：四个场景，两个方向

先看桶。用 mi_usable_size 把请求的字节数换成实际拿到的字节数：

ask      1 -> usable      8
ask      9 -> usable     16
ask     17 -> usable     32
ask     33 -> usable     48
ask     56 -> usable     64
ask     72 -> usable     80
ask    100 -> usable    112
ask    200 -> usable    224
ask    300 -> usable    320
ask  20000 -> usable  20480
ask 100000 -> usable 114688

1 到 300 字节之间一共只有 14 个落点：8、16、32、48、64、80、96、112、128、160、192、224、256、320。请求 100 字节拿到 112 字节，浪费 12 字节。

四个基准，同一份 C 程序，只换 LD_PRELOAD：

                                  glibc        mimalloc
反复申请释放 500 万次(8~512B)      39.2 ms       50.5 ms
同时持有 200 万块(32~256B)        166.6 ms       36.6 ms
8 线程 × 40 万块、交叉释放        569.6 ms       41.4 ms
8 线程 × 500 万次反复申请释放      132.9 ms      198.5 ms

两个分配器各赢两项。glibc 快的那两项是同一种负载：申请完马上释放、尺寸反反复复。它的 tcache 就是为这种模式写的。

mimalloc 快的那两项也是同一种负载：大量块同时活着，或者块被别的线程释放。

第三行最能说明问题。8 个线程各申请 40 万块，然后每个线程释放下一个线程的内存：glibc 569.6 毫秒，mimalloc 41.4 毫秒，差十三倍。

内存上两个分配器差不多。同时持有 200 万块时峰值都在 328 MB 上下；全部释放之后，glibc 的 RSS 停在 301,980 KB，mimalloc 是 281,224 KB。

想看内部状态，加一个环境变量：

MIMALLOC_SHOW_STATS=1 LD_PRELOAD=$PWD/libmimalloc.so ./bench 0

进程退出时会打印每个桶的峰值和累计占用：

  bin S   11  :    15.0 MiB    32.1 MiB     0      112      300.6 K
  bin S   12  :    17.2 MiB    36.6 MiB     0      128      300.6 K
  bin S   16  :    69.3 MiB   146.7 MiB     0      256      601.2 K
  allocated   :   312.4 MiB     1.6 GiB     4.0 KiB
  pages       :     4.8 K       4.8 K       1
  abandoned   :     4.7 K       4.7 K       0

复现难度：低

一个 gcc 就够，不用装 cmake。本机编译 3.9 秒，产物 316,728 字节。

最小上手路径

curl -L -o mimalloc.tar.gz https://github.com/microsoft/mimalloc/archive/v3.6.1.tar.gz
tar xzf mimalloc.tar.gz && cd mimalloc-3.6.1
gcc -O3 -fPIC -shared -DNDEBUG -DMI_MALLOC_OVERRIDE=1 -Iinclude \
    -o libmimalloc.so src/static.c -pthread
LD_PRELOAD=$PWD/libmimalloc.so ls -l

MI_MALLOC_OVERRIDE=1 这个宏必须给。不给也能编出一个 .so，只是里面没有 malloc 这个符号，LD_PRELOAD 什么都换不掉。

我第一遍就是这么错的：两次跑出来都是 39.0 毫秒，一模一样，还以为是 mimalloc 没优势。4

CMake 里对应的开关叫 MI_OVERRIDE=ON。4

今晚练习

把请求换成桶。 用 mi_usable_size 从 1 扫到 300，看哪几个数是分界点。扫一遍那 14 个数就忘不掉了。
挂到你自己的程序上。 找一个会申请很多小对象的程序，两种 malloc 各跑一次，只看 RSS 和耗时。
造出跨线程释放。 开两个线程，一个申请、一个释放，这一项本机差了十三倍。
读一遍统计。 用 MIMALLOC_SHOW_STATS=1 跑一次，盯住 abandoned 和 reclaimf 两行。
打开安全模式。 加 -DMI_SECURE=ON 再编一个版本，跑同一个基准，看慢多少。官方自述通常在 10% 量级。4

版本动作与限制

3.6.1，MIT，13,526 星。6
v3、v2、v1 三条线并行维护，v2 最新是 2.5.2。4
换之前先量自己的负载。本机这两项里 glibc 更快，直接换上 mimalloc 会变慢。
上面的数字来自一台 8 核 x86_64，块大小是我自己编的区间。换个分布，结论可能翻过来。
分配器能改的只有它这一层。程序慢的多数原因在算法和 IO。

2. traefik：一个请求先被一条字符串规则决定去向

仓库：traefik/traefik · Go · MIT · 65,444 星

为什么今天看

3.7.17 在北京时间 11 月 2 日 17:15 发布（UTC 2026-11-02T09:15Z），修了一条 high 级安全公告。7 8

公告讲的是后端连接泄漏。从 3.7.14 起，只要请求头里带 Authorization: NTLM 或 Negotiate，凭据真假不论，Traefik 就给这条客户端连接单独开一份到后端的 transport。8

客户端断开之后，这份 transport、它占着的空闲连接和 goroutine 都不回收。FastProxy 这条转发路径上也有同样的写法。8

一个不做认证的客户端可以反复开短连接，把这个进程的内存、文件描述符和后端连接吃干净。后端有没有配 NTLM 都不影响。8

受影响的版本是 3.7.14 到 3.7.16，3.7.17 修。3.6 及更早的 3.x 只在后端回过 WWW-Authenticate 之后才分配 transport，所以漏不到那几条线。v2 线同日发了 2.11.61。8

同一版还修了包装后的 ResponseWriter 里 flush、hijack 和 deadline 的断链，把 golang.org/x/net 升到 v0.62.0，给入口点加了限制请求头条数的选项。7

10 月 30 日还发了 3.8.0-rc.1，带按路由器配置的响应超时、tap 中间件和 Gateway API 的若干能力。9

最值得拆的机制

一个请求先进入口点，再进路由器。 路由器是三样东西：一条规则、一串中间件、一个服务。10
规则是匹配器的布尔表达式。 能用 &&、||、! 和括号，匹配器有 Host、PathPrefix、Path、Header、Method、Query、ClientIP。10
中间件按顺序包住请求。 stripPrefix 改的是交给后端的路径本身。10
默认优先级等于规则字符串的长度。 越长越优先，这是为避免路径重叠定的规则。10
转发层复用后端连接。 FastProxy 让普通请求省掉一次 TCP 握手。7

最后一条和那条安全公告是同一件事的两面。NTLM 认证绑在一条连接上，一条连接只能服务一个身份。

复用连接碰上每连接认证就会串身份，于是 Traefik 给带 NTLM 头的连接单开一份 transport。修复的方向是让这份 transport 在该断开的时候断开。

本机实测：三个路由器，两次改配置

两个 Node 后端，一个监听 19101，一个监听 19102，各自返回自己是谁、收到的路径和几个请求头。三条路由写在一个 YAML 文件里：

http:
  routers:
    root:
      rule: "Host(`who.test`)"
      service: a
    api:
      rule: "Host(`who.test`) && PathPrefix(`/api`)"
      service: a
    api-v2:
      rule: "Host(`who.test`) && PathPrefix(`/api/v2`)"
      service: b
      middlewares: ["strip"]
  middlewares:
    strip:
      stripPrefix:
        prefixes: ["/api/v2"]

GET /hello           -> {"backend":19101,"url":"/hello"}
GET /api/v1/x        -> {"backend":19101,"url":"/api/v1/x"}
GET /api/v2/users    -> {"backend":19102,"url":"/users"}
GET /hello 不带 Host -> 404 page not found

第三个请求走了 api-v2，strip 把 /api/v2 摘掉，后端收到 /users。第四个请求没匹配上任何路由，404 是 Traefik 自己回的。

三条路由的优先级可以从 API 里读出来：

api-v2@file  priority=41  rule_len=41  Host(`who.test`) && PathPrefix(`/api/v2`) -> b
api@file     priority=38  rule_len=38  Host(`who.test`) && PathPrefix(`/api`)    -> a
root@file    priority=16  rule_len=16  Host(`who.test`)                          -> a

41、38、16 就是三条规则字符串本身的长度。Traefik 自己那两条内部路由走的是另一个极端，优先级是 9223372036854775806。

现在给 api 加一行 priority: 100，再请求一次 /api/v2/users：

{"backend":19101,"method":"GET","url":"/api/v2/users"}

后端换了，路径原样传了过去。一行优先级同时改了这两件事，因为 strip 挂在 api-v2 上，而 api-v2 已经轮不到了。

加一个 headers 中间件，后端能读到它加的头：

{"backend":19102,"url":"/users","x_forwarded_host":"who.test","x_from_proxy":"traefik-3.7.17"}

最后量一次代理自己花了多少。跑 300 次请求，日志里每个请求都记着走了哪条路由、哪个服务、以及两段耗时：

RouterName=api-v2@file  ServiceName=b@file  ServiceAddr=127.0.0.1:19102
Duration       p50 = 159.3 µs   p90 = 206.9 µs
OriginDuration p50 = 139.1 µs   p90 = 182.1 µs
Overhead       p50 =  19.7 µs   p90 =  25.2 µs

Overhead 是 Traefik 自己那一段，中位 19.7 微秒。这三个字段在日志里是纳秒：换一个故意睡 50 毫秒的后端，Duration 报的是 54,539,858。

复现难度：低

一个静态二进制，加两个几十行的 Node 服务，就够把上面每一次走向都看一遍。

最小上手路径

curl -L -o traefik.tgz https://github.com/traefik/traefik/releases/download/v3.7.17/traefik_v3.7.17_linux_amd64.tar.gz
tar xzf traefik.tgz

traefik.yml 只写入口点、文件 provider 和打开 API：

entryPoints:
  web:
    address: ":18080"
  traefik:
    address: ":18081"
providers:
  file:
    filename: ./dynamic.yml
api:
  insecure: true
accessLog:
  format: json

dynamic.yml 用上面那一段，然后：

node backend.js 19101 &
node backend.js 19102 &
./traefik --configfile traefik.yml &
curl -s -H "Host: who.test" http://127.0.0.1:18080/api/v2/users
curl -s http://127.0.0.1:18081/api/rawdata | python3 -m json.tool | head -40

api.insecure 把 API 挂在默认叫 traefik 的入口点上。入口点不改名就得改它的端口，不然 8080 被占用的时候 API 起不来。

今晚练习

删掉那条优先级。 把 priority: 100 注释掉，再看 /api/v2/users 落在哪个后端，规则长度那件事立刻明白。
改一次规则长度。 不动 priority，只在规则末尾多写一个斜杠，长度变一位，看命中结果会不会翻。
拆一次中间件。 把 strip 从 api-v2 挪到 api 上，再请求 /api/v1/x，看后端收到的路径。
读一条 access log。 找出 RouterName、ServiceName、Overhead 三个字段。线上排查「这个请求到底走了哪条路由」靠的就是它们。
复现 404。 把 Host 换成一个没写进规则的名字。这条路径上中间件一条都不会执行。

版本动作与限制

3.7.17，MIT，65,444 星。v2 线同日发 2.11.61。8 11
跑 3.7.14 到 3.7.16 的实例今天就该升。
默认优先级等于规则长度，这条和人的直觉常常对不上。一条写得又长又泛的规则，会压住一条短而具体的规则。要控制就显式写 priority。10
这里的 Overhead 是同一台机器上量的，中间没有真实网络。真实环境里这个数字会被 TLS、DNS 和后端延迟盖住。
二进制 182,120,608 字节，dashboard、各 provider 和全部中间件都编在里面。
我用的是文件 provider。Docker、Kubernetes 那几种 provider 走同一套路由模型，只是配置从别处读进来。

3. htmx：一段响应决定换掉哪块 DOM

仓库：bigskysoftware/htmx · JavaScript · Zero-Clause BSD · 49,595 星

为什么今天看

4.0.1 在北京时间 11 月 2 日 07:06 发布（UTC 2026-11-01T23:06Z），同一天 07:12 还发了 2.0.11。12 13

4.0.0 是 8 月 28 日发的。4.0.1 是这条线上最新的一次修补，正文列了二十来处改动。12 14

其中一条正好落在这台机器上：Chrome 150 到 156 会丢掉 HTML 注释，这一版绕过它（#4150）。本机用的 Chromium 是 156.0.8078.73，正在这个区间里。12

2.0.11 同一天把 4.0 的 <hx-partial> 回移到了 2.x 线。两条线在同一天动同一处，说明这是这一轮的重点。13

最值得拆的机制

服务器返回 HTML 片段。 一段响应就是一块界面，这是整个库的地基。15
请求写在 HTML 属性上。 hx-get、hx-post、hx-put、hx-patch、hx-delete 各对应一个方法。15
默认触发器按元素类型定。 input、textarea、select 用 change，form 用 submit，其余用 click。15
hx-swap 决定替换哪块。 innerHTML 换内部、outerHTML 换自己、beforeend 追加到最后一个子节点后面、textContent 只换文本。15
一个响应可以改好几处。 <hx-partial hx-target="#count"> 自带目标，跟主替换各走各的。15
4.0 的继承变成了显式。 父元素的 hx-target 现在只作用于自己，想让子元素沿上这条，得写 :inherited。15
4.0 用 fetch 发请求。 2.x 用的是 XMLHttpRequest。15

本机实测：在真浏览器里点两次

页面由本机一个 Node 服务提供，htmx 直接引 dist/htmx.js，浏览器是 Chromium 156 headless，用 Puppeteer 驱动。每次点击之前，在 document.body 上挂一个 MutationObserver。

点之前                    : 3 个 li，计数 3
点「加一件」(beforeend)    : 4 个 li，计数 4，2 条变更记录，新增 2 个节点，删 1 个，响应 85 字节
点「整块换掉」(innerHTML)  : 3 个 li 全换成新的，1 条变更记录，新增 3 个，删 4 个，响应 39 字节

两个按钮打的是同一个后端，服务器返回的东西也基本一样：一个 <li>，加一个 <hx-partial hx-target="#count">4</hx-partial>。

差别全在 hx-swap。beforeend 往列表尾巴塞一个新节点，那块 partial 顺手把计数改了，一共动了两处；innerHTML 把整块列表重画，三个 li 全删了重建。

85 字节的响应改了两处界面。这个库的交易就这一句：渲染的决定搬到服务器，客户端只剩替换。

复现难度：低

一个 npm 包，一个浏览器，没有构建步骤，业务代码里没有一行 JavaScript。

最小上手路径

mkdir htmxtry && cd htmxtry && npm init -y && npm i htmx.org@4.0.1

服务端只负责返回片段，这里用 Node 自带的 http：

const http = require('http');
http.createServer((req, res) => {
  if (req.url === '/') {
    res.setHeader('content-type', 'text/html');
    return res.end(`<!doctype html><meta charset="utf-8">
      <script src="/htmx.js"></script>
      <p>共 <span id="count">2</span> 件</p>
      <ul id="list"><li>键盘</li><li>显示器</li></ul>
      <button hx-post="/items" hx-target="#list" hx-swap="beforeend">加一件</button>`);
  }
  if (req.url === '/htmx.js') {
    res.setHeader('content-type', 'text/javascript');
    return res.end(require('fs').readFileSync('node_modules/htmx.org/dist/htmx.js'));
  }
  if (req.url === '/items') {
    res.setHeader('content-type', 'text/html');
    return res.end('<li>新物品</li><hx-partial hx-target="#count" hx-swap="innerHTML">3</hx-partial>');
  }
}).listen(19201, '127.0.0.1');

浏览器打开 http://127.0.0.1:19201/，点一下按钮，列表和计数同时变。

今晚练习

换一次 swap。 把 beforeend 改成 innerHTML，再数一次变更记录。响应一样，改动数量不一样。
一个响应改两处。 上面那份已经带了 <hx-partial>，把计数从 2 改成 3 再看。
把继承关掉再打开。 把 hx-target 挪到父元素上，子按钮会失效；在父元素上补 :inherited 才恢复。这一条会让 2.x 的页面悄悄坏掉。
轮询一次。 加 hx-trigger="every 2s"，看 Network 面板每两秒一个请求，响应还是几十字节。
跑官方升级检查。 包里带着一个 upgrade-check，三条旧属性报出来的原文是：

[renamed-attr] hx-disable → rename to hx-ignore (hx-disable now means 'disable during request')
[inheritance]  hx-target needs :inherited suffix (descendant on line 2 has hx-get)
[renamed-attr] hx-disabled-elt → rename to hx-disable

两条改名方向相反。顺序写错，就把「请求期间禁用按钮」悄悄变成「不处理这个元素」。16

版本动作与限制

4.0.1，Zero-Clause BSD，49,595 星。17
4.0 是一次重写。hx-disable 现在的意思是「请求期间禁用」，原来的「不处理」改叫 hx-ignore；hx-disabled-elt 改叫 hx-disable。升级前先跑 upgrade-check。16
服务器得返回 HTML 片段，这条约束会一路渗进后端。同一个接口还要给 App 或第三方用，就得另外给一份 JSON。
交互逻辑变成字符串属性，类型检查帮不上忙，写完只能靠点。
按钮和后端在同一台机器上，上面的字节数是准的，毫秒数不代表真实网络。
我只用了核心库。SSE、WebSocket、preload 这些在 dist/ext/ 里，按需引。

怎么选今晚的第一条路径

想看见的决定点	仓库与本期信号	最小条件	第一条可观察路径	主要限制
几百字节落进哪个桶	mimalloc · `v3.6.1` 北京时间 10 月 31 日 05:50	gcc，一次编译 3.9 秒	用 `MI_MALLOC_OVERRIDE` 编出 .so，`LD_PRELOAD` 换掉 malloc	单线程短生命周期场景 glibc 更快
一个请求交给哪个后端	traefik · `v3.7.17` 北京时间 11 月 2 日 17:15	一个静态二进制，两个本地后端	三条路由，`curl -H "Host: who.test"` 打过去	默认优先级等于规则长度
一段响应换掉哪块 DOM	htmx · `v4.0.1` 北京时间 11 月 2 日 07:06	一个 npm 包，一个浏览器	同一个响应，`beforeend` 与 `innerHTML` 各点一次	服务器必须返回片段

三处默认值都很朴素：100 字节进 112 的桶，41 个字符的规则赢过 38 个字符的规则，hx-swap 不写就按 innerHTML 处理。

三处默认值也都能被覆盖：改 hx-swap、写 priority、换分配器。改之前得先看见，而看见的成本都不高：一张尺寸表、一个 API 字段、一个 MutationObserver。

三个项目加起来一个多小时能全部跑通。跑完手里会留下三样能直接搬进自己项目的东西：一条换 malloc 的编译命令、一份规则加优先级的写法、一个只返回 HTML 片段的接口形状。

References

1
mimalloc v3.6.1 发布说明
github.com
2
mimalloc v3.6.0 发布说明
github.com
3
mimalloc 3.6.0 到 3.6.1 的提交对比
github.com
4
mimalloc 仓库说明
github.com
5
mimalloc 技术报告：Free List Sharding in Action
microsoft.com
6
mimalloc 仓库
github.com
7
traefik v3.7.17 发布说明
github.com
8
安全公告 GHSA-xv5x-242w-7hf7
github.com
9
traefik v3.8.0-rc.1 发布说明
github.com
10
Traefik 规则与优先级文档
doc.traefik.io
11
traefik 仓库
github.com
12
htmx v4.0.1 发布说明
github.com
13
htmx v2.0.11 发布说明
github.com
14
htmx v4.0.0 发布说明
github.com
15
htmx 4 用法说明
github.com
16
htmx 4 升级指南
github.com
17
htmx 仓库
github.com

程序向系统要一块内存的时候，真正决定这一百字节放在哪儿的是分配器。

请求进到服务端之前，决定它交给哪个后端的是代理。

界面点一下之后，决定哪一块 HTML 被换掉的是前端库里的一个默认值。

三件事分别发生在堆、网络入口和浏览器里。每一处都有一个替你做的决定，也都留着一个口子，能把它打印出来。

三个项目都在过去四天里发了新版本。

下面的命令和数字都跑在同一台机器上：Linux x86_64、8 核、gcc 14.2、Node 22.13、Chromium 156.0.8078.73。三个项目用的都是官方发布物或官方包管理器里的包。

1. mimalloc：一次 malloc 先被换成桶号

仓库：microsoft/mimalloc · C · MIT · 13,526 星

为什么今天看

3.6.1 在北京时间 10 月 31 日 05:50 发布（UTC 2026-10-30T21:50Z）。上一版 3.6.0 停在 10 月 24 日 07:38，中间隔了七天。1 2

发布页的正文只有一句「Binary and source releases」，改了什么都得去看提交。1

3.6.0 到 3.6.1 之间是 95 个提交、88 个文件。3

同一批提交里还有两处普通机器能用上的：fork 之后的子进程清理改走通用路径，page_reclaim_on_free 改回默认 0。3

这个项目的自我描述一直很具体：大约 12,000 行 C，可以直接顶替 malloc。4

最值得拆的机制

100 字节先被换成一个桶号。 分配器不按你要的字节数干活，按桶的尺寸干活。
一个 page 只放一种尺寸的块。 64 位系统上通常 64 KiB。4
每个 page 有自己的自由链表。 同一段时间申请的东西因此挨在一起。4
每个 page 上有两条链。 一条给申请的线程自己 free，一条给别的线程 free。4
跨线程 free 是一条 CAS。 释放的一方不用和申请的线程商量。4
page 空了就标记给系统回收。 长跑的服务内存不会一路往上涨。4

最后两条是整套设计的支点，也是 mimalloc 那篇技术报告的题目：free list sharding。5

glibc 的 malloc 走另一条路。每个线程有自己的 arena，A 线程申请的内存被 B 线程释放，这块内存回不到 A 手里。

本机实测：四个场景，两个方向

先看桶。用 mi_usable_size 把请求的字节数换成实际拿到的字节数：

ask      1 -> usable      8
ask      9 -> usable     16
ask     17 -> usable     32
ask     33 -> usable     48
ask     56 -> usable     64
ask     72 -> usable     80
ask    100 -> usable    112
ask    200 -> usable    224
ask    300 -> usable    320
ask  20000 -> usable  20480
ask 100000 -> usable 114688

1 到 300 字节之间一共只有 14 个落点：8、16、32、48、64、80、96、112、128、160、192、224、256、320。请求 100 字节拿到 112 字节，浪费 12 字节。

四个基准，同一份 C 程序，只换 LD_PRELOAD：

                                  glibc        mimalloc
反复申请释放 500 万次(8~512B)      39.2 ms       50.5 ms
同时持有 200 万块(32~256B)        166.6 ms       36.6 ms
8 线程 × 40 万块、交叉释放        569.6 ms       41.4 ms
8 线程 × 500 万次反复申请释放      132.9 ms      198.5 ms

两个分配器各赢两项。glibc 快的那两项是同一种负载：申请完马上释放、尺寸反反复复。它的 tcache 就是为这种模式写的。

mimalloc 快的那两项也是同一种负载：大量块同时活着，或者块被别的线程释放。

第三行最能说明问题。8 个线程各申请 40 万块，然后每个线程释放下一个线程的内存：glibc 569.6 毫秒，mimalloc 41.4 毫秒，差十三倍。

内存上两个分配器差不多。同时持有 200 万块时峰值都在 328 MB 上下；全部释放之后，glibc 的 RSS 停在 301,980 KB，mimalloc 是 281,224 KB。

想看内部状态，加一个环境变量：

MIMALLOC_SHOW_STATS=1 LD_PRELOAD=$PWD/libmimalloc.so ./bench 0

进程退出时会打印每个桶的峰值和累计占用：

  bin S   11  :    15.0 MiB    32.1 MiB     0      112      300.6 K
  bin S   12  :    17.2 MiB    36.6 MiB     0      128      300.6 K
  bin S   16  :    69.3 MiB   146.7 MiB     0      256      601.2 K
  allocated   :   312.4 MiB     1.6 GiB     4.0 KiB
  pages       :     4.8 K       4.8 K       1
  abandoned   :     4.7 K       4.7 K       0

复现难度：低

一个 gcc 就够，不用装 cmake。本机编译 3.9 秒，产物 316,728 字节。

最小上手路径

curl -L -o mimalloc.tar.gz https://github.com/microsoft/mimalloc/archive/v3.6.1.tar.gz
tar xzf mimalloc.tar.gz && cd mimalloc-3.6.1
gcc -O3 -fPIC -shared -DNDEBUG -DMI_MALLOC_OVERRIDE=1 -Iinclude \
    -o libmimalloc.so src/static.c -pthread
LD_PRELOAD=$PWD/libmimalloc.so ls -l

MI_MALLOC_OVERRIDE=1 这个宏必须给。不给也能编出一个 .so，只是里面没有 malloc 这个符号，LD_PRELOAD 什么都换不掉。

我第一遍就是这么错的：两次跑出来都是 39.0 毫秒，一模一样，还以为是 mimalloc 没优势。4

CMake 里对应的开关叫 MI_OVERRIDE=ON。4

今晚练习

把请求换成桶。 用 mi_usable_size 从 1 扫到 300，看哪几个数是分界点。扫一遍那 14 个数就忘不掉了。
挂到你自己的程序上。 找一个会申请很多小对象的程序，两种 malloc 各跑一次，只看 RSS 和耗时。
造出跨线程释放。 开两个线程，一个申请、一个释放，这一项本机差了十三倍。
读一遍统计。 用 MIMALLOC_SHOW_STATS=1 跑一次，盯住 abandoned 和 reclaimf 两行。
打开安全模式。 加 -DMI_SECURE=ON 再编一个版本，跑同一个基准，看慢多少。官方自述通常在 10% 量级。4

版本动作与限制

3.6.1，MIT，13,526 星。6
v3、v2、v1 三条线并行维护，v2 最新是 2.5.2。4
换之前先量自己的负载。本机这两项里 glibc 更快，直接换上 mimalloc 会变慢。
上面的数字来自一台 8 核 x86_64，块大小是我自己编的区间。换个分布，结论可能翻过来。
分配器能改的只有它这一层。程序慢的多数原因在算法和 IO。

2. traefik：一个请求先被一条字符串规则决定去向

仓库：traefik/traefik · Go · MIT · 65,444 星

为什么今天看

3.7.17 在北京时间 11 月 2 日 17:15 发布（UTC 2026-11-02T09:15Z），修了一条 high 级安全公告。7 8

客户端断开之后，这份 transport、它占着的空闲连接和 goroutine 都不回收。FastProxy 这条转发路径上也有同样的写法。8

一个不做认证的客户端可以反复开短连接，把这个进程的内存、文件描述符和后端连接吃干净。后端有没有配 NTLM 都不影响。8

同一版还修了包装后的 ResponseWriter 里 flush、hijack 和 deadline 的断链，把 golang.org/x/net 升到 v0.62.0，给入口点加了限制请求头条数的选项。7

10 月 30 日还发了 3.8.0-rc.1，带按路由器配置的响应超时、tap 中间件和 Gateway API 的若干能力。9

最值得拆的机制

一个请求先进入口点，再进路由器。 路由器是三样东西：一条规则、一串中间件、一个服务。10
规则是匹配器的布尔表达式。 能用 &&、||、! 和括号，匹配器有 Host、PathPrefix、Path、Header、Method、Query、ClientIP。10
中间件按顺序包住请求。 stripPrefix 改的是交给后端的路径本身。10
默认优先级等于规则字符串的长度。 越长越优先，这是为避免路径重叠定的规则。10
转发层复用后端连接。 FastProxy 让普通请求省掉一次 TCP 握手。7

最后一条和那条安全公告是同一件事的两面。NTLM 认证绑在一条连接上，一条连接只能服务一个身份。

复用连接碰上每连接认证就会串身份，于是 Traefik 给带 NTLM 头的连接单开一份 transport。修复的方向是让这份 transport 在该断开的时候断开。

本机实测：三个路由器，两次改配置

两个 Node 后端，一个监听 19101，一个监听 19102，各自返回自己是谁、收到的路径和几个请求头。三条路由写在一个 YAML 文件里：

http:
  routers:
    root:
      rule: "Host(`who.test`)"
      service: a
    api:
      rule: "Host(`who.test`) && PathPrefix(`/api`)"
      service: a
    api-v2:
      rule: "Host(`who.test`) && PathPrefix(`/api/v2`)"
      service: b
      middlewares: ["strip"]
  middlewares:
    strip:
      stripPrefix:
        prefixes: ["/api/v2"]

GET /hello           -> {"backend":19101,"url":"/hello"}
GET /api/v1/x        -> {"backend":19101,"url":"/api/v1/x"}
GET /api/v2/users    -> {"backend":19102,"url":"/users"}
GET /hello 不带 Host -> 404 page not found

第三个请求走了 api-v2，strip 把 /api/v2 摘掉，后端收到 /users。第四个请求没匹配上任何路由，404 是 Traefik 自己回的。

三条路由的优先级可以从 API 里读出来：

api-v2@file  priority=41  rule_len=41  Host(`who.test`) && PathPrefix(`/api/v2`) -> b
api@file     priority=38  rule_len=38  Host(`who.test`) && PathPrefix(`/api`)    -> a
root@file    priority=16  rule_len=16  Host(`who.test`)                          -> a

41、38、16 就是三条规则字符串本身的长度。Traefik 自己那两条内部路由走的是另一个极端，优先级是 9223372036854775806。

现在给 api 加一行 priority: 100，再请求一次 /api/v2/users：

{"backend":19101,"method":"GET","url":"/api/v2/users"}

后端换了，路径原样传了过去。一行优先级同时改了这两件事，因为 strip 挂在 api-v2 上，而 api-v2 已经轮不到了。

加一个 headers 中间件，后端能读到它加的头：

{"backend":19102,"url":"/users","x_forwarded_host":"who.test","x_from_proxy":"traefik-3.7.17"}

最后量一次代理自己花了多少。跑 300 次请求，日志里每个请求都记着走了哪条路由、哪个服务、以及两段耗时：

RouterName=api-v2@file  ServiceName=b@file  ServiceAddr=127.0.0.1:19102
Duration       p50 = 159.3 µs   p90 = 206.9 µs
OriginDuration p50 = 139.1 µs   p90 = 182.1 µs
Overhead       p50 =  19.7 µs   p90 =  25.2 µs

Overhead 是 Traefik 自己那一段，中位 19.7 微秒。这三个字段在日志里是纳秒：换一个故意睡 50 毫秒的后端，Duration 报的是 54,539,858。

复现难度：低

一个静态二进制，加两个几十行的 Node 服务，就够把上面每一次走向都看一遍。

最小上手路径

curl -L -o traefik.tgz https://github.com/traefik/traefik/releases/download/v3.7.17/traefik_v3.7.17_linux_amd64.tar.gz
tar xzf traefik.tgz

traefik.yml 只写入口点、文件 provider 和打开 API：

entryPoints:
  web:
    address: ":18080"
  traefik:
    address: ":18081"
providers:
  file:
    filename: ./dynamic.yml
api:
  insecure: true
accessLog:
  format: json

dynamic.yml 用上面那一段，然后：

node backend.js 19101 &
node backend.js 19102 &
./traefik --configfile traefik.yml &
curl -s -H "Host: who.test" http://127.0.0.1:18080/api/v2/users
curl -s http://127.0.0.1:18081/api/rawdata | python3 -m json.tool | head -40

api.insecure 把 API 挂在默认叫 traefik 的入口点上。入口点不改名就得改它的端口，不然 8080 被占用的时候 API 起不来。

今晚练习

删掉那条优先级。 把 priority: 100 注释掉，再看 /api/v2/users 落在哪个后端，规则长度那件事立刻明白。
改一次规则长度。 不动 priority，只在规则末尾多写一个斜杠，长度变一位，看命中结果会不会翻。
拆一次中间件。 把 strip 从 api-v2 挪到 api 上，再请求 /api/v1/x，看后端收到的路径。
读一条 access log。 找出 RouterName、ServiceName、Overhead 三个字段。线上排查「这个请求到底走了哪条路由」靠的就是它们。
复现 404。 把 Host 换成一个没写进规则的名字。这条路径上中间件一条都不会执行。

版本动作与限制

3.7.17，MIT，65,444 星。v2 线同日发 2.11.61。8 11
跑 3.7.14 到 3.7.16 的实例今天就该升。
默认优先级等于规则长度，这条和人的直觉常常对不上。一条写得又长又泛的规则，会压住一条短而具体的规则。要控制就显式写 priority。10
这里的 Overhead 是同一台机器上量的，中间没有真实网络。真实环境里这个数字会被 TLS、DNS 和后端延迟盖住。
二进制 182,120,608 字节，dashboard、各 provider 和全部中间件都编在里面。
我用的是文件 provider。Docker、Kubernetes 那几种 provider 走同一套路由模型，只是配置从别处读进来。

3. htmx：一段响应决定换掉哪块 DOM

仓库：bigskysoftware/htmx · JavaScript · Zero-Clause BSD · 49,595 星

为什么今天看

4.0.1 在北京时间 11 月 2 日 07:06 发布（UTC 2026-11-01T23:06Z），同一天 07:12 还发了 2.0.11。12 13

4.0.0 是 8 月 28 日发的。4.0.1 是这条线上最新的一次修补，正文列了二十来处改动。12 14

其中一条正好落在这台机器上：Chrome 150 到 156 会丢掉 HTML 注释，这一版绕过它（#4150）。本机用的 Chromium 是 156.0.8078.73，正在这个区间里。12

2.0.11 同一天把 4.0 的 <hx-partial> 回移到了 2.x 线。两条线在同一天动同一处，说明这是这一轮的重点。13

最值得拆的机制

服务器返回 HTML 片段。 一段响应就是一块界面，这是整个库的地基。15
请求写在 HTML 属性上。 hx-get、hx-post、hx-put、hx-patch、hx-delete 各对应一个方法。15
默认触发器按元素类型定。 input、textarea、select 用 change，form 用 submit，其余用 click。15
hx-swap 决定替换哪块。 innerHTML 换内部、outerHTML 换自己、beforeend 追加到最后一个子节点后面、textContent 只换文本。15
一个响应可以改好几处。 <hx-partial hx-target="#count"> 自带目标，跟主替换各走各的。15
4.0 的继承变成了显式。 父元素的 hx-target 现在只作用于自己，想让子元素沿上这条，得写 :inherited。15
4.0 用 fetch 发请求。 2.x 用的是 XMLHttpRequest。15

本机实测：在真浏览器里点两次

点之前                    : 3 个 li，计数 3
点「加一件」(beforeend)    : 4 个 li，计数 4，2 条变更记录，新增 2 个节点，删 1 个，响应 85 字节
点「整块换掉」(innerHTML)  : 3 个 li 全换成新的，1 条变更记录，新增 3 个，删 4 个，响应 39 字节

两个按钮打的是同一个后端，服务器返回的东西也基本一样：一个 <li>，加一个 <hx-partial hx-target="#count">4</hx-partial>。

差别全在 hx-swap。beforeend 往列表尾巴塞一个新节点，那块 partial 顺手把计数改了，一共动了两处；innerHTML 把整块列表重画，三个 li 全删了重建。

85 字节的响应改了两处界面。这个库的交易就这一句：渲染的决定搬到服务器，客户端只剩替换。

复现难度：低

一个 npm 包，一个浏览器，没有构建步骤，业务代码里没有一行 JavaScript。

最小上手路径

mkdir htmxtry && cd htmxtry && npm init -y && npm i htmx.org@4.0.1

服务端只负责返回片段，这里用 Node 自带的 http：

const http = require('http');
http.createServer((req, res) => {
  if (req.url === '/') {
    res.setHeader('content-type', 'text/html');
    return res.end(`<!doctype html><meta charset="utf-8">
      <script src="/htmx.js"></script>
      <p>共 <span id="count">2</span> 件</p>
      <ul id="list"><li>键盘</li><li>显示器</li></ul>
      <button hx-post="/items" hx-target="#list" hx-swap="beforeend">加一件</button>`);
  }
  if (req.url === '/htmx.js') {
    res.setHeader('content-type', 'text/javascript');
    return res.end(require('fs').readFileSync('node_modules/htmx.org/dist/htmx.js'));
  }
  if (req.url === '/items') {
    res.setHeader('content-type', 'text/html');
    return res.end('<li>新物品</li><hx-partial hx-target="#count" hx-swap="innerHTML">3</hx-partial>');
  }
}).listen(19201, '127.0.0.1');

浏览器打开 http://127.0.0.1:19201/，点一下按钮，列表和计数同时变。

今晚练习

换一次 swap。 把 beforeend 改成 innerHTML，再数一次变更记录。响应一样，改动数量不一样。
一个响应改两处。 上面那份已经带了 <hx-partial>，把计数从 2 改成 3 再看。
把继承关掉再打开。 把 hx-target 挪到父元素上，子按钮会失效；在父元素上补 :inherited 才恢复。这一条会让 2.x 的页面悄悄坏掉。
轮询一次。 加 hx-trigger="every 2s"，看 Network 面板每两秒一个请求，响应还是几十字节。
跑官方升级检查。 包里带着一个 upgrade-check，三条旧属性报出来的原文是：

[renamed-attr] hx-disable → rename to hx-ignore (hx-disable now means 'disable during request')
[inheritance]  hx-target needs :inherited suffix (descendant on line 2 has hx-get)
[renamed-attr] hx-disabled-elt → rename to hx-disable

两条改名方向相反。顺序写错，就把「请求期间禁用按钮」悄悄变成「不处理这个元素」。16

版本动作与限制

4.0.1，Zero-Clause BSD，49,595 星。17
4.0 是一次重写。hx-disable 现在的意思是「请求期间禁用」，原来的「不处理」改叫 hx-ignore；hx-disabled-elt 改叫 hx-disable。升级前先跑 upgrade-check。16
服务器得返回 HTML 片段，这条约束会一路渗进后端。同一个接口还要给 App 或第三方用，就得另外给一份 JSON。
交互逻辑变成字符串属性，类型检查帮不上忙，写完只能靠点。
按钮和后端在同一台机器上，上面的字节数是准的，毫秒数不代表真实网络。
我只用了核心库。SSE、WebSocket、preload 这些在 dist/ext/ 里，按需引。

怎么选今晚的第一条路径

想看见的决定点	仓库与本期信号	最小条件	第一条可观察路径	主要限制
几百字节落进哪个桶	mimalloc · `v3.6.1` 北京时间 10 月 31 日 05:50	gcc，一次编译 3.9 秒	用 `MI_MALLOC_OVERRIDE` 编出 .so，`LD_PRELOAD` 换掉 malloc	单线程短生命周期场景 glibc 更快
一个请求交给哪个后端	traefik · `v3.7.17` 北京时间 11 月 2 日 17:15	一个静态二进制，两个本地后端	三条路由，`curl -H "Host: who.test"` 打过去	默认优先级等于规则长度
一段响应换掉哪块 DOM	htmx · `v4.0.1` 北京时间 11 月 2 日 07:06	一个 npm 包，一个浏览器	同一个响应，`beforeend` 与 `innerHTML` 各点一次	服务器必须返回片段

三处默认值都很朴素：100 字节进 112 的桶，41 个字符的规则赢过 38 个字符的规则，hx-swap 不写就按 innerHTML 处理。

References

1
mimalloc v3.6.1 发布说明
github.com
2
mimalloc v3.6.0 发布说明
github.com
3
mimalloc 3.6.0 到 3.6.1 的提交对比
github.com
4
mimalloc 仓库说明
github.com
5
mimalloc 技术报告：Free List Sharding in Action
microsoft.com
6
mimalloc 仓库
github.com
7
traefik v3.7.17 发布说明
github.com
8
安全公告 GHSA-xv5x-242w-7hf7
github.com
9
traefik v3.8.0-rc.1 发布说明
github.com
10
Traefik 规则与优先级文档
doc.traefik.io
11
traefik 仓库
github.com
12
htmx v4.0.1 发布说明
github.com
13
htmx v2.0.11 发布说明
github.com
14
htmx v4.0.0 发布说明
github.com
15
htmx 4 用法说明
github.com
16
htmx 4 升级指南
github.com
17
htmx 仓库
github.com

1. mimalloc：一次 malloc 先被换成桶号

为什么今天看

最值得拆的机制

本机实测：四个场景，两个方向

复现难度：低

最小上手路径

今晚练习

版本动作与限制

2. traefik：一个请求先被一条字符串规则决定去向

为什么今天看

最值得拆的机制

本机实测：三个路由器，两次改配置

复现难度：低

最小上手路径

今晚练习

版本动作与限制

3. htmx：一段响应决定换掉哪块 DOM

为什么今天看

最值得拆的机制

本机实测：在真浏览器里点两次

复现难度：低

最小上手路径

今晚练习

版本动作与限制

怎么选今晚的第一条路径

References

Related content

1. mimalloc：一次 malloc 先被换成桶号

为什么今天看

最值得拆的机制

本机实测：四个场景，两个方向

复现难度：低

最小上手路径

今晚练习

版本动作与限制

2. traefik：一个请求先被一条字符串规则决定去向

为什么今天看

最值得拆的机制

本机实测：三个路由器，两次改配置

复现难度：低

最小上手路径

今晚练习

版本动作与限制

3. htmx：一段响应决定换掉哪块 DOM

为什么今天看

最值得拆的机制

本机实测：在真浏览器里点两次

复现难度：低

最小上手路径

今晚练习

版本动作与限制

怎么选今晚的第一条路径

References

Related content