goroutine 无法被外部强制停止，所有“停止”本质都是协作式退出；应使用 context.context 监听 ctx.done() 并配合 select 实现安全退出，这是官方标准做法。
Go 语言中 goroutine 无法被外部强制停止，所有“停止”本质都是协作式退出：你发信号，它自己 clean up 后 return。强行中断会跳过 defer、丢日志、留半开连接，甚至破坏内存安全。
用 context.Context 监听 ctx.Done() 是最稳妥的选择
这是 Go 官方标准做法，尤其适合带超时、嵌套子任务或需跨包传递控制权的场景（比如 HTTP handler 起了个数据库查询 goroutine）。
- 必须用
select监听，不能只轮询 <code>ctx.Err() != nil——否则 busy loop 吃 CPU - 启动 goroutine 时把
ctx作为第一个参数传入，例如worker(ctx)，避免用context.Background()做长期任务（它永远不 cancel） - 用
context.WithTimeout(ctx, 5*time.Second)比WithCancel更安全：防卡死，主流程不会无限 hang - cancel 函数只能由创建 context 的那一方调，别在 goroutine 里
defer cancel()或直接调——会 panic
示例片段：
ctx, cancel := context.WithTimeout(context.Background(), 8*time.Second)
defer cancel()
go worker(ctx)
func worker(ctx context.Context) {
for {
select {
case
<h3>用 <code>channel</code> 发送关闭信号要小心缓冲与关闭时机</h3>
<p>简单场景可用，但容易踩坑：往已关闭 channel 写数据会 panic；不带缓冲 channel 可能阻塞 sender；漏写 <code>default</code> 会让 goroutine 卡住。</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/ai/2570" title="Neeva"><img
src="https://img.php.cn/upload/ai_manual/001/246/273/6971f7f7632e1279.png" alt="Neeva" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/ai/2570" title="Neeva" class="overflowclass">Neeva</a>
<p class="overflowclass">一款AI工具，主要用于Neeva是一款无广告、无跟踪、无偏见的AI搜索引擎，适合需要提升相关任务效率的用户。</p>
</div>
<a rel="nofollow" href="/ai/2570" title="Neeva" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div>
- 推荐用
chan struct{}表示信号，零内存开销，语义清晰 - 如果用带缓冲 channel（如
make(chan bool, 1)），确保只发一次信号，且 receiver 不会因未读而漏收 - 不要用
close(ch)当“通用退出信号”——receiver 必须用select+case 或 <code>range才能感知，if ch != nil无效 - 若 goroutine 启动了子 goroutine 或打开文件，必须在收到信号后显式关掉它们，
channel本身不帮你做清理
sync.WaitGroup 只计数，不通知：必须和信号机制配合使用
WaitGroup 的作用是让 main 等到所有已知 goroutine 自然结束，但它不提供任何“该停了”的能力。单独用 wg.Wait() 会永久 hang 住，如果 goroutine 没响应退出信号。
- 先发退出信号（via context 或 channel），再
wg.Wait() - 每个 goroutine 开头调
wg.Add(1)，结尾defer wg.Done() - 别依赖
time.Sleep()猜等待时间——超时丢数据，等太久拖慢发布
绝对不要用 panic/recover 或 runtime.Goexit() 模拟退出
这些是运行时底层机制，不是应用层控制协程生命周期的工具。
-
panic会中断整个 defer 链，可能跳过mutex.Unlock()或file.Close() -
recover不保证发生——比如 panic 在另一个 goroutine，当前 goroutine 根本收不到 -
runtime.Goexit()只终止当前 goroutine，但要求调用点在它自己的栈上；无法从父 goroutine 触发，也不传播取消信号 - 混用
context和panic极易引发竞态：cancel 已触发，但 panic 还没执行完，资源状态就不可预测
真正难的不是“怎么发信号”，而是“goroutine 是否真在监听、是否清干净了所有资源”。哪怕用了 context，只要漏了一个 select 分支、少关一个 net.Conn，就等于没退出。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
