看到银杏“独占一门”的生物学谣言被澄清，联想到技术圈类似现象。比如“过早优化是万恶之源”常被简化为“别碰优化”，实则Knuth原话强调“需基于性能剖析”；又如“微服务必优于单体”，却忽略团队规模与业务耦合度——我曾见某项目盲目拆分，反而拖慢迭代。这类误区多源于经验碎片化传播。建议遇“祖传结论”时多问：原始出处？适用边界？数据佐证？毕竟工程决策需具体问题具体分析。你踩过哪些“常识”坑？(笑)

刚在厨房切洋葱时想到个例子——“不要重复造轮子”这句，害了多少人硬塞不适合的依赖进去。我在曼谷有次帮朋友搭点餐系统，他非要用某个“工业级”ORM，结果就三个表，查询还绕过模型直接写raw SQL，build time 涨了四倍，CI 经常 timeout。后来换成 sqlx + 手写 query，代码少一半，连泰国本地小餐馆老板都能看懂逻辑。

这其实和 Knuth 那句被断章取义的情况同源：原意是“别在没测量前瞎猜瓶颈”，不是“永远别优化”。但很多人把“经验法则”当戒律，忘了工程是 trade-off 的艺术。微服务那块我也踩过雷——早年在唐人街后厨打工时，厨师长总说“分工越细效率越高”，结果酱料、切配、炒锅各搞一套标准，出错率反而飙升。后来我们改成“核心流程集中，边缘模块解耦”，才稳下来。软件也一样：团队不到十人就拆十几个 service，光维护部署流水线就能耗掉 sprint 一半时间。

现在我写 Rust 项目，先问三个问题：

1. 这个抽象是否真的消除重复？还是只是转移复杂度？
2. 如果明天没人维护，新人能否半小时内跑起来？
3. 性能关键路径在哪？（用 perf 或 flamegraph 看，别猜）

见过最离谱的是有人拿“YAGNI”当挡箭牌，连基础监控都不加，线上崩了才手忙脚乱补日志。YAGNI 是说别提前实现用不到的功能，不是别做可观测性——这两者根本不在一个维度。

话说回来，你提到“数据佐证”，这点特别关键。最近在试用一个新数据库，文档吹得天花乱坠，但我先跑了个 TPC-C 子集 benchmark，结果并发一高 latency 直接翻十倍。厂商回复说“默认配置没调优”，但生产环境哪有精力每换一个组件就 deep dive tuning？所以现在选型原则很简单：开箱即用的 baseline 性能不能低于预期 70%，否则再 fancy 的 feature 也 pass。

你有没有遇到那种“大家都说好，但你一用就水土不服”的技术？比如我至今搞不懂为啥还有人坚持用 XML 做配置……

看到你在厨房那段笑死，简直跟我上次在组里碰到的事儿一样，不过那个 ORM 案例让我想到另一个雷区——“代码即文档”。这玩意儿坑人程度不亚于那个建个三个表还要上工业级 ORM 的操作。

以前有个同事，洁癖晚期，变量名写得像诗歌，什么 dataProcessorStrategyFactory，结果逻辑绕了十八弯。问他就是"Clean Code 原则"，代码应该自解释。后来他休假，服务器崩了，我们对着那些"诗歌"debug 到凌晨三点，最后发现就是个空指针。说真的，很多时候"最佳实践"成了偷懒的借口。不写注释不是因为代码好，是因为懒得维护文档。

我現在写代码，宁愿留点通俗的注释，也不搞那些抽象艺术。毕竟半夜 on call 的时候，没人有心情赏析代码美学。就像你提到的那个泰国餐馆老板，逻辑能让人看懂才是王道，管你用的是不是"工业级"方案。有时候一点点的"脏"注释能救命，比什么抽象工厂都强。

话说回来，你那个 sqlx 方案后来稳定吗？我也在考虑把项目里的 ORM 剔了，怕动太大被老板骂，毕竟在他们眼里，重构等于没干活。有时候觉得咱们这行挺离谱的，明明是为了解决问题，最后花大半时间在解决"解决方案"带来的问题。

对了，下次聊点别的，最近收了一张 Chet Baker 的黑胶，音质绝了，改天推荐给你。代码写累了还是得听点蓝调续命，不然真要被这些"常识"气出内伤。你平时调试的时候听什么？

rustist兄提到“洋葱切到流泪时顿悟工程之道”，这画面倒让我心头一颤——厨房里的烟火气，竟与代码世界的混沌如此相通。你讲唐人街后厨分工过细反致混乱，我忽然想起十年前在成都一家苍蝇馆子帮厨的经历：老板坚持“每道菜必须用专属锅铲”，结果灶台上堆满铁器，炒回锅肉的师傅常错拿煮汤的漏勺，油星四溅，客人大笑。后来索性只留三把锅铲，按火候分粗、中、细，反倒行云流水。这不正似软件架构？抽象若不能化繁为简，便成了枷锁。

你说“新人能否半小时跑起来”，这话如钟声撞我心坎。前年带一个实习生重构旧系统，他执意引入一套时髦的依赖注入框架，美其名曰“解耦”。结果本地启动要配五层YAML，连数据库连接池都藏在三层嵌套的trait里。某夜线上告警，我俩对着满屏泛型参数枯坐到天明，窗外玉兰花开得正好，代码却如迷宫般拒人千里。后来删掉八成“优雅”设计，直接new对象、硬编码路径，反而清爽如溪。那一刻才懂：所谓简洁，不是少写几行，而是让逻辑如月光般直照人心。

你提到YAGNI被误作懒政借口，深有同感。见过有人连错误码都不统一，说“反正现在没国际化需求”，结果半年后海外用户暴增，日志里混着中文、拼音缩写和emoji报错，运维同事差点提刀上门。可观测性从来不是“未来功能”，而是系统的呼吸孔——没有它，再健壮的躯体也会窒息于无声。

不过我倒想问一句：当我们在厨房或机房里反复试错时，是否也该容许自己保留一点“无用之美”？比如那套被弃用的ORM，或许笨重，但它曾让初学者免于SQL注入的深渊；那些冗余的微服务边界，也许拖慢了迭代，却意外培养了团队对分布式事务的敬畏。工程之艺，未必全在效率与清晰之间，有时也在那些看似弯路的泥泞里，藏着下一次飞跃的种子。

对了，你后来在曼谷那家餐馆，老板看懂代码时，可曾请你喝了一杯冰镇椰青？