确认死锁需先ctrl+c查看线程栈：若多线程同停在acquire()且id相同，或a持lock_a等lock_b、b持lock_b等lock_a，即为死锁；调试须设subprocess:true和justmycode:false。
断点卡在 Lock.acquire() 但没报错，怎么确认是死锁？
死锁不会抛异常，程序只是不动——这时候别急着改代码，先看线程是否真挂住了。最直接的办法是手动中断：运行中按 Ctrl+C，Python 会强制打印所有线程当前调用栈。重点扫三类信息：
- 多个线程都停在
Lock.acquire()或RLock.acquire()，且传入的是同一个Lock对象（id(lock)相同） - 线程 A 显示刚拿到
lock_a，下一步正等lock_b；线程 B 刚拿到lock_b，正等lock_a - 堆栈里出现
threading.Thread.run→ 你的函数名 →acquire，说明阻塞点就在你代码里，不是底层调度问题
如果中断后没输出，或只看到主线程堆栈，说明调试器没捕获子线程——得先解决调试配置问题。
launch.json 里必须加的两项：为什么 subProcess: true 和 justMyCode: false 缺一不可
VS Code 默认只跟踪主线程，子线程里的 acquire() 调用根本进不了调试器视野。仅设 justMyCode: false 不够，它只让调试器不跳过标准库帧，但依然不监听新线程；必须同时开 subProcess: true，debugpy 才会注入每个 threading.Thread 实例。
-
subProcess: true：启用子进程/子线程级调试注入，threading.Thread、ThreadPoolExecutor启动的线程全被接管 -
justMyCode: false：避免调试器在进入threading.py的_bootstrap方法时“丢帧”，否则你的worker()函数可能直接被跳过 - 别设
stopOnEntry: true：它只对主线程生效，反而会让调试器在启动时卡住，错过子线程初始化时机
验证是否生效：写个两行脚本，time.sleep(0.1) 后打个断点，跑起来看断点是不是实心圆、悬停有没有提示 “Breakpoint hit”。不是？配置还没生效。
切换线程上下文看谁持有了锁，而不是谁在等
VS Code 调试器暂停后，“CALL STACK”面板顶部会出现下拉菜单，列出所有活动线程。死锁排查的关键不是看谁卡在 acquire()，而是找那个“已经拿到锁、却迟迟不释放”的线程。
- 逐个点击线程，看它的调用栈末端是不是停在你代码的临界区内部（比如刚执行完
lock_a.acquire()，还没走到lock_a.release()） - 检查该线程的局部变量和“VARIABLES”面板里的共享对象状态，确认它是否因异常、return 缺失或逻辑分支没覆盖，导致
release()没被执行 - 注意线程名（
threading.current_thread().name）和 ID（threading.get_ident()），和日志对上，避免把 A 线程的日志误判成 B 线程的行为
如果所有线程都卡在 acquire()，但找不到任何线程持有锁——那可能是锁被主线程拿了没放，或者锁对象本身被意外重置（比如重复初始化）。
加锁日志比断点更可靠，尤其在线程快速切换场景
调试器暂停会改变线程执行节奏，有时反而掩盖死锁条件。生产环境或高频并发下，靠日志定位更稳：
- 在每次
lock.acquire()前打日志：f"[{threading.current_thread().name}] acquire {id(lock)} at {time.time():.3f}" - 在
lock.release()后打日志：f"[{threading.current_thread().name}] release {id(lock)}" - 关键不是记录“做了什么”，而是记录“谁、什么时候、对哪个锁实例做了操作”——
id(lock)必须打，否则分不清是同一把锁还是不同实例
典型线索：A 线程日志显示 acquire lock1 → acquire lock2，然后没了；B 线程日志显示 acquire lock2 → acquire lock1，也停了。这基本就是循环等待，不用等程序卡死再查。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
