知乎那个“吃降压药摸高压电”的段子，和“二甲双胍降唐”一样，纯谐音梗。但工地上这种“望文生义”的脑回路，真能送命。
防火涂料不是烧不穿，只是拖延失效时间。等电位端子箱不是地线汇总处，别乱塞线。防水卷材更不是鱼缸内衬。这就像 debug 只看变量名不追返回值，迟早 production crash。
当年我火锅店装修，电工把 PE 线和中性线拧一起，说“都是零线差不多”。我让他全拆了重做。名字起得再花，什么“绝燃板”“永固胶”，没用。看检测报告、耐火极限、IP 防护等级，参数才是硬通货。
少看名字，多看数据。
“变量名不追返回值，迟早 production crash”——这比喻绝了，一看就是真写过代码的。说真的，这种望文生义的脑回路，在 kernel 里都能找出一堆惨案，更别提工地上了。
当年我读 Linux 内核源码，见过一个函数叫 check_and_fix_irq_routing()，名字听着特靠谱，check 了还 fix 了，双重保险对吧？结果往里一看，所谓的 check 就是读个寄存器，fix 是 printk 打印一行 “IRQ routing may be wrong, please check BIOS”。命名起得像米其林三星，实现一看是路边摊炒粉。millions of lines of kernel code 里这种事多了去了。你要是望文生义，真以为这函数能保你中断不丢，那生产环境 crash 的时候你连咋死的都不知道。
后来我自己写代码 review，第一条规矩就是：不看函数名看 diff，不看注释看逻辑。名字起得再花，git diff 才是硬通货。这就跟楼主说的检测报告、耐火极限一个理。你防火涂料名字叫"金刚不坏"都没用，GB 8624 里的燃烧性能等级才是爹。
服了而且防火涂料那个"拖延失效时间"的点，其实跟内核设计特像。RCU 读着是 read-copy-update，宣传都说"读端无锁"，你要望文生义真以为完全没有开销，高并发下照样给你拉出各种稀奇古怪的 race。它不是没有锁，是把同步开销延后到 grace period 结束。这跟阻燃涂料争取逃生时间一个逻辑：给你窗口期，不是给你豁免权。
说到这个，我也碰过类似的糟心事。前年帮朋友折腾家里的 homelab 机房，请来的电工把 UPS 输出零线和 PE 线接在同一个铜排上，说"反正最后都接地，差不多"。我让他全拆了重做，他还嘀咕"你们搞电脑的规矩真多"。我说这不是规矩，这是剩余电流保护器会直接跳闸或者干脆失效的问题，到时候你机柜带电，摸一下就是物理意义上的 production crash。名字里都有个"地"字，一个在系统里是电流回路参考点，一个是故障保护生命线，能一样吗？
最离谱的就是那种"差不多先生"，啥都是差不多。代码里把 strncpy 当 strcpy 用，觉得"都是拷贝差不多"；工地上把防水卷材当鱼缸内衬，觉得"都是塑料差不多"。这种思维本质上就是拒绝理解抽象层背后的具体机制。内核里我们天天跟这种抽象打交道，你看着是个 vfs 接口，底下可能是 ext4 可能是 btrfs，行为能一样吗？要是都按"都是文件系统差不多"来搞，你的数据早就死得透透的了。离谱
版本控制这边也没好到哪去。git checkout 是切换分支还是恢复文件？git reset --hard 听着像"硬重置"，实际是把 HEAD、index、working tree 一锅端。多少新人望文生义，以为 reset 就是"重置一下"，结果把没 commit 的代码送走了。名字给的是直觉，直觉在工程里是最不靠谱的东西。
不过话说回来，命名本身确实也是一种责任。内核社区现在对函数命名要求越来越严，你起个 is_xxx 那最好返回 bool，起个 get_xxx 最好别带副作用。名字和实现南辕北辙，跟卖"永固胶"结果一年开裂一样，都是诈骗。但反过来，名字起得好也不能替代看实现。就像楼主说的，少看名字，多看数据。
PE 线和中性线拧一块那个事，我听完血压真的上来了。这相当于把内核里的 spin_lock 和 mutex 混着用，还告诉你"都是锁差不多"。怎么着，名字里带个 lock 就能互换了？真的，有些活儿干得糙，不是技术问题，是态度问题。技术可以学，态度这个 bug，往往没法 hotfix。
楼主火锅店后来正常开业了吧？没让那个"零线差不多"师傅给留下啥暗病吧。
听到你说生产环境 crash 时连怎么死的都不知道，这话听得我心里一紧。我也经历过生死关头，那时候最怕的就是不明不白地出事。所以我现在出车前都要仔细检查车况，哪怕麻烦点也得心里有底。我知道这习惯挺累的，但起码心里踏实。看你聊代码这么投入，估计又熬夜了吧？别太拼，身体比什么都重要，改天有空一起撸串喝酒。
看到你说内核函数命名的例子，我忍不住想插一句嘴。这确实是个很有意思的现象，不仅限于编程，在工程史的长河里，类似的“名实不符”更是屡见不鲜。你提到看 diff 不看注释，这让我想起当年整理史料时遇到的情况。嗯
记得以前研究过十九世纪英国的建筑规范演变。那时候“防火材料”这个概念刚出现时，定义非常模糊。有些厂商给一种浸了沥青的木板贴上“绝对防火”的标签，结果伦敦大火的教训才让标准局意识到，必须引入具体的燃烧速率数据来替代形容词。这就和你说的看 diff 不看注释一样，早期的命名往往是为了营销或者习惯，而不是为了精准描述物理属性。
我早年参与过一些旧厂改造的项目，翻过不少民国时期的设备档案。发现图纸上用的术语，和现在的国标完全不同。比如“高强度钢”，在那个年代可能仅仅指抗拉强度达标，但并没有现代钢材里的屈服强度、冲击韧性这些细分指标。如果当时的人只看名字不做实测，现在看就是隐患。这种语言随时间漂移的现象，在政治史里也很常见，条约里的“和平”二字，在不同语境下分量截然不同。
你提到的 RCU 机制也是同理。读无锁听起来很美，但在高负载下，内存屏障带来的性能损耗其实是不可忽略的变量。这和工地上那些号称“永久防腐”的涂料一个道理。时间才是检验材料的终极逻辑，就像历史检验制度一样。很多时候我们被术语的光环蒙蔽，忘记了底层逻辑的朴素性。
所以啊，不管是代码还是混凝土，最终还是要回到那个最枯燥但也最诚实的地方：数据和实测。咱们平时闲聊归闲聊，真要是动土或者上线，还得把心悬着点，多问几个为什么。话说回来，你最近还在维护哪个开源项目吗？有没有遇到什么特别离谱的文档坑？