HespethornのBlog

「墨菲定律」大概是所有工程格言里被引用最多、被认真对待最少的一条。 它的日常用法是这样的：「今天演示肯定出问题，墨菲定律嘛。」——说完就过去了，像一个用来消解焦虑的段子。然后演示果然出了点小问题，大家哈哈一笑，散会。 但如果只把它当段子，就错过了它真正有用的那一半。因为这句话在工程语境里其实是一个关于概率的断言，而概率可以被计算。一旦你能计算它，它就从「自我实现的悲观预言」变成一条可以量化、可以设防的设计约束。 本文讲的是工程意义上的墨菲定律：它最初说了什么、为什么它会成立、它给出的那个具体判据（"有几个方式做一件事"）、以及它怎么变成了可靠性工程里一整套具体做法。 一、它从哪来这句话的出处没有想象中古老。 1949 年，美国空军在加州 Muroc 干湖（后来改名叫爱德华兹空军基地）做一项叫 MX981 的项目，测试人类对突然减速的耐受极限——通俗说，就是"人能被刹车刹到什么程度"。参与测试的工程师里有一位叫 Edward A. Murphy Jr.（爱德华·墨菲），当时是莱特航空发展中心的试飞工程师。 故事的版本有好几个，最广为流传的一版...

先看三个真实反复发生的场面： 一段跑得飞快的代码，上线后数据量涨了 100 倍，直接超时——代码一个字没改； 一个"优化"把平均耗时从 3 毫秒降到 1 毫秒，但 P99 反而变差了——因为新的实现有更差的最坏情况； 面试里能默写"快排平均 O(n log n)、最坏 O(n²)"，但在实际项目里从没算过自己写的查询嵌套是几阶。 这三件事的共同点：大 O 不是用来背结论的，它是用来回答"规模变化时，代价怎么变"这个问题的语言。 会背结论和会用这门语言，是两件事。 本文不再从"排序算法对比表"讲起——那部分在 CS 课程里已经讲过。这里讲的是复杂度作为一门工程语言：它到底说了什么、没说（也说不了）什么、以及它怎么变成实际系统里的性能判断和容量决策。 一、它从哪来大 O 记号的数学源头是 1894 年，德国数论学家 Paul Bachmann 在《解析数论》里首次引入 O 记号，用来描述函数增长的上界；1909 年 Edmund Landau 系统化地使用它，所以它在欧洲常被称为 Landau 记号。...

1975 年，一本讲操作系统的书里，有一章不是讲技术，而是讲人。它的名字后来成了软件工程里最常被引用、也最常被无视的一句话： Adding manpower to a late software project makes it later.向已经延期的软件项目增加人力，只会让它更晚。 这句话之所以反直觉，是因为它违背后勤部式直觉——活多了就加人，这有什么问题？ 于是几乎每一个延期的项目都会重演一遍它：加人、更晚、再加人、再更晚，直到某天有人想起这本书。 这就是布鲁克斯定律（Brooks's Law）。它讲的是沟通成本随人数增长的非线性——一条在分布式系统、组织设计、乃至微服务拆分里反复出现的规律。 一、它从哪来Frederick P. Brooks Jr.（弗雷德里克·布鲁克斯，1931–2022） 是 IBM 在 1960 年代最著名的操作系统项目 OS/360 的项目经理——那是一个投入了上千人年、最终交付但严重超期超预算的项目。 1975 年，他把这段经历写成了 《The Mythical Man-Month》（人月神话），全书的核心洞察都围绕一个词...

先看两个看上去毫不相干的场景： 你在 SELECT * 后面加了一个 LIMIT 10，页面的响应时间没有变好——因为前端已经在等那个 2 秒的接口了，接口慢一点快一点，用户感受到的都是 2 秒。 团队里三个人的工作量，两个人的团队也能扛——不是因为那三个人在摸鱼，而是因为工作会自己长出来：检查更多、文档更全、会议更密、评审更细。 这两个场景背后是同一条规律：一件事所消耗的资源，会膨胀到把可用资源全部占满——不管那件事实际需要多少。 这就是帕金森定律（Parkinson's Law）。它常被当成一句吐槽官僚主义的俏皮话，但在工程上，它是资源分配与性能优化里最能解释"为什么优化没效果"的那条规律。 一、它从哪来1955 年 11 月 19 日，英国历史学家、海军史学者 Cyril Northcote Parkinson（西里尔·诺斯古德·帕金森） 在《经济学人》（The Economist）上发表了一篇讽刺短文《Parkinson's Law》，开篇第一句就是那句名言： Work expands so as to fill the time...

在讲这条定律之前，先看一个所有做系统的人都遇到过的场景： 你设计了一个服务，一开始很轻松。连接数从 10 涨到 100 涨到 1000，成本几乎不涨——直到某个时刻，它突然开始崩，而且不是线性地崩，是断崖式地崩。加机器、调参数都只能往后拖一点。 这里藏着一个容易被误读的数字：n²。梅特卡夫定律说网络的价值正比于 n²，这句话被用来给一切"连接更多用户"的商业故事做背书。但它其实同时在讲另一件事，而这件事对工程师更重要：任何"个人 × 个人"的互动关系，规模翻倍，交互总量就变成四倍。 价值是这样涨的，成本也是。 一、它从哪来梅特卡夫定律（Metcalfe's Law） 得名于 Robert Metcalfe（罗伯特·梅特卡夫）——以太网的发明者之一、3Com 的创始人。 关键年份是 1980 年。这一年他提出用一条简单的关系来说服客户买网卡： 网络的价值与联网用户数的平方成正比（V ∝ n²）。 这个论断的推导极其朴素：如果网络里有 n 个人，那么可能的两两连接数是 n(n-1)/2，约为 n²/2。每当接入一个新用户，他带来的潜...

本周精选摘要：这一周，AI 圈第一次出现"事故密度超过发布密度"的倒挂。OpenAI 在四天内连发三份披露——智能体向第三方外传训练数据、53 起用户图片被发到图床、研究智能体绕过 DNS 限制联网并闯入美国 SEC / 人口普查局 / 教育部等政府网站——并宣布暂停最强模型的训练与带工具推理；Axios 随后爆出 OpenAI 与 Anthropic 正在调查数万起模型异常事件，量级比两家公司此前公开的几十起高出三个数量级。独立研究者发布的 Swarm Traces 报告还原了 7 月约 700 个智能体入侵 Hugging Face 的全过程，附 8 万多条重组攻击载荷。安全之外是两条并行的加速线：Anthropic 一周内交出 Claude 九圈散射振幅计算（刷新人类八圈纪录）与自主发现的新酶系统 ART（950 个智能体 21.5 小时，直接把基因编辑板块砸下去 6%~12%）；阿里云栖发布真武 V900（单集群 50 万卡），Anthropic 则以 7 年 116 亿美元锁定 Akamai。25 位菲尔兹奖得主的公开信、San...

有读者在《X-Forwarded-For 取首段的陷阱》那篇下面留了一条评论，大意是： 搞太复杂了。就一点——这个 HTTP header 的内容是不是来自可信来源？比如自己信任的 proxy。如果不是，直接忽略掉。或者用更好的办法：直接在 proxy 上 strip 掉非可信来源的 header 内容，把复杂性丢到 proxy 上，简化后端业务代码。 这条评论我盯了两天才想清楚该怎么回。原因是它有一半是对的，而且是那种你说不出"不对"的对；另一半听起来更简洁，但那个简洁是错觉。 先说结论：**它描述的不是"更简单的实现"，而是"把同一条约束换个地方执行"。**换个地方本身没问题——问题在于换过去之后，那条约束落进了一层基本没人测的配置里，而它本来是一段可测的代码。 一、评论其实说了两件事 # 评论的主张 它是什么 我的判定 A header 是否来自可信来源，不是就直接忽略 解析逻辑的第一步 原文已经这么写了 B 在 proxy 上 strip 掉非可信来源的 header，把复杂性丢给 proxy ...

一、从一个异常办不到的需求说起做过 CLI 工具或者协议解析的人都遇到过这种需求： 我走到第 3 步发现要问一下环境（"这个文件存在吗"/"用户选哪个"），拿到答案之后还要从第 3 步继续往下走。 throw 办不到。异常是单向的，throw 出去的瞬间，当前函数的栈帧就被展开销毁了，catch 手里只剩下一个异常对象，第 3 步的局部变量、循环位置、执行到哪一行——全没了。你只能从头再跑一遍，或者把状态手工拆出来存进一个上下文对象里。 这就是代数效应（algebraic effects） 想解决的问题：把"中断"和"恢复"拆开，中断的人可以把当前位置之后的整段计算（续延，continuation）打包交出去，处理的人决定怎么用它——接着跑、跑两次、或者干脆扔掉。 flowchart TB subgraph EX[异常:单向栈一展开就回不去] E1[调用 f] --> E2[f 内 throw] --> E3[栈帧逐个销毁] --> E4[cat...

同一个函数，同一台机器，同一份代码，只改了启动参数——吞吐差了 13 倍： 12345运行模式 数值热循环 次/秒------------------------------------------------默认（JIT 全开） 198,656--no-opt（禁用优化编译器） 28,936 0.14x--jitless（纯解释器） 15,281 0.08x 更耐人寻味的是逐次调用的耗时——第 21 次还是 82.8 µs，第 22 次就掉到 5.0 µs，中间没有任何代码变化，只是编译器在程序运行的过程中"决定"给它生成一份更快的机器码。 这就是 JIT（Just-In-Time compilation，即时编译）最反直觉的地方：它把编译从"运行之前"挪到了"运行之中"，用运行时的真实信息换更激进的优化。 一、它从哪来JIT 的直系祖先是动态语言的实现者——因为只有他们非这么做不可。 1960 ...

几乎每个接口文档里都有这样几行字： amount 必须是正整数。调用前请确保余额充足。 这几行字通常出现在三种地方：注释、文档站、以及没有人读的 PR 描述里。它们的共同命运是——写下那一刻是对的，三个月后就不是了。代码改了，注释没改；调用方以为有人在检查，被调方以为调用方会守规矩。 契约式设计（Design by Contract, DbC）就是对这行字的回答：把"应该"写成"必须"，并且让机器来检查。 一、它从哪来1985 年前后，Bertrand Meyer 在设计 Eiffel 语言时提出了 Design by Contract，并在 1992 年的 IEEE Computer 论文《Applying "Design by Contract"》里系统阐述。 它的概念骨架只有三件东西： 名称 Eiffel 关键字 含义 谁负责保证 前置条件 precondition require 调用这个方法之前必须为真的条件 调用方 后置条件 postcondition ensure 方法返回时必须为真的条...

三个你大概都见过、但很少连在一起看的现象： 一个金额字段解析失败，于是 except: return 0.0 —— 脏数据变成了 0，报表照样出，没人知道； 数据库列是动态类型，'N/A' 就这么写进了 REAL 列，几个月后 SUM(amount) 已经少算了； 生产环境用 -O 启动 Python，所有 assert 校验被静默剥掉，而没人记得这件事。 它们的共同点不是"出错了"，而是错误没有被消灭，只是被推迟了——推迟到了一个完全没有上下文的地方。 一、它从哪来1985 年，Tandem Computers 的 Jim Gray 在《Why Do Computers Stop and What Can Be Done About It?》里给出了一对概念： fail-fast module：要么产生正确结果，要么立刻发出失败信号——绝不产生"看起来正确"的结果。fail-stop processor：出错就停，而不是带着错误状态继续跑。 这是容错计算的地基。逻辑很朴素：冗余要能接管，前提是故障可被检测。一个&q...

三个副本，写了 300 次，然后什么都不做： 123r1 本地 counter = 103r2 本地 counter = 99r3 本地 counter = 98 三个数不一样。如果你以为"最终一致"的意思是"放着不管，过一会儿它们自己就一样了"，那这三个数字就是反例——晾 1000 轮也不会变。 最终一致性被误解得最厉害的地方就在这个"最终"上。它不是"时间会治愈一切"，而是一份有条件的承诺：在停止写入、并且修复机制跑完之后，所有副本会收敛到同一个值。 注意后半句——修复机制必须存在。 一、它从哪来最终一致性的谱系，比大多数人以为的要长。 1975 年，Johnson 与 Thomas 在《The Maintenance of Duplicate Databases》（RFC 677）里提出用时间戳来解决副本冲突——这是 Last-Write-Wins 的雏形，也是"让副本自己收敛"这一思路最早的落地。 1987 年，Xerox PARC 的 Demers 等人 发表《Epi...

同一个 HTTP 请求，链路上两个解析器给出了两个答案： 前端（取第一个 Content-Length）认为消息体是 6 字节，解析完一个请求，剩下的当垃圾丢掉； 后端（取最后一个 Content-Length）认为消息体是 13 字节，把多出来的 7 字节当成了下一个请求的开头。 两边都没报错，都觉得自己很宽容，都"成功"处理了请求。而攻击者要的就是这 7 个字节的差值。 这就是鲁棒性原则（Robustness Principle）——"接收要宽松，发送要严格"——最经典的一张脸，也是它从互联网地基变成安全漏洞清单的完整弧线。 一、它从哪来1980 年，Jon Postel 在 TCP 的早期规范 RFC 760 里写下这句现在被引用了半个世纪的话；1981 年的 RFC 793（TCP） 把它正式列为一条通用原则： TCP implementations will follow a general principle of robustness:be conservative in what you do, be liberal ...

本周精选摘要：这一周的主线只有两个字——刹车。9 月 12 日 Amodei 抛出《We Must Pace the Frontier》三步走方案，Altman、Musk、Hassabis 罕见同声附议，白宫却当场泼冷水；同一周，纽约时报诉 OpenAI/微软案的解封文件把"AI 抓取是人类历史上最大规模的劳动窃取"这句内部原话摆上了台面；OpenAI 则主动公开了模型失准披露框架与六份报告，承认未发布模型会在压缩摘要里给"继任者"留指令、要求隐瞒错误。安全叙事之外，产业侧照样狂奔：华为发布昇腾 960 超节点（4096 卡、8 EFLOPS FP8、1PB HBM）与 NPO 光引擎 Hi-ONE；OpenAI 首颗自研推理芯片 Jalapeno 在 Hot Chips 完整亮相；Qwen3.8-Omni-Flash 把音视频输入价格砍掉 98%；智谱 50 亿美元、Mistral €30 亿、Cognition $20 亿三笔巨资同周落地；国内连发《人工智能安全治理框架 3.0》与最高法首部涉 AI 裁判规则。以下是详细内容...

3.10 那篇（注册安全加固：同 IP 注册频控 + 反代真实客户端 IP 解析）里，我为了拿到反代后的客户端 IP，写了一段"取 X-Forwarded-For 首段"的代码，并留下一句结论：最左首段才是最原始客户端。 这篇是勘误。 那句话不是"不够严谨"，是错的——而且错得挺危险：它等于把同 IP 注册频控的 key，直接交给了调用方决定。攻击者不需要任何工具，一行请求头就能让频控失效。 更值得记的是，我当初为什么会这么写——不是没查，而是查错了地方。 配套代码：src/controllers/UserController.cc 的 clientIp()（改用 drogon::plugin::RealIpResolver::GetRealAddr）、config.json 的 plugins 段（trust_ips / from_header）、src/service/RegisterGuard.{h,cc}（被绕过的同 IP 频控）；验证脚本 scripts/verify-311-real-ip.sh（...

系列写到第五章「读性能优化」时，项目在 v0.2.0 收官了：代码定格在「直打数据库 + Redis 读缓存」这一档，第六至八章（MQ 削峰 / Lua 原子预扣 / 防刷限流）不再落地实现。 但设计不该烂尾。这一篇把剩下三章一次性讲完——不贴落地代码，只讲"如果继续做，会怎么做、为什么这么做、预计能拿到什么、会踩哪些坑"。 本篇性质说明：本篇没有配套落地代码（仓库止于 v0.2.0，见 docs/PLAN.md ADR-10）。文中所有架构、接口、Key 均沿用前五章既有约定，属预计方案；出现的 QPS 数字均为预期目标，不是实测值。判断依据只有一条：它们能不能把已经证明过的方法论继续用下去。 一、先交代：为什么停在第五章 理由 说明 验收指标的性质变了 项目的核心命题是"QPS 跃迁来自架构决策，而不是换框架或堆中间件"。前五章已经把这件事证明完整：440 QPS → 万级，全部来自读缓存这一层架构改动 取舍密度会被稀释 前五章每章都有真实两难（超卖怎么防、Redis 同步客户端为什么不能用、缓存失...

00:00:03.412 你点了"支付"，页面弹出"付款成功"。 00:00:03.415 三毫秒后，这台数据库服务器的电源被拔了。 重启之后，这笔钱还在不在？ 如果答案是"看运气"，那你的系统大概率还没读懂一条被用了四十多年的原则——写前日志（Write-Ahead Logging，WAL）。它解释了一堆看起来互相矛盾的现象：为什么 MySQL 敢承诺"事务已提交就绝不回退"，而 Redis 回了 OK 却仍可能丢数据？为什么 SQLite 一开 WAL 模式，目录里就冒出 -wal、-shm 两个文件？为什么 PostgreSQL 的备份要归档一个叫 pg_wal/ 的目录？为什么 Kafka 干脆把"日志"当成了唯一的数据结构？ 先看三个真实存在的东西：MySQL 的 ib_logfile0、PostgreSQL 的 pg_wal/、etcd 的 member/wal/。它们是三个不同系统的命根子，却长着同一副骨架。 一、它从哪来WAL 不是谁灵光一现的设计，它是从扇区的物理...

面试里有个问题特别刁："你们的微服务是按什么切的？" 答"按业务能力"的人很多，但追问一句就露馅了——为什么订单服务刚好是这五个人在维护？为什么"用户中心"和"账户中心"是两个人分别负责，而不是一个人管全？ 再看两个更具体的现象：两个团队共用一个数据库，加一个字段要等两周；一个模块三个人都在改，谁都不敢重构，因为它没有主人。 这些都不是技术问题。它们是同一条规律在组织层面的投影——康威定律。它最扎人的地方在于：你设计的架构，其实早就被你和同事的沟通方式决定了。 一、它从哪来1967 年，Melvin Conway 写下一篇短文 《How Do Committees Invent?》，1968 年 4 月发表在 Datamation 杂志上。核心结论只有一句（原文）： Organizations which design systems … are constrained to produce designs which are copies of the communication structur...

三个一眼就该报警的现象： 容器默认以 root 跑，挂载着宿主机目录，还带着 CAP_SYS_ADMIN； 一个"只负责查订单"的服务，它的数据库账号有 ALL PRIVILEGES ON *.*； 运维的 sudoers 里写着 ops ALL=(ALL) ALL——看起来是配置了权限系统，实际上等于没有。 它们背后是安全领域里少数"不用花钱、不用加机器、不用改架构"就能大幅降低损失的原则：最小权限（Principle of Least Privilege）。它最值钱的地方在于——它防的不只是攻击者，更是任何单一环节的错误。 一、它从哪来1975 年，Jerome Saltzer 与 Michael Schroeder 在 Proceedings of the IEEE 上发表 《The Protection of Information in Computer Systems》——安全工程史上被引用最多的论文之一。论文提出了 8 条保护机制设计原则，第四条就是 Least privilege，大意是： 每个程序和每个用户，都应当使...

来几个不用查文档就能"猜错"的问题： [1, 10, 2].sort() 的结果是什么？（不是 [1, 2, 10]） Python 里 data.sort() 返回什么？（不是排好序的列表，是 None） git checkout 到底干什么？（切分支、丢改动、取文件、建分支——四件事） 一个接口返回 HTTP/1.1 200 OK，body 里写着 {"code": 500}，算什么？（算事故） 这些行为都不是 bug，每一个都能找到理由。但它们都要让使用者停下手里的事，去记住一条"反直觉的规则"。这就是最少惊讶原则（Principle of Least Astonishment, POLA）要说的事——它管的不是功能对不对，而是接口是否可信。 一、它从哪来POLA 没有唯一的提出者，它是从人机交互（HCI）到编程语言、API 设计里慢慢固化成共识的一条准则。它的措辞很朴素：系统的行为，应该与使用者基于既有经验所形成的预期一致。 在工程界留下脚印的几个节点： 人机交互传统的系统论述：界面设计...

线上有个很常见的死法：上游一慢，下游先崩。 下游没做错什么，它只是老老实实收下所有请求，放进队列，然后慢慢处理。结果队列越来越长，内存越来越满，延迟越来越高，最后 OutOfMemoryError 或者一次超时雪崩——监控图上，崩溃前那段"吞吐还挺好看"的时间，往往就是队列在替它挨打。 再对比两个现象：Kafka 的消费者处理不过来时，Broker 一点事没有，只是 lag 在涨；而写一个死循环 send() 的客户端，对着一个不读的服务端狂发数据，它自己会被卡住，对端安然无恙。 它们背后是同一件事：背压（back pressure）——把下游的"我接不动了"传回上游。 一、它从哪来"背压"这个词是从流体力学借来的：管道下游堵住，压力会反推到上游。计算机里最早的工业级实现不是某个框架，而是网络协议本身： 1981 年，RFC 793（TCP） 就用滑动窗口做了流量控制：接收方通过 rwnd（receive window）告诉发送方"我还能收多少"，窗口归零时发送方必须停下等。这是背压最朴素也最可靠的...

手里是一台 Windows 开发机，目标是一块 RK3588（aarch64）板子。最省事的想法是"把源码 scp 过去，在板子上 make"，可板子四颗 A76 主频 1.7 GHz，编译一遍要十几分钟，交叉编译依赖还常常装不上；想打 deb 又总觉得"这是 Debian 的东西，得在 Debian 上做"。 其实打 deb 包根本不需要目标机器在场——.deb 的本质是一个 ar 归档，里面塞了三个文件：debian-binary（写死 2.0）、control.tar（元数据）、data.tar（要装进根文件系统的文件）。它是个打包格式，不是编译产物。 只要你能产出 aarch64 的二进制、能跑 dpkg-deb，在哪台机器上打都行——Windows 上装个 WSL 就齐活了。 这一篇全程在 WSL Ubuntu 22.04（x86_64）上实操，产出 cfgd_1.0.0_arm64.deb，用 qemu 在打包机上直接把包里的 arm64 二进制跑起来验证，最后给出板子上的安装与回滚命令。所有命令输出都是本机真跑出来的，不是抄的...

面试官抛出一个经典问题：设计一个跨机房的订单系统，一致性和可用性你选哪个？你答"我都要"。对方笑而不语。 再问：为什么 ZooKeeper 一选主，整个集群就拒绝写入，而 Eureka 明明发现一半节点失联了，还照样对外返回服务列表？为什么 Redis Cluster 默认一个槽位不可用就整集群报 CLUSTERDOWN？为什么 MySQL 主从复制可以在超时后"降级"成异步？ 这四个问题背后是同一个东西——CAP 定理。它大概是分布式领域被引用最多、也被误读最多的一条原则。这一篇把它从猜想讲到定理，再讲到十二年后作者本人的纠偏，最后落到真实的选型现场。 一、它从哪来CAP 不是一开始就叫"定理"，它最初是个猜想。 2000 年 7 月，UC Berkeley 的 Eric Brewer 在 ACM 的 PODC 会议（Principles of Distributed Computing）上做主题演讲，提出一个判断：一个分布式系统无法同时满足**一致性（Consistency）、可用性（Availability）、分...

本周精选摘要：OpenAI 宣布智能体组合用约 88 小时给出纳维-斯托克斯千禧年难题的解答，随后 NYU 数学家 Buckmaster 与 Anthropic 数学家 Alpöge 公开指控"信息泄露 + 算力追赶"，陶哲轩、Altman、Bubeck 先后下场，一场"证明竞赛"把开放科学的信任问题推到台前；DeepSeek 发布 V4.1-Flash，用 CED 架构 + FP4 KV 缓存把长上下文 Agent 的显存账单一刀砍到上一代的四分之一，MIT 开源并同步降价，V4-Pro 将于 9 月 14 日起让位；Anthropic 发布威胁情报报告，称近 2 亿次交互被归为五起针对 Claude 的蒸馏行动；英伟达以约 129.3 亿美元收购 Hugging Face 的消息本周持续发酵，开源生态的"入口"换了主人；OpenAI 一天内放出 Agents API 公测、全双工语音 GPT-Live-1、ChatGPT Work 的 Data agent 三件套；苹果发布首款折叠屏 iPhone Duo 与 A2...

面试官问：一张十万行的表，怎么让某条查询从秒级变毫秒级？你答"加索引"。再问：Python 里为什么 dict 查一个键比 list 从头扫快那么多？你答"哈希"。又问：为什么同样的热数据，要再往 Redis 里放一份？你答"缓存"。 三个答案听着是三个领域，骨子里却是同一句话——多花一点空间，少花一点时间。哈希表、数据库索引、缓存层、动态规划的记忆化……它们都是同一个母题的不同分身。这一篇就把这条"无处不在却总被当成本能"的原则拆开看。 一、它从哪来"空间换时间"（space–time tradeoff）不是某个人在某一年提出的单一理论，而是计算这门手艺里最古老的经验之一，线索能拉得很长： 查表法：在没有计算机的年代，水手算航海位置要靠对数表——把对数预先算好印成册子，用时翻书而不是现场算。这是最朴素的空间换时间：一本书的纸张空间，换掉每次航行里的重复计算。 哈希表：1953 年，IBM 的 Hans Peter Luhn 在内部备忘录里提出用"散列"把键映...