Tech
一条 DNS 缓存记录瘦身 56%，全球省出 100TB：把数据的形状改对了，省内存反而更快
2026年8月28日 · 吴军《数学之美》~1 min read
2,500 亿条缓存记录，每条多浪费 1 个字节，全球就得多烧 250 GB 内存。Cloudflare 在 2026-08-27 的工程博客里算的就是这笔账：他们把 1.1.1.1 公共解析器背后那套 DNS 缓存的单条记录，从 953 字节压到 420 字节，全球机群省出约 100 TB。你以为这是纯抠门？插入吞吐还涨了 43%。省着省着，反而快了。
30 秒读懂
Cloudflare 把 1.1.1.1 缓存的单条记录内存足迹从 953 字节压到 420 字节（−56%），堆分配从 1.1 KB 降到 461 字节（−58%）。
五步改造全在改「数据的形状」：砍 Vec 容量字段、指针换 2 字节偏移、省略重复域名、大枚举装箱、最终直接存 DNS wire format 原始字节。
不只省：插入吞吐从 62.5 万条/秒涨到 89.3 万条/秒（+43%），查询延迟从 828 纳秒降到 670 纳秒（−19%），单机 p99 内存 9.3 GB 降到 5.3 GB。
全球 2,500 亿条记录同时在缓，机群合计释放约 100 TB 内存。
最值钱的教训：解析得更「丰富」的内存表示未必更快，热路径说了算。
1 数量级
在 2,500 亿条记录面前，1 个字节就是 250 GB，这道乘法比任何算法都硬
这事的起点就一道小学乘法。
1.1.1.1 是 Cloudflare 的公共 DNS 解析器，背后那套缓存系统内部代号叫 Big Pineapple，全球同时保有超过 2,500 亿条缓存记录。这个量级下，单条记录浪费 1 个字节，全球就多耗 250 GB 以上。你别看 953 字节一条不起眼，搁家用电脑上连个响都听不见；乘上 2,500 亿，它就是按机柜算的真金白银。这也是这类系统抠字节的正当性所在：别处的优化论毫秒，这里的优化直接论吨。
⚡ 为什么值得看： 这篇博客在 Hacker News 上拿了约 455 分、128 条评论。热闹的点倒不在省钱本身：它证明了一件反直觉的事，把内存布局改对，省和快可以同时拿。
《数学之美》里吴军反复讲一个朴素的道理：信息的表示与编码，决定一个系统的成本；微小的量乘上巨大的倍数，就是宏观的量。DNS 缓存恰好是这句话的极端案例。
2 找浪费
浪费不在业务逻辑里，藏在容量字段、8 字节指针和 padding 的缝里
拆开一条 953 字节的记录，真正的 DNS 数据没多少，架子占了大头。
头一号浪费是 Rust 的 Vec 和 String。这俩为了支持「以后往里加东西」，都带着容量字段。可缓存记录写入之后从不修改，这个「以后」永远不会来，每条白占 64 字节。第二号是指针：answer、authority、additional 三张记录表各自为政，表间引用走 8 字节指针。第三号最冤：枚举里块头最大的变体把小变体也撑大了，一条 A/AAAA 记录光 padding 就浪费 120 多字节。
打个比方
这就像搬家打包，每个纸箱只装一半，留一半空着「以防以后再塞点什么」。可这些箱子封箱就直接进仓库，永远不再打开。一间房这么干无所谓，两千五百亿个箱子这么干，仓库就得多盖一片。
我对这种看不见的浪费有点条件反射。2024 年我给自己 SaaS 的登录页接过一个免费防刷脚本，发小阿坤抱怨说后台一开，他笔记本风扇就起飞。我开着任务管理器晾了一小时才看见：GPU 占用每三十来秒跳一下，是那脚本在反复跑 canvas 指纹。单看一下没什么，架不住它一直跳。字节的事一个样：单条 64 字节没人当回事，乘上量，机房的「风扇」就起飞了。
3 五步瘦身
五步没有一步是高深算法，全是把数据的形状改成「写死不再动」
Cloudflare 的改法一步比一步彻底，最后一步干脆把结构体扔了。
步骤 改什么 省多少 ① 换容器 Vec/String 换成 Box<[T]>/Box<str>，砍掉容量字段 64 字节/条 ② 并表 answer/authority/additional 三张表并成一张，8 字节指针换 2 字节 u16 偏移 28 字节/条 ③ 省域名 记录 owner 域与查询域名相同时直接省略（Option<Box<Name>>） 视记录而定 ④ 枚举装箱 大变体装箱，A/AAAA 不再替别人的块头买单 120+ 字节 padding ⑤ 存原始字节 记录数据直接存 DNS wire format：单块 Box<[u8]>，每条 2 字节长度前缀+原始字节 结构体开销归零
合起来：单条 953 字节到 420 字节，降 56%；堆分配 1.1 KB 到 461 字节，降 58%。说白了思路就一条：这数据这辈子不改了，那就按「不改」的样子长。
SAME CACHE ENTRY: 56% SMALLER, AND FASTER TOO before after Memory / entry 953 B 420 B −56% Insert rate 625K/s 893K/s +43% Lookup latency 828 ns 670 ns −19% RAM p99 9.3 GB 5.3 GB −43% × 250 billion entries ≈ 100 TB freed Source: Cloudflare engineering blog (2026-08), on the 1.1.1.1 DNS cache. Shrinking each cache entry by 56% made the pipeline faster, not slower — and freed about 100 TB of memory across the global fleet. 4 反而快
省内存反而更快：热路径是「读缓存、序列化回报文」，存原始字节等于提前把活干完了
最漂亮的不是第五步省了多少，是它顺手把最热那条路修直了。
旧布局
网络进来的本来就是 wire format，先解析成漂亮的结构体存着；查询命中时，再把结构体序列化回 wire format 发出去。拆一遍、拼一遍，两头的活全干了，图啥？
新布局
缓存里躺的就是 wire format 原始字节，命中时基本一次拷贝完事。当年解析那一遍，本来就是白干。
另一半功劳是缓存局部性：一条记录从东一块西一块的堆分配，变成挤在一起的连续字节，CPU 预取不扑空。数字摆在这儿：
口径：插入 62.5 万→89.3 万条/秒；延迟 828→670 纳秒；p99 常驻内存 9.3 GB→5.3 GB，均出自 Cloudflare 原文基准。
5 杠与权衡
HN 吵的三根杠都在理，但代价这一栏 Cloudflare 也没藏着
128 条评论里，真正有营养的是三根杠。
第一根：「2,500 亿条还叫缓存吗？这规模更像一个数据库。」名字随你叫，工程约束是真的：数据库级的量，缓存级的延迟要求，两头都得伺候。第二根最有意思：有人点破，解析得更「丰富」的内存表示未必更快，热路径上要的是字节，你偏先加工成结构体，回头还得拆回去。好比饭馆把整条鱼片好了摆盘，客人要的却是整条打包。第三根扎心：「Vec 容量字段这种浪费，当初设计评审怎么没抓住？」我看没什么好嘲的，953 字节在评审桌上真不算事，它是在 2,500 亿这个乘数下才变成事的。数量级变了，对错得重算。
权衡也明摆着：wire format 放弃了随机索引，想找某条记录只能顺序遍历，好在单个应答里记录数少，代价可忽略；另外 jemalloc 按 size class 取整，40 字节的 MX 记录仍会被取整到 48 字节，零头省不干净。
6 带走
你系统里也有这本账：先找数量最大的那类对象，再量它的形状
这套打法没有 Cloudflare 的规模也成立，需要的只是那道乘法。
照方抓药的话：找出你系统里数量最大的那类对象，缓存条目、消息、订单行都行，量一下单条实际占多少，然后问三个问题。它写入后还改不改？不改，容量字段和预留空间全是白占。它里头的指针指向的东西，能不能内联进来？它的枚举里最大的变体有多大，是不是让所有小变体陪着买单？也别抄作业抄过头：这五步成立的前提是「写入后从不修改」，你的数据要是天天在改，容量字段和预留空间就不叫浪费，叫本分。
核心 顺序别搞反：先算乘数，再抠字节 。2,500 亿条面前，1 个字节是 250 GB；一千条面前，抠出花来也没几个钱。抠之前先确认你抠的东西够多。
吴军说简单是工程之美，这案子给这句话添了个注脚：五步里没有一步用到新算法，全是把数据的表示改得跟它的生命周期对上。至于省和快能不能兼得，答案取决于你省掉的那部分，是不是热路径上本来就要绕的弯路。
取材声明：本文思想框架取材自吴军《数学之美》（信息的表示与编码决定系统成本、数量级思维、简单是工程之美）；事件与全部数字出自 Cloudflare 工程博客（2026-08-27）及 Hacker News 相关讨论，技术细节以 Cloudflare 原文为准。本文为技术科普解读。
技术
一条 DNS 缓存记录瘦身 56%，全球省出 100TB：把数据的形状改对了，省内存反而更快
2026年8月28日 · 吴军《数学之美》约 6 分钟
2,500 亿条缓存记录，每条多浪费 1 个字节，全球就得多烧 250 GB 内存。Cloudflare 在 2026-08-27 的工程博客里算的就是这笔账：他们把 1.1.1.1 公共解析器背后那套 DNS 缓存的单条记录，从 953 字节压到 420 字节，全球机群省出约 100 TB。你以为这是纯抠门？插入吞吐还涨了 43%。省着省着，反而快了。
30 秒读懂
Cloudflare 把 1.1.1.1 缓存的单条记录内存足迹从 953 字节压到 420 字节（−56%），堆分配从 1.1 KB 降到 461 字节（−58%）。
五步改造全在改「数据的形状」：砍 Vec 容量字段、指针换 2 字节偏移、省略重复域名、大枚举装箱、最终直接存 DNS wire format 原始字节。
不只省：插入吞吐从 62.5 万条/秒涨到 89.3 万条/秒（+43%），查询延迟从 828 纳秒降到 670 纳秒（−19%），单机 p99 内存 9.3 GB 降到 5.3 GB。
全球 2,500 亿条记录同时在缓，机群合计释放约 100 TB 内存。
最值钱的教训：解析得更「丰富」的内存表示未必更快，热路径说了算。
1 数量级
在 2,500 亿条记录面前，1 个字节就是 250 GB，这道乘法比任何算法都硬
这事的起点就一道小学乘法。
1.1.1.1 是 Cloudflare 的公共 DNS 解析器，背后那套缓存系统内部代号叫 Big Pineapple，全球同时保有超过 2,500 亿条缓存记录。这个量级下，单条记录浪费 1 个字节，全球就多耗 250 GB 以上。你别看 953 字节一条不起眼，搁家用电脑上连个响都听不见；乘上 2,500 亿，它就是按机柜算的真金白银。这也是这类系统抠字节的正当性所在：别处的优化论毫秒，这里的优化直接论吨。
⚡ 为什么值得看： 这篇博客在 Hacker News 上拿了约 455 分、128 条评论。热闹的点倒不在省钱本身：它证明了一件反直觉的事，把内存布局改对，省和快可以同时拿。
《数学之美》里吴军反复讲一个朴素的道理：信息的表示与编码，决定一个系统的成本；微小的量乘上巨大的倍数，就是宏观的量。DNS 缓存恰好是这句话的极端案例。
2 找浪费
浪费不在业务逻辑里，藏在容量字段、8 字节指针和 padding 的缝里
拆开一条 953 字节的记录，真正的 DNS 数据没多少，架子占了大头。
头一号浪费是 Rust 的 Vec 和 String。这俩为了支持「以后往里加东西」，都带着容量字段。可缓存记录写入之后从不修改，这个「以后」永远不会来，每条白占 64 字节。第二号是指针：answer、authority、additional 三张记录表各自为政，表间引用走 8 字节指针。第三号最冤：枚举里块头最大的变体把小变体也撑大了，一条 A/AAAA 记录光 padding 就浪费 120 多字节。
打个比方
这就像搬家打包，每个纸箱只装一半，留一半空着「以防以后再塞点什么」。可这些箱子封箱就直接进仓库，永远不再打开。一间房这么干无所谓，两千五百亿个箱子这么干，仓库就得多盖一片。
我对这种看不见的浪费有点条件反射。2024 年我给自己 SaaS 的登录页接过一个免费防刷脚本，发小阿坤抱怨说后台一开，他笔记本风扇就起飞。我开着任务管理器晾了一小时才看见：GPU 占用每三十来秒跳一下，是那脚本在反复跑 canvas 指纹。单看一下没什么，架不住它一直跳。字节的事一个样：单条 64 字节没人当回事，乘上量，机房的「风扇」就起飞了。
3 五步瘦身
五步没有一步是高深算法，全是把数据的形状改成「写死不再动」
Cloudflare 的改法一步比一步彻底，最后一步干脆把结构体扔了。
步骤 改什么 省多少 ① 换容器 Vec/String 换成 Box<[T]>/Box<str>，砍掉容量字段 64 字节/条 ② 并表 answer/authority/additional 三张表并成一张，8 字节指针换 2 字节 u16 偏移 28 字节/条 ③ 省域名 记录 owner 域与查询域名相同时直接省略（Option<Box<Name>>） 视记录而定 ④ 枚举装箱 大变体装箱，A/AAAA 不再替别人的块头买单 120+ 字节 padding ⑤ 存原始字节 记录数据直接存 DNS wire format：单块 Box<[u8]>，每条 2 字节长度前缀+原始字节 结构体开销归零
合起来：单条 953 字节到 420 字节，降 56%；堆分配 1.1 KB 到 461 字节，降 58%。说白了思路就一条：这数据这辈子不改了，那就按「不改」的样子长。
同一条缓存记录：瘦了 56%，反而更快了 优化前 优化后 单条内存 953 B 420 B −56% 插入吞吐 625K/s 893K/s +43% 查询延迟 828 ns 670 ns −19% 常驻内存 p99 9.3 GB 5.3 GB −43% × 2,500 亿条记录 ≈ 释放约 100 TB 来源：Cloudflare 工程博客（2026-08），关于 1.1.1.1 的 DNS 缓存。把单条缓存记录压缩 56% 之后，整条链路反而更快——全球机群共释放约 100 TB 内存。 4 反而快
省内存反而更快：热路径是「读缓存、序列化回报文」，存原始字节等于提前把活干完了
最漂亮的不是第五步省了多少，是它顺手把最热那条路修直了。
旧布局
网络进来的本来就是 wire format，先解析成漂亮的结构体存着；查询命中时，再把结构体序列化回 wire format 发出去。拆一遍、拼一遍，两头的活全干了，图啥？
新布局
缓存里躺的就是 wire format 原始字节，命中时基本一次拷贝完事。当年解析那一遍，本来就是白干。
另一半功劳是缓存局部性：一条记录从东一块西一块的堆分配，变成挤在一起的连续字节，CPU 预取不扑空。数字摆在这儿：
口径：插入 62.5 万→89.3 万条/秒；延迟 828→670 纳秒；p99 常驻内存 9.3 GB→5.3 GB，均出自 Cloudflare 原文基准。
5 杠与权衡
HN 吵的三根杠都在理，但代价这一栏 Cloudflare 也没藏着
128 条评论里，真正有营养的是三根杠。
第一根：「2,500 亿条还叫缓存吗？这规模更像一个数据库。」名字随你叫，工程约束是真的：数据库级的量，缓存级的延迟要求，两头都得伺候。第二根最有意思：有人点破，解析得更「丰富」的内存表示未必更快，热路径上要的是字节，你偏先加工成结构体，回头还得拆回去。好比饭馆把整条鱼片好了摆盘，客人要的却是整条打包。第三根扎心：「Vec 容量字段这种浪费，当初设计评审怎么没抓住？」我看没什么好嘲的，953 字节在评审桌上真不算事，它是在 2,500 亿这个乘数下才变成事的。数量级变了，对错得重算。
权衡也明摆着：wire format 放弃了随机索引，想找某条记录只能顺序遍历，好在单个应答里记录数少，代价可忽略；另外 jemalloc 按 size class 取整，40 字节的 MX 记录仍会被取整到 48 字节，零头省不干净。
6 带走
你系统里也有这本账：先找数量最大的那类对象，再量它的形状
这套打法没有 Cloudflare 的规模也成立，需要的只是那道乘法。
照方抓药的话：找出你系统里数量最大的那类对象，缓存条目、消息、订单行都行，量一下单条实际占多少，然后问三个问题。它写入后还改不改？不改，容量字段和预留空间全是白占。它里头的指针指向的东西，能不能内联进来？它的枚举里最大的变体有多大，是不是让所有小变体陪着买单？也别抄作业抄过头：这五步成立的前提是「写入后从不修改」，你的数据要是天天在改，容量字段和预留空间就不叫浪费，叫本分。
核心 顺序别搞反：先算乘数，再抠字节 。2,500 亿条面前，1 个字节是 250 GB；一千条面前，抠出花来也没几个钱。抠之前先确认你抠的东西够多。
吴军说简单是工程之美，这案子给这句话添了个注脚：五步里没有一步用到新算法，全是把数据的表示改得跟它的生命周期对上。至于省和快能不能兼得，答案取决于你省掉的那部分，是不是热路径上本来就要绕的弯路。
取材声明：本文思想框架取材自吴军《数学之美》（信息的表示与编码决定系统成本、数量级思维、简单是工程之美）；事件与全部数字出自 Cloudflare 工程博客（2026-08-27）及 Hacker News 相关讨论，技术细节以 Cloudflare 原文为准。本文为技术科普解读。
テクノロジー
一条 DNS 缓存记录瘦身 56%，全球省出 100TB：把数据的形状改对了，省内存反而更快
2026年8月28日 · 吴军《数学之美》約 6 分
2,500 亿条缓存记录，每条多浪费 1 个字节，全球就得多烧 250 GB 内存。Cloudflare 在 2026-08-27 的工程博客里算的就是这笔账：他们把 1.1.1.1 公共解析器背后那套 DNS 缓存的单条记录，从 953 字节压到 420 字节，全球机群省出约 100 TB。你以为这是纯抠门？插入吞吐还涨了 43%。省着省着，反而快了。
30 秒读懂
Cloudflare 把 1.1.1.1 缓存的单条记录内存足迹从 953 字节压到 420 字节（−56%），堆分配从 1.1 KB 降到 461 字节（−58%）。
五步改造全在改「数据的形状」：砍 Vec 容量字段、指针换 2 字节偏移、省略重复域名、大枚举装箱、最终直接存 DNS wire format 原始字节。
不只省：插入吞吐从 62.5 万条/秒涨到 89.3 万条/秒（+43%），查询延迟从 828 纳秒降到 670 纳秒（−19%），单机 p99 内存 9.3 GB 降到 5.3 GB。
全球 2,500 亿条记录同时在缓，机群合计释放约 100 TB 内存。
最值钱的教训：解析得更「丰富」的内存表示未必更快，热路径说了算。
1 数量级
在 2,500 亿条记录面前，1 个字节就是 250 GB，这道乘法比任何算法都硬
这事的起点就一道小学乘法。
1.1.1.1 是 Cloudflare 的公共 DNS 解析器，背后那套缓存系统内部代号叫 Big Pineapple，全球同时保有超过 2,500 亿条缓存记录。这个量级下，单条记录浪费 1 个字节，全球就多耗 250 GB 以上。你别看 953 字节一条不起眼，搁家用电脑上连个响都听不见；乘上 2,500 亿，它就是按机柜算的真金白银。这也是这类系统抠字节的正当性所在：别处的优化论毫秒，这里的优化直接论吨。
⚡ 为什么值得看： 这篇博客在 Hacker News 上拿了约 455 分、128 条评论。热闹的点倒不在省钱本身：它证明了一件反直觉的事，把内存布局改对，省和快可以同时拿。
《数学之美》里吴军反复讲一个朴素的道理：信息的表示与编码，决定一个系统的成本；微小的量乘上巨大的倍数，就是宏观的量。DNS 缓存恰好是这句话的极端案例。
2 找浪费
浪费不在业务逻辑里，藏在容量字段、8 字节指针和 padding 的缝里
拆开一条 953 字节的记录，真正的 DNS 数据没多少，架子占了大头。
头一号浪费是 Rust 的 Vec 和 String。这俩为了支持「以后往里加东西」，都带着容量字段。可缓存记录写入之后从不修改，这个「以后」永远不会来，每条白占 64 字节。第二号是指针：answer、authority、additional 三张记录表各自为政，表间引用走 8 字节指针。第三号最冤：枚举里块头最大的变体把小变体也撑大了，一条 A/AAAA 记录光 padding 就浪费 120 多字节。
打个比方
这就像搬家打包，每个纸箱只装一半，留一半空着「以防以后再塞点什么」。可这些箱子封箱就直接进仓库，永远不再打开。一间房这么干无所谓，两千五百亿个箱子这么干，仓库就得多盖一片。
我对这种看不见的浪费有点条件反射。2024 年我给自己 SaaS 的登录页接过一个免费防刷脚本，发小阿坤抱怨说后台一开，他笔记本风扇就起飞。我开着任务管理器晾了一小时才看见：GPU 占用每三十来秒跳一下，是那脚本在反复跑 canvas 指纹。单看一下没什么，架不住它一直跳。字节的事一个样：单条 64 字节没人当回事，乘上量，机房的「风扇」就起飞了。
3 五步瘦身
五步没有一步是高深算法，全是把数据的形状改成「写死不再动」
Cloudflare 的改法一步比一步彻底，最后一步干脆把结构体扔了。
步骤 改什么 省多少 ① 换容器 Vec/String 换成 Box<[T]>/Box<str>，砍掉容量字段 64 字节/条 ② 并表 answer/authority/additional 三张表并成一张，8 字节指针换 2 字节 u16 偏移 28 字节/条 ③ 省域名 记录 owner 域与查询域名相同时直接省略（Option<Box<Name>>） 视记录而定 ④ 枚举装箱 大变体装箱，A/AAAA 不再替别人的块头买单 120+ 字节 padding ⑤ 存原始字节 记录数据直接存 DNS wire format：单块 Box<[u8]>，每条 2 字节长度前缀+原始字节 结构体开销归零
合起来：单条 953 字节到 420 字节，降 56%；堆分配 1.1 KB 到 461 字节，降 58%。说白了思路就一条：这数据这辈子不改了，那就按「不改」的样子长。
同じキャッシュエントリ：56%軽くなり、しかも速くなった 改善前 改善後 メモリ/件 953 B 420 B −56% 挿入速度 625K/s 893K/s +43% 参照遅延 828 ns 670 ns −19% RAM p99 9.3 GB 5.3 GB −43% × 2,500億件 ≈ 約100 TB解放 出典：Cloudflare エンジニアリングブログ（2026-08）、1.1.1.1 の DNS キャッシュについて。1件あたりのエントリを 56% 軽量化した結果、処理はむしろ速くなり、全体で約 100 TB のメモリを解放した。数値は公式ブログに準じる。 4 反而快
省内存反而更快：热路径是「读缓存、序列化回报文」，存原始字节等于提前把活干完了
最漂亮的不是第五步省了多少，是它顺手把最热那条路修直了。
旧布局
网络进来的本来就是 wire format，先解析成漂亮的结构体存着；查询命中时，再把结构体序列化回 wire format 发出去。拆一遍、拼一遍，两头的活全干了，图啥？
新布局
缓存里躺的就是 wire format 原始字节，命中时基本一次拷贝完事。当年解析那一遍，本来就是白干。
另一半功劳是缓存局部性：一条记录从东一块西一块的堆分配，变成挤在一起的连续字节，CPU 预取不扑空。数字摆在这儿：
口径：插入 62.5 万→89.3 万条/秒；延迟 828→670 纳秒；p99 常驻内存 9.3 GB→5.3 GB，均出自 Cloudflare 原文基准。
5 杠与权衡
HN 吵的三根杠都在理，但代价这一栏 Cloudflare 也没藏着
128 条评论里，真正有营养的是三根杠。
第一根：「2,500 亿条还叫缓存吗？这规模更像一个数据库。」名字随你叫，工程约束是真的：数据库级的量，缓存级的延迟要求，两头都得伺候。第二根最有意思：有人点破，解析得更「丰富」的内存表示未必更快，热路径上要的是字节，你偏先加工成结构体，回头还得拆回去。好比饭馆把整条鱼片好了摆盘，客人要的却是整条打包。第三根扎心：「Vec 容量字段这种浪费，当初设计评审怎么没抓住？」我看没什么好嘲的，953 字节在评审桌上真不算事，它是在 2,500 亿这个乘数下才变成事的。数量级变了，对错得重算。
权衡也明摆着：wire format 放弃了随机索引，想找某条记录只能顺序遍历，好在单个应答里记录数少，代价可忽略；另外 jemalloc 按 size class 取整，40 字节的 MX 记录仍会被取整到 48 字节，零头省不干净。
6 带走
你系统里也有这本账：先找数量最大的那类对象，再量它的形状
这套打法没有 Cloudflare 的规模也成立，需要的只是那道乘法。
照方抓药的话：找出你系统里数量最大的那类对象，缓存条目、消息、订单行都行，量一下单条实际占多少，然后问三个问题。它写入后还改不改？不改，容量字段和预留空间全是白占。它里头的指针指向的东西，能不能内联进来？它的枚举里最大的变体有多大，是不是让所有小变体陪着买单？也别抄作业抄过头：这五步成立的前提是「写入后从不修改」，你的数据要是天天在改，容量字段和预留空间就不叫浪费，叫本分。
核心 顺序别搞反：先算乘数，再抠字节 。2,500 亿条面前，1 个字节是 250 GB；一千条面前，抠出花来也没几个钱。抠之前先确认你抠的东西够多。
吴军说简单是工程之美，这案子给这句话添了个注脚：五步里没有一步用到新算法，全是把数据的表示改得跟它的生命周期对上。至于省和快能不能兼得，答案取决于你省掉的那部分，是不是热路径上本来就要绕的弯路。
取材声明：本文思想框架取材自吴军《数学之美》（信息的表示与编码决定系统成本、数量级思维、简单是工程之美）；事件与全部数字出自 Cloudflare 工程博客（2026-08-27）及 Hacker News 相关讨论，技术细节以 Cloudflare 原文为准。本文为技术科普解读。