asyncio.Lock用于协程间同步共享资源，确保单线程异步环境中临界区互斥访问；不适用于跨线程、阻塞I/O或CPU密集型任务。
asyncio.Lock 主要用于在协程间同步访问共享资源，避免竞态条件。它不是为线程或进程设计的，只在单线程的异步事件循环中生效。
保护异步操作中的共享状态
当多个协程需要读写同一个变量（如计数器、缓存字典、连接池状态）时，必须加锁，否则结果不可预测。
- 例如：多个协程同时对 counter += 1 操作，不加锁可能导致漏更新
- 锁确保同一时间只有一个协程执行临界区代码，其他协程 await lock.acquire() 暂停等待
- 务必配合 async with lock: 使用，自动释放，避免死锁
限制并发访问外部资源
某些资源本身不支持高并发，比如数据库连接数有限、API 有调用频次限制、文件以独占模式打开等。
- 用一个全局 Lock 控制同一时刻最多一个协程发起请求
- 比单纯用 asyncio.Semaphore（允许多个并发）更严格，适合“完全互斥”场景
- 注意：不要用 Lock 替代 Semaphore 来控制 N 路并发，应选 asyncio.Semaphore
协调协程执行顺序（简单场景）
虽非主要用途，但可借助 Lock 实现简单的“先到先得”顺序控制，比如初始化仅执行一次。
立即学习“Python免费学习笔记（深入）”；
- 定义一个模块级 lock 和标记变量，首次进入的协程获得锁并完成初始化
- 后续协程 acquire 失败或立刻释放，直接使用已初始化的结果
- 更推荐用 asyncio.OnceCallback 或第三方库 async-lru，Lock 属于低阶手动方案
不适用的典型情况
理解哪些场景不该用 asyncio.Lock，能避免误用：
- 跨线程/多进程：Lock 只在当前 event loop 内有效，不能同步不同线程里的协程
- 阻塞 I/O 操作中：在 sync 函数里调用 time.sleep() 或 requests.get() 时，Lock 不起作用，会阻塞整个事件循环
- 纯 CPU 密集任务：asyncio.Lock 不解决 GIL 问题，CPU 绑定任务应交给线程池/进程池，而非靠锁串行化协程
