SpinLock 必须配合 ref bool lockTaken 使用且用 try-finally 包裹，仅在 lockTaken 为 true 时调用 Exit()；它仅适用于多核、低争用、纳秒级纯计算临界区，禁用于 async 或阻塞场景。
SpinLock 必须用 ref bool lockTaken 才安全
直接调用 SpinLock.Enter() 不带 ref bool 参数是错的——结构体复制后，Exit() 可能释放一个根本没拿到的锁，或在异常时漏释放。正确写法必须配合 ref bool lockTaken，且只在 lockTaken == true 时调用 Exit()。
-
lockTaken是输出参数，Enter 成功才设为true，失败或抛异常则保持false - 必须用
try-finally包裹，不能用using或try-catch替代 - 别把
SpinLock实例定义成局部变量——它是结构体，传参会复制，导致 Exit 失效
SpinLock 和 lock 的底层行为完全不同
lock 是 Monitor.Enter/Exit 的语法糖，线程争抢失败就挂起（进入内核态），让出 CPU；而 SpinLock 是纯用户态忙等：CPU 空转轮询，直到锁释放。这决定了它们适用的临界区长度天差地别。
-
lock适合任意长度的临界区，哪怕含Thread.Sleep(1)、await、I/O 或字典查找 -
SpinLock只适合「纯计算」+「纳秒级耗时」，比如单次Interlocked.Increment(ref counter) - 只要临界区平均超过 2 微秒，
SpinLock很可能 CPU 占用飙到 300%+，吞吐反而更低
SpinLock 在 async 方法里绝对不能用
自旋期间线程不能让出控制权，而 await 会触发上下文切换和线程跳转。一旦你在持有 SpinLock 时 await，当前线程可能被调度走，锁永远不释放，其他线程无限自旋——这不是死锁，是 CPU 白烧。
- 编译器不会报错，但运行时必崩或卡死
- 也不要在 SpinLock 里调用任何可能阻塞的方法，包括
Console.WriteLine（内部有锁）、Dictionary.TryGetValue（可能触发扩容） - 真要异步保护共享状态，改用
AsyncLock（基于SemaphoreSlim）或重构为无锁设计（如ConcurrentQueue）
高争用或单核 CPU 上 SpinLock 反而更慢
SpinLock 的优势建立在「低争用 + 多核 + 超短临界区」三者同时成立的前提下。现实里最容易踩坑的是误判争用程度：100 个线程抢同一把锁，不管临界区多短，都会导致大量线程同时空转，CPU 拉满却谁也进不去。
- 单核 CPU 上自旋毫无意义——自旋时别的线程根本跑不起来，锁永远无法释放
- 不要复用同一个
SpinLock实例保护多个无关资源，这会人为制造争用 - 上线前务必用
dotnet-trace或 Visual Studio 并发可视化工具看实际锁等待时间，别凭感觉选
lock。 
