该用panic时是程序遇无法恢复的致命状态需紧急终止，如初始化失败；不该用时是凡能返回error让调用方处理的场景，如用户输入校验、HTTP handler中错误。
什么时候该用 panic，什么时候不该用
panic 不是错误处理机制，而是程序遇到无法恢复的致命状态时的紧急终止手段。比如初始化阶段读不到必需配置文件、数据库连接池构建失败、TLS 证书加载异常等——这些场景下继续运行只会让后续逻辑更不可靠。但凡能通过返回错误（error）让调用方决定是否重试、降级或记录日志的，就不该用 panic。
常见误用包括：在 HTTP handler 中对用户输入校验失败就 panic；对第三方 API 返回的 404 状态直接 panic；甚至把 fmt.Sprintf 的格式错误也包进 panic。这些都会导致整个 goroutine 崩溃，且无法被上层统一捕获（recover 在非主 goroutine 中极难可靠使用）。
用 error 替代 panic 的典型模式
Go 的标准库几乎全部采用显式错误返回，这是有明确设计意图的：把控制权交还给调用者。你写的函数也应如此，尤其是以下几类：
- 输入参数校验失败 → 返回
fmt.Errorf("invalid %s: %v", field, value) - I/O 操作（文件、网络、数据库）→ 直接透传底层
error，必要时用errors.Wrap或fmt.Errorf("%w", err)补充上下文 - 业务规则不满足（如余额不足、权限不够）→ 定义自定义 error 类型，实现
Is方法便于判断，例如：var ErrInsufficientBalance = errors.New("insufficient balance") - JSON 解析失败 → 用
json.Unmarshal返回的error，而不是先panic再写recover
注意：不要为了“省一行 if err != nil”而封装一个自动 panic 的工具函数——这等于把错误处理责任悄悄上移，最终往往落到 HTTP handler 或 main 函数里，反而更难定位问题源头。
立即学习“go语言免费学习笔记（深入）”；
哪些地方真需要 panic？如何安全使用
真正合理使用 panic 的场景极少，且必须满足两个条件：1）当前函数完全无法继续执行；2）调用方本就不该（也无法）处理这种错误。典型例子：
- 初始化函数中，
flag.Parse()后发现关键 flag 未设置 →panic("missing required flag -config") - 全局单例（如 logger、DB）在
init()中构建失败 →panic(fmt.Sprintf("failed to init DB: %v", err)) - 断言失败且属于开发阶段逻辑错误，比如：
v, ok := interface{}(x).(MyType); if !ok { panic("x must be MyType") }（仅限内部断言，非用户输入）
关键约束：绝不在导出函数（public function）中主动 panic；不在 goroutine 中随意 panic（除非你确定它会被 recover 且不会泄露资源）；所有 panic 都应附带可读的字符串说明，避免只传 err 对象（因为堆栈已丢失原始上下文）。
替代 panic 的实用工具与惯用法
很多看似“不得不 panic”的场景，其实有更可控的替代方式：
- 空指针访问风险 → 用结构体嵌入或接口约束代替裸指针，例如定义
type Service interface { Do() error }，而非暴露*http.Client - 数组越界 → 用
slice而非数组，配合len()和边界检查；或使用container/list、map等动态容器 - 类型断言失败 → 优先用
switch v := x.(type)多分支处理，或提前用reflect.TypeOf做白名单校验 - 需要快速失败又不想崩溃 → 实现一个轻量级断路器（circuit breaker），或用
log.Fatal终止进程（比panic更明确，且不触发 defer）
最常被忽略的一点：panic 不会释放 defer 中的资源（比如未关闭的文件句柄、未 unlock 的 mutex），而正常错误返回可以保证 defer 执行。这点在长生命周期服务中尤其关键——一次误用 panic 可能导致连接泄漏或死锁。
