凌晨两点，代码共享我收到一条陌生人的代码共享消息。对方发来一段Python代码，代码共享注释写着“修复了你的代码共享分页bug，顺带优化了查询效率”。代码共享我盯着屏幕愣了几秒——那是代码共享我白天刚提交的项目，还没公开。代码共享

后来才知道，代码共享他在某个技术社群里看到了我的代码共享代码片段，觉得有问题，代码共享就fork下来改了改。代码共享改完没直接提PR，代码共享而是代码共享先私信告诉我原因：原来的写法在数据量过万时会内存溢出，他换成了生成器逐条处理。代码共享附带的代码共享性能对比图显示，响应时间从1.8秒降到了0.3秒。

这就是代码共享最原始的样子——不是把文件上传到GitHub然后等star，而是让代码脱离作者，自己长脚跑起来。它像一种技术界的“漂流瓶”，你不知道谁会捡到，但捡到的人大概率会往里面塞点新东西再扔回海里。

我见过最极端的例子是某个开源项目。作者因为工作变动停更了两年，期间issue堆积如山，fork数却悄悄涨了四百多。有个陌生人接管了维护工作，没改一行核心逻辑，只把文档重写了一遍，把过时的依赖全部升级。项目活了，原作者后来在commit记录里留言：“这比我自己维护得还好。”

共享的本质是暴露脆弱。把代码摊开，等于承认自己写的不完美——可能漏了边界条件，可能用了过时的API，甚至可能整个架构思路就是错的。但恰恰是这种暴露，让代码有机会被陌生人用完全不同的视角审视。你觉得自己写的排序算法很优雅，人家直接扔来一个基数排序的链接，说“你的场景用这个更快”。这种碰撞带来的提升，比自己闷头优化快得多。

当然也有翻车的时候。有人共享了爬虫代码，结果被拿去爬了不该爬的网站，服务器被反爬策略封了IP；有人共享了加密相关的工具类，第二天就收到邮件说“你这随机数种子不安全，能预测”。这些教训让人明白，共享不是甩锅，你得想清楚代码里有没有埋雷——比如硬编码的密钥、未脱敏的数据库地址、甚至隐含的歧视性逻辑。

去年我在公司内部推行代码评审制度，阻力不小。有人觉得被看代码像被扒光衣服，有人担心自己的“独门技巧”被学走。直到有个老同事分享了一段他十年前写的脚本——用awk处理日志的，几十行，注释比代码还长。他说这脚本救过他的命，但现在已经没人看得懂awk了。大家笑完，突然就理解了共享的另一层意义：代码是活的语言，只有不断被阅读、被修改、被吐槽，它才不至于变成化石。

现在我的工作流里多了个习惯：每次提交代码前，会先自己扮演那个凌晨两点的陌生人，用最挑剔的眼光审一遍。这比任何静态检查工具都管用。因为我知道，迟早会有个睡不着觉的家伙，把我的代码翻个底朝天。与其让他发现漏洞，不如自己先动手。

代码共享到最后，共享的其实是信任——信任陌生人会认真读你的注释，信任即使有人骂你写的是屎山，下一行commit记录里也会有人帮你填坑。这种信任一旦建立，技术社区就活了。像那个凌晨的消息，让我在关电脑前，突然觉得代码这行当，还挺有人情味的。