go的time.sleep达不到微秒级精度，因其底层依赖操作系统调度，linux/macos最小分辨率通常为1–15ms，windows更差；传入time.microsecond会被向上取整至系统时钟粒度（如15ms），属设计使然而非bug。
Go里time.Sleep为什么达不到微秒级精度？
Go的time.Sleep底层依赖操作系统调度，Linux/macOS上最小分辨率通常在1–15ms，Windows更差；即使传入time.Microsecond，实际休眠时间往往被向上取整到系统时钟粒度（比如15ms），根本不是“微秒级延时”。这不是bug，是设计使然——Go不承诺亚毫秒级睡眠精度。
用runtime.Gosched()和忙等待能凑出微秒级吗？
不能盲目轮询。纯CPU忙等待（如for time.Now().Sub(start) ）会导致：
<ul>
<li>单核场景下可能饿死其他goroutine（尤其GOMAXPROCS=1时）</li>
<li>多核下消耗100% CPU，且受调度器抢占影响，误差仍达数十微秒</li>
<li>不同CPU频率、温度、负载下偏差剧烈，不可靠</li>
</ul>
<code>runtime.Gosched()只是让出当前goroutine，不控制时间，对精度无帮助。
真正可用的微秒级延时方案：结合time.Now()与time.Sleep
务实做法是“粗睡+精调”：先用time.Sleep休眠到离目标时间还剩几十微秒，再用高精度计时+忙等待收尾。关键点在于：
- 预留足够缓冲（建议≥50μs），避免因调度延迟错过目标点
- 忙等待只做最后几微秒，且必须用
time.Now()而非time.Since()（后者有额外函数调用开销） - 实测表明，在现代Linux（4.15+）+ Go 1.21+环境下，5–100μs范围误差可稳定控制在±2μs内
func SleepMicroseconds(us int64) {
if us 0 {
time.Sleep(coarse)
}
// 精调：忙等待至target
for time.Now().Before(target) {
}
}
哪些场景不该硬上微秒延时？
多数业务逻辑根本不需要真微秒级控制：
- 网络超时、数据库连接池等待、HTTP客户端timeout——用
context.WithTimeout或原生timeout字段，它们基于系统timer，更稳 - 定时任务调度（如每100ms采样）——
time.Ticker足够，别自己手写循环 - 硬件同步（如GPIO脉冲）——Go不是实时语言，应交由C/rust驱动或专用RTOS处理
clock_nanosleep或绑定CPU核心（syscall.SchedSetAffinity），单纯Go代码有天然天花板。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
