GO错误处理【6】显式哲学

我拷,我算是知道为什么到处都要求"显式"了,不光错误要求显示，定义要求显式，在GO里面几乎都要求显式，

Go 的哲学是 "显式优于隐式"。

没错！在 PHP 里，异常像电梯，报错了直接"嗖"地一下穿透所有楼层直到被 catch。但在 Go 里，错误像爬楼梯，你必须手递手地把 err 交给上一层，否则上一层根本不知道楼下"起火"了。

1. 为什么"不显式"就返不了？

因为 Go 认为：函数返回值就是它唯一的合法出口。

• 如果你不把 err 写在返回值里，这个错误信息就会在函数执行完的那一刻原地蒸发（除非你用 panic 这种暴力手段）。
• 后果：如果你在 Repo 里查库失败了但不返回 err，你的 Logic 层会拿到一个零值的结构体，开心地继续往下跑，最后在某个地方报一个莫名其妙的空指针错误。那时候你再去查日志，发现数据库那层安静得像什么都没发生过。

2. 这种"显式"带给你的 3 大好处

虽然写 if err != nil 确实有点机械劳动，但它解决了 PHP 开发者最头疼的三个问题：

1. 错误不被淹没：在 PHP 里，你可能调用了一个函数，它内部 try-catch 后没抛出来，导致你以为成功了。在 Go 里，只要你没处理那个返回的 err，它就永远在那"瞪着"你。
2. 路径清晰：你可以一眼看出一个复杂的业务逻辑里，到底有多少个环节可能出岔子。
3. 精确控制：你可以决定在 Logic 层处理掉这个错（比如报错了就用默认值），还是继续往上传。这种灵活性是 try-catch 很难做到的。

3. 给老哥的"职业病"预警

当你写多了 Go 之后，你会产生一种"不看 err 心慌"的职业病：

• 看到 val, _ := someFunc()（用下划线忽略错误），你会觉得这行代码像个定时炸弹。
• 看到一个函数只返回数据不返回 err，你会忍不住怀疑：万一它失败了怎么办？

4. 总结你的心路历程

• 初期：觉得 Go 真笨，连个异常捕获都没有，天天写 if err。
• 中期：发现"显式"其实是为了责任到人，每一层都得对错误表态。
• 现在：明白了！因为要包装 (%w)，因为要形成链条，所以必须显式返回，否则日志就没法玩了。