time.Sleep仅阻塞当前goroutine，不暂停全局；需配合goroutine实现延迟执行，不响应context取消，精度有限，不适合高精度定时任务。
time.Sleep 会阻塞当前 goroutine，不是全局暂停
time.Sleep 只会让调用它的那个 goroutine 暂停，不会影响其他 goroutine 运行。这是最常被误解的一点——有人以为它像 
JavaScript 的 setTimeout 那样“延迟执行某段代码”，其实它只是“当前线程睡一会儿”。如果你在 main 函数里直接调用，程序看起来像卡住了，但那只是主线程在等；如果在单独的 goroutine 里调用，其他逻辑照常运行。
常见错误现象：time.Sleep 放在循环里却没看到预期的间隔效果，是因为忘了它不返回、也不自动触发后续操作，纯粹是同步阻塞。
- 必须配合 goroutine 使用才能实现“延迟后做某事”
- 参数类型固定为
time.Duration，不能传 int 或 string - 单位要显式指定，比如
time.Second、time.Millisecond，不能写1000代替1000 * time.Millisecond
想延迟执行一段逻辑？得用 goroutine + time.Sleep 组合
Go 没有内置类似 setTimeout 的函数，但可以用 go func() { time.Sleep(...); /* do something */ }() 模拟。这种写法本质是启动一个新 goroutine，在里面先睡再干活。
使用场景：定时轮询、模拟异步回调、避免密集重试、UI 状态延时更新（如命令行进度提示）。
注意：如果延迟逻辑需要访问外部变量，记得捕获正确值，避免闭包陷阱。
go func() {
time.Sleep(2 * time.Second)
fmt.Println("2秒后执行")
}()
// 如果要在循环中延迟执行不同内容：
for i := 0; i < 3; i++ {
i := i // 创建新变量，避免闭包引用同一地址
go func() {
time.Sleep(time.Duration(i) * time.Second)
fmt.Printf("第%d次延迟执行\n", i)
}()
}
别用 time.Sleep 做精确定时任务
time.Sleep 的实际休眠时间可能略长于指定值，尤其在系统负载高、GC 触发或调度延迟时。它不保证精度，只保证“至少睡这么久”。如果你需要每 500ms 执行一次且误差不能超过 10ms，应该用 time.Ticker；如果只需一次性延迟且对精度要求不高（比如网络重试间隔），time.Sleep 完全够用。
-
time.Sleep(100 * time.Millisecond)实际可能耗时 105ms 或更多 - 在测试中 mock
time.Sleep很麻烦，建议把 sleep 封装成可注入的接口 - 频繁调用小间隔 sleep（如
time.Sleep(1 * time.Microsecond)）几乎无效，会被调度器忽略
time.Sleep 和 context.WithTimeout 冲突吗？
不冲突，但要注意：如果在 time.Sleep 期间上下文已超时，sleep 不会自动中断——它仍会睡满。也就是说，time.Sleep 不响应 context 取消信号。要实现可取消的延迟，得用 time.AfterFunc 或结合 select + time.After。
例如，等待最多 3 秒，但允许提前退出：
select {
case <-time.After(3 * time.Second):
fmt.Println("延迟完成")
case <-ctx.Done():
fmt.Println("被取消了")
}这种写法才是符合 Go 并发模型的惯用方式。硬套 time.Sleep 在需要 cancel 的场景里，等于自己绕开调度控制。
真正容易被忽略的是：sleep 时间一长，goroutine 就一直挂着，哪怕业务逻辑早该结束了。所以凡是有 context 场景，优先考虑 time.After 或 time.NewTimer。
