说真的，看到Unix那个spell在64k内存里跑拼写检查，我第一反应是：这哥们儿压根没想自己扛。它把字典甩到磁盘上，活儿拆给sort、grep这些老伙计，再用管道一个接一个传下去，所谓能在64k里跑，其实是把重活全外包出去了。
好吧好吧
离谱的是这思路放今天一点都不过时。现在多少开源项目，写个工具恨不得连日志库、配置解析都自己造一套，美其名曰"零依赖"，结果代码越堆越臃肿，内存倒是省了，人脑子不够用了。说真的，Unix那帮老头子早把答案给过了：别啥都自己扛，该借力就借力，把各路小工具串成一条线，活自然就通了。
咱们开源圈真该把这种"借力"的古早智慧捡回来，而不是天天比谁造的轮子多。
你这个"外包"的比喻我吃，Unix那条管道哲学确实到现在都站得住。不过"64k能跑"的根因可以再精确点：不是活儿真甩没了，是管道让每个环节跑完就退场，峰值内存才压得下来。字典靠哈希查，不是拿grep硬扫原始词表。
零依赖那部分我倒觉得有点扫射。真坑人的是图省事import一整个框架、顺带拉进来几十个间接依赖的项目。自己撸个二三十行的配置解析，往往比引第三方更可控。借力要对地方，但"能不引就不引"这件小事，真没必要一起骂。
现在npm那棵依赖树才该被挂路灯。
笑死 把活儿全甩给老伙计 这思路放今天叫甩锅 当年叫智慧 哈哈
等等，我怎么听说的版本不太一样。那个spell把字典甩到磁盘上，真不是什么“早看透了借力哲学”，当年那机器就64k，不甩出去程序根本起不来——是先被逼的，后来才被后人包装成古早智慧。
不过说到今天开源圈自己造轮子，我有个八卦不知道该不该说。前阵子有个挺火的小工具，作者天天喊极简零依赖，结果被扒出来核心逻辑是把人家成熟库抄了一遍改了名，社区里闹了好几天。所以“借力”和“偷懒抄近道”中间那条线，比楼主说的要模糊得多，真捡回古早智慧的人没几个，拿它当遮羞布的倒不少。
绝了
你们见过更离谱的伪零依赖翻车现场吗哈哈
楼主拿spell当例子挺妙的，不过"64k内存跑通拼写靠外包"这句，严格说把两件事揉在一起了，值得拆开看。
一是内存约束的本质。早期Unix进程地址空间确实小，pipeline把任务切成sort、grep、comm这些独立进程，每个只占自己那一份内存，所以单进程看着省。但这省的是"单个进程的内存"，不是系统总账——字典在磁盘上、临时文件一堆、管道来回拷数据，真实代价转移到了I/O和进程调度。说白了，它是把内存压力换成I/O压力，不是真的"轻"。
二是"借力"和"零依赖"未必对立。今天有人自己造日志库、配置解析，很多时候不是忘了Unix哲学，而是运行环境根本不允许他假设目标机上躺着sort和grep——浏览器里的JS、跨平台二进制、嵌入式固件，这些地方借不到系统工具，只能打进包里。当年的借力能成立，前提是全世界共用同一套Unix工具链，这个前提今天碎了。
我倒觉得真正该捡回来的不是"借力"二字，而是"单一职责加可组合"这条线。你看ripgrep、fd、jq、fzf，全是现代重写，但照样走管道、只干一件事，那才是老头子们留的底子。至于依赖多寡，从某种角度看更像工程权衡而非信仰：引一个外部库省了代码，也多了供应链和版本绑架的风险，这笔账得具体项目具体算，不能一句"别造轮子"就打发。
你们现在写小工具，会先摸一遍标准库再决定引不引包，还是直接上现成的？
今天谁还敢假定目标机上一定装着sort/grep、版本还对得上？spell能跑，靠的是系统自带件稳。现在重写轮子多半是怕传递依赖不可控、构建不可复现，不是单纯爱造。借力有账期，外包的活迟早要还。
spell 那套脚本我翻过，核心就一行思路：输入按非字母切成词、sort 去重、再拿 comm 跟 /usr/dict/words 做差集。所以它"跑在 64k"指的是 spell 自己那点脚本占的内存，sort、grep、comm 各自另开进程吃自己的份额——你说的外包没错，但严格讲不是"在 64k 里把拼写检查干完"，是拆给一串独立进程轮流上。这精度得补一下。
顺着你的"借力"往下，我觉得真正值钱的是另一层：那些老工具能串起来，靠的不是谁帮谁，而是它们全吃纯文本、走 stdin/stdout，接口稳定到几十年不变。spell 敢把字典甩给 comm，是因为它确信 comm 永远按行读、按字典序比。可组合的前提是接口契约稳。今天开源圈的问题往往不是"造轮子多"，而是大多数轮子没有这种通用接口——你引一个库，吃的是它自定义的 struct 和异常体系，根本没法像管道那样随手接上下家。
所以"别自己扛"得加个前提：能借力的前提是借来的是标准件。Unix 年代标准件是 OS 自带的 sort/grep，白送；现在你想借个日志库，常得连它那套 transitive 依赖、版本号和 license 一起吞。Leftpad 就是典型——为几行功能引整个包，对面删库全網跟着挂，这种"借力"等于把风险也外包出去了。其实
我更认同的玩法：能文本化、能管道化的，坚决不自己造；核心路径上出事要自己兜底的，多写两百行比引个黑盒踏实。你那边有没有被哪个依赖坑过的例子，发出来大家避个雷。
笑死 64k跑通纯靠sort grep在底下扛雷 这哪是它本事 分明是外包典范
spell 实际靠的是 comm 不是 grep，字典排好序做差集。零依赖跟自造轮子也别划等号，不少零依赖项目纯用标准库，压根不臃肿。
被甲方改了快五十稿才悟过来，啥都自己扛真会疯。楼主这帖说到我心坎里了
把字典甩到磁盘上，这个画面让我停了一下。从前我自己开公司，也是什么都想攥在手里，连不该自己写的都硬写，好像不亲手摸过就不放心。后来才懂，人不是64k的盒子，弦绷得太紧会断的。楼主说的"借力"，说到底是一种舍得。Хорошо，现在学着把活交出去，手空了，反倒能安安静静多下一盘棋。
我前阵子被一个两年没更新的小依赖坑过，作者突然删库，CI 直接红，连带挂了三个服务。所以有些人喊零依赖真不是想炫耀轮子多，是怕被人删库删到怀疑人生。
你那个 Unix “借力” 思路我认同，但把现代人的依赖焦虑简化成 “爱造轮子” 有点草率。left-pad 之后，多少人不是不想借，是不敢随便借。依赖一多，license 冲突、供应链投毒、版本锁死，哪样都比内存多点头疼。
我觉得真该捡回来的是 “小工具、单一职责、用干净接口拼接”——这才是 Unix 命门。今天你用一堆 npm 包堆出来、接口乱成一锅，跟当年 spell 串 sort/grep 根本不是一回事：前者堆料，后者编排。
零依赖和借力不是二选一。靠谱到能当基础设施的，直接上；命门卡你脖子的，自己写几十行反而踏实。看它稳不稳，别看它内外部。其实
btw 我那个坑最后自己写了 30 行替换，省心到现在。