go中退出当前函数唯一正统方式是return；os.exit终止整个进程且不执行defer，仅用于不可恢复错误；runtime.goexit退出当前goroutine并执行defer，不终止进程。
Go 里没有 “Exit 函数” 能安全退出当前函数——用 os.Exit 就是杀进程，不是退函数。
为什么 os.Exit 不是函数退出机制
os.Exit 的作用对象是整个进程，不是当前函数。它一调就跳过所有调用栈、忽略所有 defer、不等 goroutine 结束，直接向操作系统交还控制权。
- 你在
handleRequest里调os.Exit(1)，HTTP server 就当场瘫痪，其他正在处理的请求全被丢弃 - 你在测试函数里调
os.Exit，go test进程中断，后续测试用例不跑，覆盖率统计失效 - 你在子 goroutine 里调
os.Exit，整个程序挂掉，不是只退出那个 goroutine
return 才是唯一合法的函数退出方式
Go 的函数控制流设计非常明确：函数结束靠 return，进程终止靠 os.Exit。二者语义不可混用。
-
return会正常执行当前函数内已注册的defer，适合资源清理（如关闭文件、解锁、记录日志） - 多层嵌套时，
return只退一层；想提前跳出深层逻辑，可配合if err != nil { return }或错误包装后向上返回 - 不要封装类似
func exitNow() { os.Exit(1) }的函数来“模拟函数退出”，这会让调用者误判行为边界
真要暴力终止当前 goroutine？用 runtime.Goexit
如果确实需要从任意深度的调用栈里“拔掉”当前 goroutine（比如 worker 超时、任务取消），runtime.Goexit 是唯一正统选择。
-
runtime.Goexit()会执行当前 goroutine 内所有 pending 的defer，然后干净退出该 goroutine - 它不影响其他 goroutine，也不会触发进程退出，和
os.Exit有本质区别 - 注意：
runtime.Goexit不在标准库文档首页显眼位置，需手动 import"runtime"
log.Fatal 看似方便，实为隐式 os.Exit
log.Fatal 和它的变体（log.Fatalf、log.Fatalln）底层都调 os.Exit(1)，行为完全等价。
- 它们适合 main 入口点或初始化失败场景，比如配置加载失败、监听端口被占用
- 绝不该出现在业务 handler、循环体、或任何可能被复用的函数中
- 状态码无法自定义——如果你需要区分“配置缺失”和“数据库连不上”，
log.Fatal就不够用
最容易被忽略的是 defer 的执行时机：你写 os.Exit 前没手动 close 文件或 unlock mutex，就等于把资源锁死在进程里；而 runtime.Goexit 虽然能跑 defer，但它不传播错误，上层无法感知这个 goroutine 是怎么消失的。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
