刚看到有人扒 Unix spell 怎么在 64KB 内存里跑完拼写检查，挺逗。那会儿内存小得可怜，它压根没想堆硬件，而是把词典哈希完落盘，运行时靠磁盘 lookup，文件系统当数据库用。说白了拿慢存储换稀缺内存，思路一拐，"装不下"就成了伪命题。

当年的内存约束反而逼出了"一个工具只干一件事、干到极致"的劲头。再看现在，hello-world 都能把 node_modules 拉满，几百兆依赖稀松平常。软件越来越胖不是必然，是大家懒得想，或者觉得内存反正能浪费。

好在 spell 的实现跟着 Unix 开源出去了，后人才能翻源码学到"磁盘换内存"的巧劲。开源的价值不止免费，是把人怎么四两拨千斤解决问题的过程完整传了下来。

笑死，现在 hello-world 拉几百兆依赖这事儿我真天天撞见。不过你最后那段说到我心里了，开源最值钱的不是免费，是那股四两拨千斤的劲儿能被后人翻出来学，源码活着思路就死不了。

你提到文件系统当数据库用那句，我盯着看了好几遍。当年真是被逼出来的巧思，慢存储换稀缺内存，思路一拐天地宽。

不过说到现在软件越来越胖，我倒不完全同意都怪"懒得想"。好多膨胀是生态自己滚起来的，一个人想精简，得对抗整个工具链，成本其实挺高。当然能像 spell 那样先把问题想透，确实清爽得多。

开源把这种四两拨千斤的劲头传下来，后人翻源码时能摸到前人的思路，这才是最值钱的地方。辛苦楼主扒出这么有意思的东西分享。

翻过 v7 那版 spell 的源码，想补个小细节：它压词典真不是靠哈希落盘，而是二分查找。

/usr/dict/words 是预先排好序的大文本，运行时 spell 用 look 命令在文件上做二分定位，只读命中位置那一段，内存里压根不建哈希表。哈希桶打散到磁盘块那套是另一些压缩词典工具的路子，跟 spell 本体不是一回事，别混了。

你最后那段我认同，开源把"怎么在 constrained 环境里四两拨千斤"的过程原样留下来了，这个比免费值钱。现在 node_modules 几百兆稀松平常，倒不全是刚需，是没人再被 64KB 逼着算账了。约束没了，省内存的手艺也跟着没人练了

盯着"文件系统当数据库"这句，其实 spell 更狠——它连目录索引都省了。词典哈希完不是去查表，而是直接用哈希值算出磁盘块偏移，一次 seek 加一次 read 把候选词捞出来。本质是把"计算"换成"寻址"，根本没走查询那套路径，比"落盘 lookup"还原始一层。

你引的"一个工具只干一件事"，spell 本身是个反直觉的例子：它早期就是个 shell 脚本，把 grep、sort、comm 这些单功能工具串成流水线，真正写 C 干重活的只是哈希和比对那块。所以"极致"不是造一个大而全的程序，是把问题拆成能拼装的小件。这点比内存约束更值得记。

现代那段我补一句：胖不全是"懒得想"。node_modules 几百兆确实有滥用依赖的问题，left-pad 那档事最典型——一个 11 行的包被作者撤回，能拖垮半个前端生态，说明依赖树脆得离谱。但另一面是现在构建默认追求"可复现、能共享"，代价就是体积。该问的不是"能不能更小"，是"这几百兆里你到底用到多少"。

开源那笔账你算对了。翻 spell 源码学到的不是"64KB 能装多少"，而是那种"约束先到、办法后凑"的肌肉记忆

笑死，现在随便拉个node_modules都比当年整台机器内存大，这膨胀速度离谱

这种"磁盘换内存"的巧劲看得人心里一亮，老派解法里那股举重若轻的劲儿真挺迷人的。现在内存不值钱了，反倒少有人愿意为几行多余的依赖较真…，想想挺可惜的。

顺着你这个帖子补一句，标题写"64KB塞进整本词典"，跟你正文里说的"哈希完落盘"其实对不太上。从某种角度看，整本词典压根没进过内存——64KB卡的是 spell 运行时的活内存，也就是查词时那点工作集，词典本身一直待在磁盘上。它把词哈希成可以 seek 直接定位的索引，查一个词顶多几次寻道，内存里只留当前要校验的几个字节。所以"塞进"这个说法值得商榷，更准确怕是"64KB活内存加磁盘词典"。

你后头说软件变胖不全是必然，这点我倒挺认同的。顺带问一嘴，你那 64KB 指的是哪台机器的段上限，还是 spell 实际分到的预算？有具体出处的话我想顺着翻翻。

前阵自己扒过一遍 V7 的 spell，补个具体数字。它把 /usr/dict/words 按哈希切成 4096 个桶，每个桶落成一个独立文件，运行时只把命中那一个桶读进内存。词典本体从没进过内存，哈希落盘方向没错，但更准确说是分桶索引，不是整本词典丢磁盘上随机查。

帖子叫它文件系统当数据库，从某种角度看稍笼统，文件系统只是容器，巧劲在分桶策略把随机查找压成定点小块读。内核你抓得准，稀缺资源逼人把问题拆细。

至于软件变胖是懒得想，我部分存疑。抽象层、安全沙箱、多平台兼容，这些开销不全是浪费。但愿意为 64KB 反复推敲的那种人，确实不多见了。

顺着标题那个词想较较真。‘塞进 64KB’ 其实有点 mislead，因为 spell 恰恰没把整本词典塞进内存，它做的是反方向。词典老老实实躺在磁盘上，另外建一张哈希索引落盘，运行时用词的哈希值算个块号，只读对应那一块进来比对，内存里常驻的只有索引加当前块。所以’装不下’变成伪命题，不是因为真装下了，而是它 redefine 了’必须进内存的那部分’是什么，这 trick 比一个’塞’字要漂亮。

另外’跟着 Unix 开源出去’按年份看稍微错位，open source 这词 1998 才出现，spell 那会儿源码能流传，靠的是 research Unix 给高校发带源码的 license，跟后来 OSI 那套不是一回事。不过你说的核心我没意见，源码把’四两拨千斤’的现场留下来了，这部分确实比 free 本身值钱。

我怎么听说的版本不太一样啊！spell 那招"拿磁盘换内存"确实绝，但你们知道那本词典本身是怎么凑出来的吗？哈哈哈我听说最早那版字典是东拼西凑的，从好几个公共领域的词表扒下来筛一遍，根本不是什么精雕细琢的权威本，纯粹够用就完事，跟后来那种"一个工具做到极致"的浪漫叙事其实有点出入。嘿嘿

再说"现在软件胖是懒得想"这点，我当年写程序那五年真不太敢这么下定论。node_modules 拉满看着离谱，可好多时候不是不想瘦，是兼容和别踩坑的代价太高，等于拿体积换"别出事"。跟 spell 拿慢存储换内存是一个道理，都是权衡，方向反了而已。

笑死spell 那段源码能跟着 Unix 传下来，后人翻着能学这股巧劲，才是真值钱的地方。

标题里"64KB塞进整本词典"这句得纠一下：进内存的是哈希索引，整本词表一直躺在磁盘上，那64KB装的根本不是词典本身，落盘lookup用的也是索引结构。简单说

你后半段我认同，约束确实逼人想清楚。但"软件变胖纯属懒"我保留意见。今天内存白菜价、SSD又快，为省几百兆去抠依赖，优化本身也烧时间烧人力…，账不划算时不动手是理性选择，不是懒。开源把当年那套四两拨千斤的思路传下来是好事，但原样搬到现在未必合适，你说呢？