最可靠的方式是在每次循环迭代中检查 ctx.Done()；若只在循环开头检查一次，则无法及时响应取消信号，违背 context 协作式退出的设计初衷。
用 context.Context 检测取消信号最可靠
死循环本身不危险，危险的是它不响应外部停止请求。Go 官方推荐用 context.Context 实现协作式退出——不是“杀死”goroutine，而是让它自己发现该停了。关键点在于：每次循环迭代中必须主动检查 ctx.Done()，不能只在开头 check 一次。
常见错误是写成这样：
for {
select {
case <-ctx.Done():
return
default:
// 长耗时操作，比如 http.Get 或 time.Sleep(10 * time.Second)
}
}问题在于：如果 http.Get 卡住或 time.Sleep 还没结束，goroutine 就无法进入下一轮 select，也就收不到取消信号。
- 正确做法是把长耗时调用也接入 context，例如用
http.Client{Timeout: ...}或context.WithTimeout包裹 - 对纯计算型循环，用
time.AfterFunc或短间隔time.Sleep（如 10ms）+select配合default分支实现非阻塞轮询 - 永远不要在
select中只留一个case ，否则循环会立即阻塞，失去执行逻辑的机会
chan struct{} 适合简单通知，但要注意关闭时机
当任务逻辑非常轻量、不涉及第三方阻塞调用时，用一个关闭的 chan struct{} 是最直接的退出机制。它的优势是零内存开销、语义清晰，但陷阱在于：必须由发送方关闭 channel，且只能关一次。
立即学习“go语言免费学习笔记（深入）”；
典型误用：
- 多个 goroutine 同时
close(stopCh)→ panic: close of closed channel - 接收方在
select中写了case 却没处理后续逻辑，导致 goroutine 退出后资源未释放 - 用
bool变量代替 channel → 引发竞态，因为没加锁或原子操作
安全写法是：定义 stopCh := make(chan struct{})，启动 goroutine 时传入，外部需要停止时调用 close(stopCh)；goroutine 内部用 select 监听，并在收到信号后做清理再 return。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
别碰 os.Exit() 和 runtime.Goexit() 做“优雅终止”
os.Exit() 会立刻终止整个进程，跳过所有 defer、未完成的 goroutine 和文件 flush，只适用于崩溃兜底或 CLI 工具的硬退出。把它当成“优雅终止”手段是严重误解。
runtime.Goexit() 虽然只退出当前 goroutine，但它会绕过该 goroutine 中所有尚未执行的 defer，破坏资源清理契约。官方文档明确说它“主要用于测试”，生产代码应避免。
真正需要“强制中断”的场景（比如 Cgo 调用卡死、硬件驱动 hang 住），Go 本身不提供安全方案。这时候要么重构为可中断的异步接口，要么靠外部进程信号（SIGTERM）重启服务——而不是在 goroutine 里调个函数就指望它能“安全终止死循环”。
带标签的 break 只在单 goroutine 内有效
有人试图用 break myLoop 从另一个 goroutine 触发退出，这完全无效。Go 的 break 标签作用域仅限于当前函数块，跨 goroutine 无意义。更糟的是，这种写法会让代码看起来“好像能控制”，实则埋下静默失效的坑。
如果你看到类似下面的结构，说明设计已偏离 Go 并发模型：
myLoop:
for {
select {
case <-ctx.Done():
break myLoop // ✅ 有效，但仅限本 goroutine
}
}
// 外部 goroutine 想“触发 break myLoop”？做不到。结论很直白：终止逻辑必须由目标 goroutine 自己完成，通信靠 channel 或 context，控制流不能越界。任何想“远程 break”的尝试，本质都是在对抗 Go 的并发哲学。
