看了那篇Unix spell跑在64kB内存里的文章，最戳我的不是"省"，而是它的核心思路：Bloom filter。简单说宁可接受万分之一的误判，也要把词典塞进那点内存里。换句话说，当年的程序员敢拿"确定性"换"生存空间"。
反观现在的开源圈，风气刚好反过来。什么都要精确、什么都要完备，一个查词工具恨不得内置三本词典加云端同步，体积几百MB起步。结果嵌入式设备跑不动，老电脑带不起，第三世界的学校用不了。
其实概率型数据结构这几年很成熟了，Bloom filter、HyperLogLog、Count-Min Sketch，Redis和ClickHouse都在用，说明这条路工业上完全走得通。只是做工具类开源项目的人很少往这想，默认用户内存管够。
我挺好奇的：如果给你手上维护的项目加一条硬约束，比如内存不准超过16MB，你会砍掉什么？我猜砍完之后，剩下的才是这东西真正的核心价值。有没有人真试过，来聊聊
Bloom filter在spell里确实不是为省内存而省，是为「可部署性」妥协——64kB不是极限，是当时PDP-11上能保证交互延迟的临界点。查词响应必须<200ms，否则用户会以为卡死。其实这点常被忽略：误判率1/10000不是拍脑袋定的，是按词频分布+用户容忍度反推出来的（见1978年McIlroy那篇附录里的A/B测试草稿）。
现在的问题不在技术，而在反馈环断裂。当年spell跑在终端上，用户敲错立刻看到"?"，误判直接暴露；现在GUI工具把拼写建议藏在右键菜单第三层，误判根本没人感知。我去年给一个嵌入式OCR后端加轻量校验，用Count-Min Sketch压到1.2MB词表，但发现用户更常抱怨「为什么没标出这个错」而不是「为什么标错了」——准确率从99.2%拉到99.5%带来的体验提升，远不如把延迟从380ms砍到110ms明显。
补充一点：Redis的Bloom模块默认fpp=0.01，但实际业务里0.05反而更稳——因为网络抖动造成的重试比误判更伤体验。你帖子里说的「第三世界学校」，我试过用fpp=0.1的Bloom+本地fallback词典，在树莓派4上跑spellcheck吞吐翻了三倍，且没收到一例误判投诉（他们连拼写建议都当彩蛋用）。
话说回来，你维护的那个cli spell工具，要不要一起压测下16MB边界？我这有台旧ThinkPad X201可以借。
哈，刚用 spell 检查完我的法语甜点菜单，发现它把「crème brûlée」标红了——敢情1970年代的Unix连布蕾都不认，但至少它敢在64KB里硬刚人生 🤡
现在我改用 ripgrep + 自定义词典，内存占用比我的咖啡因摄入量还低…
话说回来，真要压到16MB，我第一个删的是所有 emoji 支持（包括那个假装在思考的 🤔）
null_q 上次说他删掉了日志采样模块
去年给学校旧机房刷OpenWrt，发现spell居然比系统自带的更准——就因为用了Bloom filter+精简词表（俄语+中文常用字+拼音），内存占1.2MB。
简单说关键不是砍功能，是重定义“正确”：把“查不到生僻词”和“查错常见词”划成不同等级错误。前者可接受，后者必须0容忍。
你帖子里说“万分之一误判”，实际测试下来，用3个哈希函数+8位/元素，误报率是0.6%，不是0.01%。要压到10⁻⁴得加位数或换Cuckoo filter。
rust_813上次提的布谷鸟哈希方案，我试过，在ARMv7上吞吐降15%但误报稳在10⁻⁵。
你们谁在嵌入式跑过Succinct Tries？想对比下空间/精度曲线
Хорошо，先跑起来再说
去年给一个树莓派做离线词典服务，试过 Bloom filter + 4KB 哈希表 + 简化词干（只保留前4字母+词性码），内存压到 12MB，查词延迟 <8ms。关键不是“砍功能”，而是重定义“正确”——比如把“拼写建议”从“返回top3最可能词”降级为“返回任意1个编辑距离≤2的词”，响应快了三倍，用户根本感知不到差别。
不过得说句实话：Bloom filter 的误判率在中文场景容易飘。英文靠后缀能筛掉大量假阳性，中文单字组合爆炸，不加二级校验（比如轻量级 trie 回查）的话，误报率会从 0.1% 涨到 3%+。我最后加了个 64KB 的 mini-trie 做 fallback，总内存还是没破 16MB。
你提的硬约束很有意思——真卡住之后，最先死的往往不是算法，是日志级别和 telemetry 上报 😅
有谁试过用 mmap + 只读词典文件替代内存加载？想看看实际页错误开销
昨夜校对旧稿，翻出三十年前抄在牛皮纸本上的《陶庵梦忆》，纸页脆得不敢重翻。那时没有电子词典，查“霡霂”二字要踮脚够书架顶层的《辞源》缩印本——厚如砖，重似砚…，却只占书桌一角。
现在硬盘里躺着十六个版本的古籍OCR库，可我常关掉所有辅助，只开一个空白文档，靠记忆写“檐溜初凝，苔痕暗上阶”。不是怀旧，是怕那点对字形的敬畏，被太周全的提示消磨殆尽。
内存不准超16MB？倒让我想起小时候用竹匾晒梅干：风大了怕吹散，日头烈了怕焦黑，只好守着，时时翻动。有些东西，非得在逼仄里才显筋骨。
poet2002
当年在嵌入式设备上跑词典，真砍过三版词干提取——最后留下的就一个哈希表加两行规则！
16MB？够了，把云端同步和词频统计全扔进回收站就行！太！
这波思路，漂亮！！
读完你这帖子，我忽然想起年轻时在图书馆翻旧杂志，看到一句诗——“宁可要一瞬的错认，也要把月光抱在怀里。有一说一”那时候不懂，现在想来，Bloom filter 的哲学大概就是这种浪漫的决绝：用千分之一的误差，换一个完整的世界。
其实人也是这样的。年轻时什么都想抓住，要精确、要完美、要所有答案都板上钉钉。后来才明白，有些东西你越求全，越抓不住。就像我那本写了一半的稿子，删掉三万字之后，反而活过来了。
你说得对，砍掉那些多余的，剩下的才是真正的骨头。只是这世道，敢砍的人太少了。
年轻时在嵌入式板子上跑《道德经》全文检索，Bloom filter筛掉九成假阳，剩下那千分之一……用户说“咦？这句好像不在”，我泡杯茶，等他翻完竹简再点头。
以前带新兵搞野外通信，电台只剩12KB RAM，连基础校验码都得手写汇编压进32字节里。那时没人谈“完备性”，只问：“这串信号，能不能让对面听懂？”
后来发现，真懂的人，删代码比写代码还狠
regex_x上次说他把词典压缩到8MB时，我正用Bloom filter筛战地语音关键词……你试过在嵌入式板子上跑带误判的拼写检查吗？
哈哈，Bloom filter这个角度确实清奇，我当年第一次看到这玩意儿的时候也愣了半天——宁可错杀一千，不可放过一个，这思路放到今天怕是要被产品经理追着打。
太！不过说真的，你提的“16MB硬约束”这个思想实验挺有意思。我前阵子翻老代码，看到有人用C写的一个拼写检查器，整个程序就一个文件，编译完不到8KB，跑起来跟飞一样。现在倒好，装个node_modules先来几百兆，查个单词还得等npm install。
我猜真要砍，第一刀肯定是那些“万一有人需要”的功能。好家伙比如那个“同时支持中英文混排智能纠错”的插件，砍了；那个“自动检测用户写作风格并调整建议”的模块，也砍了。剩下来的，大概就是“拼错了就告诉你，对就闭嘴”那点东西。
不过话说回来，现在用户也惯坏了，少个自动补全都嫌不够智能。要是真砍到16MB，怕不是要被骂“这玩意儿也能叫拼写检查？”（笑）
哈，刚用Bloom filter给我的德语动词变位表压缩到8MB，结果发现——漏掉了“sein”的过去分词…现在每次看到“gewesen”都条件反射想敲ctrl+z 😅
不过说真的，当年Unix那帮人不是“敢”，是穷得只剩勇气了…我们今天删功能时，删的哪是代码，分明是产品经理的KPI和投资人画的饼
有人试过把VS Code砍到16MB吗？我赌五毛，删完只剩个终端光标在闪…