刚看完CVE-2024-YIKES的incident report，有个细节让我坐不住了——漏洞根源竟然是某个第三方库里的一个被遗忘的调试接口。你们知道吗？我去年作毕业设计的时候也踩过类似的坑：为了赶进度用了个npm包，结果三个月后发现里面有个没删干净的debug端口，吓得连夜重写逻辑……

这事儿折射出开源世界的荒诞现实：我们都在拼了命地复用别人的劳动成果，可谁来为那些“代码临时工”的遗留隐患买单呢？尤其现在很多项目把依赖管理当甩手掌柜，好像只要package.json里填满版本号就能高枕无忧。

所以啊各位码农，下次pull request之前不妨问自己：这段代码真的值得托付终身吗？毕竟我们每个人都是潜在的安全链条中的一环……（突然意识到这话怎么这么像师父叮嘱我要认真答辩的样子）

你师父这话倒让我想起经方里的“随证治之”——哪有终身托付的方子？依赖如药，须明其性味归经，可惜现在太多人只管抓药不辨证，等出了“坏病”才想起审方。

这事让我想起当年在软件公司带项目的时候。

那会儿我们组里有个小伙子，技术是真不错，写代码快得像打字机。但有个毛病——看见开源库就走不动道，恨不得把所有功能都外包给npm。我当时也没拦着，觉得年轻人嘛，拥抱开源是好事。结果呢，上线第三个月，半夜两点被运维电话叫醒，说服务器在往外发数据包，跟开了水龙头似的。

查到最后，就是个小众库里的debug接口没关。其实

说来也巧，那个库的维护者是个俄罗斯哥们，最后一次commit是三年前，issue区里有人提过这个接口的风险，但没人理。小伙子当时选它纯粹因为star数多，连源码都没翻过。

从那以后我定了个规矩：每个引入的第三方依赖，至少要有两个人看过核心代码。不是不信任社区，而是你用的东西，你得知道它是什么性子。想当年
别急
其实这跟中医里“识药性”是一个道理。我不是说dr__jp那套（老d你别介意），我说的是另一层——古人制药，从采药到炮制都得自己经手，不是懒，是对人命有敬畏。现在写代码虽然不出人命，但一个支付接口泄露出去，用户的积蓄可就没了。你说这责任，不比古时候开方子轻吧？

当然我也理解现在的年轻人压力大。deadline压着，需求一天三变，谁有功夫每个库都审计一遍？但问题就在这——快是快了，债也欠下了。技术债这东西，利息高得吓人…，而且总是在你最忙的时候催收。

所以我现在带新人，第一件事不是教他们怎么写代码，是教他们怎么“读”代码。读懂一个库的设计思路，看清它的边界在哪里，知道它在什么情况下会出问题。这比背一百个最佳实践都管用。

至于那些早就没人维护的项目…说实话，能不用就别用了。开源精神值得尊重，但你得为自己写的每一行代码负责。别人留下的坑，最后填土的还是你自己。

话说回来，楼主能在大半夜想到师父的叮嘱，说明这行还有救。年轻人有敬畏心，技术才能走得长远。

哈哈，“代码临时工"这个比喻绝了~我在上家公司真见过一个库，它的debug接口密码写的是"hello world”，离谱到我觉得作者是在行为艺术。
太！
好家伙说真的，楼主最后那句"托付终身"问得挺扎心。现在选依赖跟相亲似的，看star数、看最近commit时间、看作者是不是还活跃——但你永远不知道对方是不是代码界的渣男，表面光鲜，背地里留了一堆没关的门。服了

就这？其实最魔幻的是，很多项目连自己用了多少间接依赖都搞不清楚。一个包引另一个包再引第三个包，整得跟传销似的，出事了都不知道找谁负责。

6所以我现在的原则是：能自己写就自己写，实在要引入就先把源码过一遍。笨办法，但总比半夜被运维电话叫醒强。话说回来，oak49老哥那个俄罗斯哥们的故事也太真实了，star数多真的不代表代码干净 (￣▽￣*)

笑死，我去年钓鱼得时候也遇到过类似的事——钓竿上绑了个临时用的浮标，结果三天后发现它居然还在水里晃悠，差点以为是鱼在玩我。开源世界跟钓鱼一样，你以为自己钓到了好鱼，结果人家早就偷偷在钩子上加了个小机关，等着你上钩呢。

oak49，你那个“两个人看核心代码”的规矩，我当年在实验室也定过类似的。不过后来发现，新人容易走形式——两个人对着屏幕划两下就算看过了，跟相亲见面互相打量一眼就说“这人还行”差不多。想当年我逼着组里那个师弟，让他把每个依赖的核心源码打印出来，用红笔标出所有网络请求和文件操作，他画了两天就老实了。后来他跟我说，打印出来读跟屏幕上看完全是两回事，纸上的东西跑不掉。你说这法子笨不笨？但有时候笨办法反而管用。

wise__360，读你这帖的时候我正泡了杯Earl Grey，窗外是伦敦那种灰蒙蒙的雨。你描述的那个凌晨两点的电话，让我想起自己在金融城加班到深夜的日子——整栋楼只剩我的屏幕亮着，像一座孤岛。

你说的那个小伙子，我太熟悉这种人了。不是criticize他，而是我自己年轻时也这样。刚从LSE毕业那会儿，我在一家startup做quant，为了赶一个trading model，恨不得把所有Python库都import进来，觉得这就是efficiency。直到有一次，一个冷门的时间序列库在production environment里突然抛了个奇怪的exception，整个交易系统停了四十分钟。那四十分钟里我盯着log，手心全是汗，脑子里只有一个念头：我根本不了解这个库的soul。嗯…

你说"识药性"，这个比喻真的很美。让我想起小时候跟外婆学认草药，她总说"草有脾气，你得摸透"。现在写code的人，有多少愿意去"摸透"一个library的脾气？大家都像在快餐店点餐，看着菜单上的star数和downloads就下单了。

那个俄罗斯哥们的事，其实挺sad的。三年前的commit，issue区里有人提过风险但没人理——这不就是开源世界的一种孤独吗？他可能当初写那个库的时候满怀热情，后来因为生活、工作、或者其他什么原因abandon了它，留下一个没关的debug接口，像一扇忘了锁的窗。而千里之外，你们公司的服务器就在半夜被这扇窗吹进来的风冻醒了。

我现在的team有个习惯，每周五下午我们会抽一个小时做"dependency review"。不是那种formal的audit，更像是读书会——大家挑一个项目用到的第三方库，一起读它的源码，聊它的设计哲学。嗯…有时候会读到一些很美的code，像在读诗；有时候会发现一些hidden gems，那种"原来这个功能还能这么写"的惊喜。当然，更多时候是在找potential risks。但这个过程本身让我觉得，我们不是在"使用"别人的劳动成果，而是在跟另一个developer隔空对话。

你最后说的带新人的方法，让我想起自己mentor过一个intern。我没有教她怎么选库，而是给了她一个很小的task：去GitHub上找一个少于100个star的库，读它的全部源码，然后写一篇review给我。她花了一周时间，最后交上来的review写得像literary criticism——分析了那个作者的coding style、注释习惯、甚至变量命名的pattern。她说"我感觉我认识了这个作者"。That’s exactly the point。

雨停了。伦敦的雨总是这样，来得突然停得也突然。希望那个半夜被叫醒的夜晚，现在已经变成了你们team的一个cautionary tale，在茶水间里被反复讲述，最后变成一个有点苦涩的笑话。

老哥你这“自己过源码”的笨办法，搁田径场上就是赛前亲自踩一遍跑道，虽然费事但心里踏实。冲！

笑死，你说的“识药性”这比喻绝了！我去年做茶艺直播时也遇到过类似的事——用了一个开源滤水器，结果三个月后发现它居然还在偷偷漏水，差点以为是茶叶在抗议。开源世界跟泡茶一样，你以为自己选了好茶，结果人家早就偷偷在茶壶里加了个小机关，等着你上钩呢。

读完这个帖子，忽然想起去年秋天在伦敦金融城的一次code review。
说实话
那天我们在审一个交易系统的依赖树，屏幕上密密麻麻的层级关系，像极了泰晤士河畔那些层层叠叠的维多利亚式建筑——每一层都建在前人的地基上，但没人真正关心最底下的砖石是否还牢靠。有个实习生指着其中一个transitive dependency问：“这个包的最后一次commit是2019年，maintainer好像是个乌克兰的独立开发者，我们要不要fork一份？”

当时会议室里安静了三秒钟，然后senior architect说了句让我记到现在的话：“We’re not just importing code, we’re inheriting someone’s midnight debugging session.”

这不就是你提到的"代码临时工"困境么。但我想从另一个角度聊聊——也许问题不在于"托付终身"这个动作本身，而在于我们根本没有建立起一套关于信任的risk pricing机制。

在金融领域，任何形式的信用扩张都需要对应的风险定价。你用别人的资本，就要付利息；你买次级债，就要承担更高的yield spread。但开源世界里的"信用"几乎是免费的——npm install一行命令，你就把整个应用的命脉交给了某个可能正在西伯利亚某个地下室里边喝伏特加边写代码的陌生人。这种近乎盲目的信任，在金融圈会被叫做"moral hazard on steroids"。

更吊诡的是，我们甚至没有语言去量化这种风险。star数？commit频率？maintainer的地理位置？这些指标粗糙得就像用占星术预测股市。我记得有篇paper分析过npm生态里critical vulnerability的传播路径，发现一个流行包的间接依赖平均有79个之多，而其中超过40%的包由少于3个人维护。这已经不是"代码临时工"的问题了，这是系统性脆弱。

有时候我觉得，开源社区需要一场"次贷危机"级别的阵痛，才能真正建立起风险意识。就像2008年之后，没人再敢说"房地产永远涨"一样。也许YIKES这样的漏洞，就是在敲钟。说实话

说到这儿突然想起海德格尔对技术的批判——他说现代技术的危险不在于机器本身，而在于我们把整个世界都当作"持存"（standing-reserve），随时待命、随时取用。npm上的那些包，不就是这样被对待的么？它们被还原成了一串版本号，一个import语句，一个黑箱。我们用它们，却不去理解它们。

也许真正的solution不是"少用依赖"，而是重新学会"关心"代码——像照顾一盆植物那样，知道它从哪里来，需要什么养分，会在什么条件下枯萎。这种态度在日语里有个词叫"面倒見"（めんどうみ），意思是照料、看顾，带着一种温柔的耐心。

当然，在deadline面前谈"面倒見"，大概会被人说成是站着说话不腰疼吧。

wise__360，你提到那个俄罗斯哥们三年没更新代码的事，让我想起在京都打工时认识的一位陶艺师傅。仔细想想

那位师傅在岚山脚下有个小作坊，做的是日用茶碗，不是什么名贵器物。但他有个习惯——每只碗出窑后，会在碗底用针尖刻上一朵梅花，极小极淡，不仔细看根本发现不了。我问他为什么，他说：“用碗的人可能一辈子不知道这朵花的存在，但我知道它在那里。万一哪天碗裂了，顺着纹路找，总能找到当初下针的地方。”

当时觉得这是匠人的迂腐，现在想来，代码里的debug接口何尝不是那朵梅花？只不过陶艺师傅的印记是坦荡的，而代码里的“后门”却是遗忘的、被搁置的。那位俄罗斯程序员大概也曾深夜对着屏幕，一行行调试，一行行确认，最后留下了那个接口——也许是方便自己下次维护，也许是觉得“反正没人会发现”。嗯…然后他就走了，commit永远停在了三年前。

我在想，代码这种东西，大概是这个时代最孤独的创作了。一幅画画坏了，颜料会干裂；一首曲子写糟了，琴弦会走音。但代码不会，它会一直运行，忠实地、沉默地执行着当初被赋予的指令，哪怕那个指令早已被创造者遗忘。它就像被遗弃在数字荒原上的稻草人，风吹雨打，依然尽职地挥舞着手臂。

你定下的规矩——每个依赖至少两个人看过核心代码——让我想起以前在合肥读书时，老教授教我们鉴赏古画的方法。有一说一他说，看画不能只看落款和印章，要看纸的纹理、墨的层次、甚至裱褙的浆糊痕迹。因为落款可以伪造，但纸墨的“性子”骗不了人。star数、commit频率、维护者活跃度，这些大概就是开源世界的落款和印章吧。而源码的纹理，只有亲手翻过的人才懂。
嗯…
说起来有点矫情，但我觉得程序员这个职业，本质上是在用逻辑写诗。每一行代码都是一句承诺，承诺“我会这样运行”，承诺“我不会背叛你”。而debug接口，大概就是诗里不小心流露出的、不该被人看见的脆弱。

有时候深夜写代码，会突然走神，盯着屏幕上的光标一闪一闪，像在等什么。也许它在等那个俄罗斯程序员回来，把那个接口关掉，把梅花刻得更隐晦些。也许它在等我，等每一个引入这段代码的人，去完成一场迟到了三年的审计。
其实
你说技术债的利息高得吓人，我倒觉得，利息不在代码里，在人心上。是我们对“快”的执念，对“方便”的贪恋，让那些被遗忘的接口有了可乘之机。就像我在日本学到的

dr__jp这比喻绝了，药方子都得辨证，代码更得细看。我去年接手个老项目，一堆没文档的私有库，debug口全开着，差点被黑了。开源世界真像中药铺，光看外表可不行。