asyncio.Lock 能解决全局变量竞态，但仅保障临界区互斥，不保证业务逻辑正确；需用模块级单例、细粒度包裹写操作，避免滥用。
asyncio.Lock 能不能解决全局变量竞态？
能，但只在“读-改-写”三步必须原子执行时才真正起作用；如果多个协程都读到旧值再各自加1，asyncio.Lock 无法阻止这种逻辑层覆盖——它保的是临界区不重入，不是保业务语义正确。
常见错误是把锁用在了错误位置：比如把 await asyncio.sleep(0.001) 也包进 async with lock:，既没提升安全性，又拖慢并发吞吐。
- 锁对象必须是模块级单例，不能每次协程里
asyncio.Lock()新建一个 -
async with lock:是唯一推荐写法；手动await lock.acquire()+lock.release()容易漏掉释放 - 锁粒度要细：只包裹
global_counter = current + 1这类写操作，读取和异步延迟尽量放外面
为什么 contextvars 比全局变量更合适？
因为 contextvars.ContextVar 天然隔离协程上下文，不需要锁——每个协程拿到的是自己副本，根本不存在“竞争”。
但它只适用于“状态随协程生命周期存在”的场景，比如请求 ID、用户身份、追踪链路等，不适合做跨协程共享的计数器或缓存。
立即学习“Python免费学习笔记（深入）”；
- 必须配对使用
var.set()和var.reset(token)，漏掉reset会导致子协程意外继承父协程值 - 不能在普通同步函数里调用
var.get()，会返回default或抛LookupError -
ContextVar名字只是调试标识，不影响作用域，别指望靠名字实现命名空间隔离
有没有比锁和 contextvars 更轻量的替代方案？
有。优先考虑把全局状态收束进一个可控对象里，而不是散落在模块顶层。
比如用 asyncio.Queue 做生产者-消费者缓冲，或封装成带内部锁的 AsyncCounter 类——这样调用方完全不用操心同步细节。
- 直接操作全局变量本身就是坏味道，在异步环境下尤其危险
-
asyncio.Queue天然线程/协程安全，适合解耦任务分发与状态更新 - 如果只是计数，
asyncio.Semaphore可控资源许可数，但不提供数值读取接口
多线程和异步混用时锁选哪个？
看执行环境：纯 asyncio 协程用 asyncio.Lock；混合了 threading.Thread 就得用 threading.Lock，且必须确保所有线程共享同一个实例。
千万别在协程里 await 一个 threading.Lock，它会阻塞整个事件循环；也别在普通线程里 await asyncio.Lock，语法直接报错。
- 跨线程访问 async 对象（如
asyncio.Queue）需用loop.call_soon_threadsafe() - 如果用了
multiprocessing，锁要换成multiprocessing.Lock，它不跨进程 - 最易忽略的一点：日志、配置加载、单例初始化这些看似“只读”的操作，一旦涉及写入（比如首次加载后缓存到全局 dict），也得上锁
