runtime.Goexit() 是唯一能从任意栈深度退出当前 goroutine 的标准方式：它立即终止协程、执行所有 defer，但不可跨 goroutine 调用；context.Context 才是跨 goroutine 协作退出的正确机制。
runtime.Goexit() 是唯一能从任意栈深度退出当前 goroutine 的标准方式
Go 不允许外部强制杀掉 goroutine，runtime.Goexit() 是语言层唯一提供的、能从函数调用链任意位置（比如嵌套 5 层的 parseJSON → validate → checkAuth → loadConfig → panicIfInvalid）立即终止当前 goroutine 的机制。它不跳回上层函数，而是直接交还调度权，并保证所有已注册的 defer 按顺序执行——这是它和裸 return 的关键区别：后者只退出当前函数，而 Goexit() 终止整个协程生命周期。
- 必须在目标 goroutine 内部调用，跨 goroutine 调用无效
- 不会触发 panic，因此不会被外层
recover()捕获 - 调用后该 goroutine 中后续所有代码（包括调用点之后的语句、未执行的循环迭代、未到达的
return）全部失效 - 常见误用：在 defer 中调用
Goexit()—— 这会导致 defer 自身无法完成（死锁风险），应避免
context.Context 是跨 goroutine 协作退出的事实标准
当你需要“通知其他 goroutine 主动退出”，而不是自己单方面终止，context.Context 是唯一可信赖的选择。它不是退出指令，而是退出信号源：goroutine 必须主动监听 ctx.Done() 并响应，否则就等于没接收到通知。
- 永远不要把
context.Background()直接传给长期运行的 goroutine —— 它永远不会关闭，等于放弃控制权 - 必须用
select等待，不能只轮询ctx.Err()（会 CPU 忙等） -
context.WithCancel适合手动触发；context.WithTimeout更适合带超时的 IO 操作（如 HTTP 请求、数据库查询） - 若 goroutine 内部有阻塞系统调用（如
net.Conn.Read），需配合其支持 context 的变体（如http.Client的Do方法），否则 context 无法中断
os.Exit() 是紧急熔断，但会绕过所有清理逻辑
当某个 goroutine 检测到不可恢复错误（如配置加载失败、证书损坏、核心依赖崩溃），需要立刻终止整个进程时，os.Exit() 是最直接的方式。但它不是“退出 goroutine”，而是“杀死整个程序”。
- 调用后，所有 goroutine 立即停止，包括 main；
defer全部不执行，文件未 flush、锁未释放、连接未 close 都会发生 - 退出码非 0（如
os.Exit(1)）是运维排查的第一线索，别总用 0 - 绝不应在测试或常规业务逻辑中使用；仅限 init 阶段致命错误、信号处理中的 SIGTERM 后兜底等极少数场景
- 与
log.Fatal()的区别：后者内部调用os.Exit(1)，但多了一次日志输出；两者都跳过 defer
channel 关闭只适用于生产者-消费者模型的单向退出
用 close(ch) 发送“数据流结束”信号，本质是告诉接收方：“不会再有新值了，你可以收工了”。它不是通用退出机制，只在明确存在发送/接收角色分工时才安全有效。
立即学习“go语言免费学习笔记（深入）”；
- 必须由发送方关闭；接收方关闭会 panic
- 重复关闭同一个 channel 也会 panic
- 接收方应使用
for range ch或val, ok := 判断是否关闭，不能假设读一次就完事 - 不适合需要传递退出原因、支持超时、或多个 goroutine 协同退出的场景 —— 此时请回到
context
真正难的不是选哪个函数，而是判断“谁该负责退出”和“退出前必须做完什么”。比如一个持有数据库连接的 goroutine，用 Goexit() 能保证 defer 关闭连接，但若它正被另一个 goroutine 等待结果，就还得通过 channel 或 context 通知等待方“我退出了，别等了”。退出从来不是单点动作，而是协作契约。
