Go语言中不推荐滥用panic，因其用于不可恢复的严重错误，如空指针、越界等，而常规错误应通过返回error处理，以保障程序健壮性、可维护性和可测试性。
在Go语言中，不推荐使用全局panic作为常规错误处理手段，这直接关系到程序的健壮性。核心在于，panic代表的是“不应该发生”的致命缺陷，而健壮的程序应该能预见并妥善处理各种可恢复的错误。
panic适用于不可恢复的严重错误
Go的设计哲学是将error和panic明确区分。error用于表示预期中的、可以被处理的业务逻辑错误，比如文件不存在、网络连接超时等。这些情况程序完全有能力继续运行。而panic则专为那些破坏程序正常流程的严重问题保留，例如：
- 空指针解引用
- 数组或切片越界
- 除数为零
- 向已关闭的channel发送数据
遇到这类问题，程序状态可能已经不一致，强行继续执行风险极高。此时触发panic，让程序在崩溃前有机会通过defer进行资源清理（如关闭文件、释放锁），是一种更安全的选择。
滥用panic会破坏代码的可预测性和可控性
如果在业务逻辑中随意抛出panic，会带来一系列问题：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 调用栈中断：panic会立即停止当前函数的执行，并沿着调用栈向上冒泡，直到被捕获或程序崩溃。这意味着正常的控制流被暴力打断，开发者很难追踪和理解程序的实际执行路径。
- 维护成本高：任何函数都可能成为潜在的panic源头，迫使所有调用方都必须考虑recover的可能性，这极大地增加了代码的复杂度和推理难度。
- 测试困难：单元测试需要模拟各种错误场景。使用error可以轻松地注入特定的错误值进行测试，而测试panic则要繁琐得多，且无法像处理error那样精确控制恢复点。
健壮设计应依赖显式的错误返回
Go推崇通过函数返回error来传递错误信息。这种模式迫使开发者正视每一个潜在的失败点，并做出明确的处理决策（忽略、记录、转换或向上传播）。这种方式让错误处理变得可见、可控且可追溯。
虽然对于深层嵌套的调用链，逐层返回error可能显得冗长，但这正是Go强调清晰性的体现。它避免了隐藏的异常跳转，使得程序的行为更加可靠。对于初始化阶段的致命错误（如配置加载失败），使用panic是可以接受的，因为程序无法在错误配置下安全启动。
基本上就这些。
