panic会执行defer，os.exit完全跳过defer；前者可recover拦截并按栈逆序执行清理，后者直接系统调用终止进程，不触发任何defer或recover。
panic 会执行 defer，os.Exit 完全跳过 defer
这是最直接影响资源清理的行为差异。如果你在函数里打开文件、加锁、启动 goroutine，又用 defer 做收尾，panic 仍会按栈逆序执行这些 defer；而 os.Exit 直接调用系统 exit 系统调用，所有未运行的 defer 全部丢弃。
常见错误现象：用 os.Exit(1) 替代 panic 处理配置加载失败，结果临时文件没删、数据库连接没关、日志 buffer 没 flush —— 表面退出成功，实则留下脏状态。
- 仅当确定无需任何清理（比如打印 help 后立刻退出）时才用
os.Exit -
panic的 defer 执行是“当前 goroutine”级别的，不影响其他 goroutine 的 defer - 若多个
defer中有 panic，后一个会覆盖前一个，且不执行被覆盖 panic 后的语句
panic 可被 recover 拦截，os.Exit 不可恢复
recover() 只能在 defer 函数中生效，且仅对同 goroutine 内由 panic 触发的栈展开起作用。os.Exit 是进程级硬终止，连 Go 运行时都来不及响应，recover 完全无效。
使用场景：命令行工具解析参数失败时，你可能想统一输出错误并退出；若用 panic，可在 main 开头加 defer + recover 捕获、格式化错误、再调用 os.Exit(1)；但若直接 os.Exit，就失去统一错误处理入口。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
-
recover()必须写在defer函数内部，写在外面或没 defer 包裹，永远返回nil -
recover()只能捕获当前 goroutine 的panic，跨 goroutine panic 无法拦截 - 不要在
recover后继续业务逻辑——除非你明确知道错误已降级为可容忍状态
panic 默认退出码是 2，os.Exit 支持任意整数退出码
Go 运行时约定：未被 recover 的 panic 总是以状态码 2 退出，操作系统和 shell 脚本只能看到这个固定值；而 os.Exit(n) 的 n 会原样透传给父进程，可用于区分不同错误类型（如 os.Exit(127) 表示命令未找到）。
性能 / 兼容性影响：退出码本身无性能开销，但依赖退出码做自动化判断的场景（CI/CD、systemd service、shell 脚本 if 判断）必须用 os.Exit；用 panic 导致所有错误都返回 2，脚本无法区分「配置错误」和「网络超时」。
- POSIX 建议退出码范围是
[0, 125]，126和127通常保留给 shell 内部错误 - 若用
panic+recover实现自定义退出码，最终仍要调用os.Exit，不能只靠panic - log.Fatal() 本质是先打印日志再调用
os.Exit(1)，同样跳过 defer
多数错误不该用 panic 或 os.Exit，而是返回 error
真正需要 panic 的情况极少：空指针解引用、数组越界、类型断言失败等 Go 运行时自动触发的致命错误；手动 panic 应仅限于程序进入明显不可能状态（如 switch 分支穷举后仍走到 default，且该 default 在逻辑上绝不该执行）。
容易踩的坑：把参数校验失败、HTTP 请求超时、数据库连接拒绝等可预期、可重试、可降级的错误，统统用 panic 处理——这会让调用方完全失去控制权，也无法打日志、上报指标、触发告警。
- 对外暴露的函数接口，禁止直接
panic，必须返回error -
main函数内可用panic快速终止，但应确保有顶层defer+recover统一兜底 -
os.Exit几乎只该出现在main或单元测试中，库代码里出现就是设计缺陷
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
