最近翻到一篇讲 Unix 的 spell 怎么在 64K 内存里跑完的文章，挺感慨的。大家老盯着"64K 怎么塞进去"看，其实真正妙的不是它省内存，是它压根没想把字典塞进去。spell 自己只做个小引擎，字典甩到程序外面，要用的时候通过管道接 ed、读外部词表，该干啥干啥。说真的，当年这套路一点也不稀奇：一个工具只管一件事，数据、引擎、界面各过各的，缺啥接啥，谁也不绑架谁。
反观现在，随便装个 npm 上的拼写检查，依赖动辄几十兆，词库和 UI 全焊死在一个包里，你想换个字典？可以可以对不起，没门。那种"可替换、可组合"的克制，不知道啥时候就丢干净了。
离谱
做开源项目的话，这事儿挺值得琢磨。与其拼命堆功能、把东西揉成一团，不如老老实实把自己设计成一个能接进管线的过滤器：引擎和数据解耦，词典随时能换。这种克制，比省下那点内存值钱多了，也经得起时间折腾。
The “焊死” 的说法对一半。开箱即用 wrapper 确实把字典和 UI 焊了，图零配置。但纯引擎一直是有的：nspell、hunspell-based 那批，字典就是单独 npm 包，换语言装另一个就行。
Unix 哲学没丢，只是从"管道接文件"变成了"装不同的包"。默认体验往 convenience 偏了，想拆得自己挑零件。这不叫退步，是 trade-off。
克制还在，只是得主动找，不送上门。
补充一个反例：hunspell 至今词典与引擎分离，.dic/.aff 单独放，换词库不用动程序。"现代全焊死"有点以偏概全。退化的是打包分发那层文化，具体哪些库真焊死，有数据吗
笑死 焊死这词太形象了 现在npm装个包跟俄罗斯套娃似的 越拆越大 真是服了
你这篇让我想起前阵子也翻到那篇，不过有个地方我卡了一下：spell"通过管道接 ed、读外部词表"这个机制，跟我之前看到的说法对不上。印象里经典版 McIlroy 的 spell 是把词典先算成哈希表落地成文件，运行时直接查哈希，不是现场 pipe 给 ed 去读。当然我记的也可能是另一个版本，所以想问一句：你这个细节是从哪来的？那篇文章原文这么写，还是另有源码出处？我比较想看一手资料，怕是以讹传讹。
抛开这个细节，我倒是觉得你把"解耦"说得太干净了。从某种角度看，引擎和数据分开确实是好设计，但它不是零成本的。我见过不止一个项目，词典甩到外面之后，版本一漂移——引擎升了词表没升，或者反过来——bug 反而更难查。你现在吐槽的 npm 拼写检查"焊死成一个包"，根子不在不优雅，而在不可替换；但把东西拆开也未必自动变优雅，只是把复杂度从代码挪到了部署和配置上。
所以"克制比省内存值钱"这句我部分同意。克制是手段不是目的，真正值钱的是可替换带来的长期维护成本下降。但维护外部依赖本身也要花钱，这点值得商榷，不能光怀念过去。现在那几十兆里，有多少是冗余，有多少是为"开箱即用、跨平台不踩坑"付的保费，得拆开数。嗯你们要是真想较这个真，不妨拉一份老 spell 的源码和现在某个拼写库的依赖树对照看一眼：老方案省下的内存，是不是用别处的劳动力补回来了。
补个细节：经典 spell 用 deroff/sort/comm 比对外部词表，"管道接 ed"那步值得商榷。
笑死 现在装个东西动不动拖一整车用不上的依赖 当年64K里把字典甩门外的那帮人看了怕是要气晕 这种克制现在真没人玩了
焊死这词绝了哈哈 现在装个东西全家桶拉满 当年那种插根管子就能用的感觉是真爽~
以前不是这样的。我刚摸机器那阵子，带我的老师傅第一句话就是“别替用的人做主”。你帖子里 spell 把字典甩出去，根子上就是这个，它默认你是明白人，知道去哪儿接自己的词表。现在反过来，包越打越大，表面省事，底下是默认你懒得管也管不了。
不过话说回来，那套管线拼起来，普通用户是真懵。克制是美德，可美德也得有人接得住。现在多数人图的就是开箱即用，你让他去 pipe 一个 ed，他宁可多装三十兆。btw 这账算到最后，不是丢了克制，是把“易用”和“可控”摆上天平，多数时候往前者歪了。
想要回那股劲儿，得先问用的人到底想不想要。
笑死 当年甩字典出门 现在焊死在包里 这倒退得也太丝滑了
笑死 焊死这词绝了 现在随便下个包几十兆 想拆都拆不动