Go中goroutine无法真正暂停和恢复，唯一可靠方式是用带缓冲的chan struct{}配合select实现协作式挂起与唤醒：暂停时在select中等待控制通道，恢复时向其发送信号，且需避免死锁与延迟响应。
goroutine 本身不能暂停和恢复
Go 没有提供类似 runtime.Gosched() 那样能“暂停当前 goroutine 等待唤醒”的原语，更没有 Pause() / Resume() 这类方法。强行用 time.Sleep() 或空循环“假装暂停”，只会浪费 CPU 或阻塞调度器，不是真暂停。
真正可行的路径只有一条：用通道（chan）配合 select 实现协作式挂起与唤醒。
- 暂停 = 在某个
select中等待一个控制通道（如pauseCh）接收信号 - 恢复 = 向该通道发送一个值（哪怕只是
struct{}{}） - 必须确保通道是带缓冲的（容量至少为 1），否则发送会阻塞，导致恢复失败
用 chan struct{} 控制单个任务生命周期
适用于简单场景，比如一个后台轮询任务需要临时停掉再继续：
func runTask(pauseCh <-chan struct{}, resumeCh <-chan struct{}) {
for {
select {
case <-pauseCh:
// 暂停：等 resumeCh 有信号才继续
<-resumeCh
default:
// 执行实际逻辑
doWork()
time.Sleep(1 * time.Second)
}
}
}注意这里用了两个独立通道——pauseCh 触发暂停入口，resumeCh 负责唤醒。避免单通道读写竞争；也别用同一个无缓冲通道反复读/写，容易死锁。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 调用方需维护两个通道实例，且保证
resumeCh是带缓冲的（make(chan struct{}, 1)） - 如果任务在
doWork()中耗时很长，暂停请求会被延迟响应——这是协作式暂停的固有限制 - 不能从外部强制中断正在运行的
doWork()，只能等它自己结束并进入下一轮select
用 context.Context + 取消 + 重启动态管理状态
当任务需要支持多次暂停/恢复、还要兼顾超时或取消时，硬编码通道容易失控。此时应把暂停/恢复抽象成状态机，用 context.Context 传递控制信号，并配合一个原子状态变量（如 int32）记录当前状态（running/paused/stopped）。
关键点在于：暂停不是让 goroutine 睡死，而是让它主动退出本次循环，下次循环前检查状态决定是否跳过执行。
- 不要在
select里直接监听ctx.Done()来实现暂停——那是取消，不是暂停 - 暂停期间仍要保持
ctx有效，否则下游依赖 context 的操作（如 HTTP 请求）会意外终止 - 恢复后需重新触发一次工作逻辑（比如往工作通道塞一个哨兵值），不能只靠“继续循环”——因为可能刚进循环就又遇到 paused 状态
为什么不用 sync.Cond？
有人会想用 sync.Cond 配合互斥锁模拟 wait/notify。不推荐：
-
Cond.Wait()会释放锁并挂起 goroutine，但 Go 的调度器不保证被Signal()唤醒的 goroutine 立即运行，存在明显延迟 - 必须搭配锁使用，容易写出死锁（比如在持有锁时调用
Wait()，或在Signal()前未加锁） - 无法跨 goroutine 安全传递条件变量指针，调试困难；而通道天然支持 goroutine 间通信，语义清晰
真实项目里，所有看似“暂停”的需求，最终落地几乎都回归到带缓冲的 chan struct{} + select 组合。别的方案要么不可靠，要么过度设计。
