使用 defer 还是不使用 defer?
这篇讲的是Go语言中defer语句的“爱恨情仇”——从最初赞赏它能简化资源清理代码，到发现其性能开销，再到最终理解其适用边界的全过程。 文章首先展示了defer的魅力：它能让锁的获取与释放成对出现，代码清晰且不易出错，因此在标准库中被广泛使用。然而，性能测试揭示了一个关键事实：使用defer释放锁（70.4 ns/op）比直接调用（19.3 ns/op）慢数倍，多个defer叠加时开销更大。这引出了核心矛盾：defer带来的代码简洁性，是以几十纳秒的性能损耗为代价的。 文章进一步探讨了Go官方对此的优化（如1.8版本的改进），并引用了实际案例（如Prometheus项目）。结论并非一刀切地否定defer，而是提出了务实的平衡点：对于大多数业务代码，defer的便利性远胜于其微小开销；但对于高并发下的“热路径”，通过pprof观察到defer成为瓶颈时，手动管理资源释放则是更优选择。简单说，defer并非免费，但它的代价在绝大多数场景下完全值得。