费曼来信：为什么你家厨房漏水，污水却喷到了顶层观景台？——聊聊 Go 错误分层的哲学

读完 steper 关于 Go 错误处理十年迷思 的感悟，我感觉这不仅仅是在谈代码，而是在聊一种“文明的隔离感”。

为了让你明白为什么“错误分层”比“语法糖”更重要，咱们把系统想象成一座 三层高的摩天大楼。

1. 地下室（Infra 层）：那些冰冷的管道

这里跑的是数据库、缓存、消息队列。 当水管爆了（数据库连接超时），它的原始信号是：“pq: connection refused”。

• 现状：很多程序员习惯直接把这句脏话往上扔。

2. 交通枢纽（Service 层）：负责逻辑的调度

这里住着业务员。他负责开订单、查用户。 如果他收到地下室的脏话，他应该做的是 “翻译”。

• 错误的做法：直接把脏话转发出去。结果就是用户在顶层观景台，莫名其妙被喷了一脸下水道污水。
• 正确的做法：他应该把“connection refused”包装成：“SERVICE_UNAVAILABLE（系统正在维护）”。他给错误贴上了一个 业务标签，并保留了原始细节供日志审计。

3. 顶层观景台（Handler 层）：面向用户的窗口

这里是用户看风景的地方。 观景台的导游（Handler）只需要看标签：

• 如果是“系统维护”，他就温柔地告诉用户：“稍微等会儿，我们在打扫。”
• 如果是“用户不存在”，他就告诉用户：“您找错门了。”

他永远不应该把下水道的结构图（SQL 语句、堆栈信息）展示给游客看。

4. 费曼式的判断：错误是“私有的”，标签是“公有的”

所谓的“架构觉醒”，就是意识到：一个底层的物理故障，不应该直接转化为一个顶层的逻辑灾难。

Go 语言之所以坚持 if err != nil，其实是在强迫你去做那个“交通枢纽”的翻译官。语法糖虽然能让你少敲键盘，但它也容易让你偷懒，跳过那层至关重要的 “语义防火墙”。

带走的启发： 在评估你的代码质量时，别看你用了多少高级语法。 去看看你的 API 响应。 如果你的接口在报错时吐出了数据库字段名或底层驱动的黑话，说明你所在的城市还没有“消防规划”，所有的居民都生活在随时可能爆发的“污水喷涌”风险中。

#Golang #ErrorHandling #SoftwareArchitecture #CleanCode #LayeredArchitecture #FeynmanLearning #智柴后端实验室🎙️