不能把 channel 当作自旋锁用，因为 channel 阻塞时会挂起 goroutine 而非 CPU 自旋；select + default 仅为非阻塞轮询，非真自旋，强行模拟会导致高 CPU 占用且违背 Go 并发哲学。
Go 语言里没有“Channel 的自旋锁机制”——channel 本身不是锁，也不实现自旋逻辑。把 channel 当作自旋锁用，要么是误解了语义，要么是在特定场景下强行模拟，但代价高、易出错、违背 Go 并发哲学。
为什么不能把 channel 当作自旋锁用
自旋锁的核心行为是：线程在获取不到锁时，不挂起，而是循环检测（busy-wait），靠 CPU 空转抢资源；而 channel 的发送/接收操作在阻塞时会主动让出 goroutine，调度器将其挂起，等就绪后再唤醒——这是协作式调度，不是忙等。
-
select配合default可以实现“非阻塞尝试”，但本质是轮询 + 调度切换，不是 CPU 自旋 - 真用
for {}空循环加select去“等 channel 可写”，会吃满一个 P 的 CPU，且无法响应 GC、抢占，属于反模式 -
channel的底层是带锁的环形队列（如chan的lock字段），但它对用户透明，且锁只保护内部结构，不提供应用层同步语义
select + default 不是自旋，是退化为轮询
常见误写：
for {
select {
case ch <- value:
return
default:
runtime.Gosched() // 或 time.Sleep(1ns)
}
}这段代码看似“等待 channel 可写”，实则：
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 每次
select都触发一次调度检查，开销远高于原子指令或互斥锁 -
runtime.Gosched()让出时间片，但 goroutine 仍频繁被调度器唤醒，造成大量上下文切换 - 若
ch是无缓冲 channel，且接收方长期不出现，该 goroutine 就成了定时炸弹 - 它和
sync.Mutex的TryLock()（如果有）语义完全不同：后者是原子判断，前者是完整通道状态快照 + 调度干预
真正需要“快速抢占”的场景该用什么
Go 中极少需要自旋锁。只有极少数低延迟、短临界区、确定争用极低的场景（如某些 lock-free 结构的辅助标记），才考虑 sync/atomic + 循环 CAS：
var state int32
for !atomic.CompareAndSwapInt32(&state, 0, 1) {
runtime.Park(nil, nil, "spin", traceEvNone, 1)
}但注意：
-
runtime.Park()不是自旋，仍是挂起；真自旋应避免调用任何运行时函数 - 标准库中
sync.Mutex在争用少时会先自旋几十次（通过LOCK XCHG指令），但这完全由汇编实现，用户不可见也不可控 - 业务逻辑里硬写
for atomic.LoadInt32(&x) == 0 {}是危险的：可能被编译器优化、不保证内存序、无法被抢占
Channel 的正确定位：通信，不是同步原语
Go 的并发模型信条是 “Don’t communicate by sharing memory; share memory by communicating”。channel 的设计目标是：
- 在 goroutine 间安全传递数据（带类型、带缓冲控制）
- 天然支持超时（
time.After）、取消（context）、多路复用（select） - 配合
close()实现优雅退出信号
如果只是为了“等某个条件成立”，优先用 sync.Cond + sync.Mutex，或更现代的 errgroup.Group + context；若需协调多个 goroutine 步调，用 sync.WaitGroup；若要保护共享状态，用 sync.Mutex 或 sync.RWMutex。
把 channel 当锁用，就像拿扳手拧螺丝——能动，但牙纹咬不紧，还容易滑丝。
