queue.Queue本身线程安全，无需额外加锁；其put()、get()等方法已内置threading.Lock和Condition同步逻辑，直接使用即可避免竞态，切勿手动加锁或用list模拟队列。
queue.Queue 本身就是线程安全的，不用额外加锁
Python 的 queue.Queue 底层用的是 threading.Lock 和条件变量（threading.Condition），所有公共方法（put()、get()、task_done()、join()）都已内置同步逻辑。你直接用，不会出现竞态——比如两个线程同时 get() 导致数据错乱或 IndexError。
常见误解是“队列操作简单，我手动加个 threading.Lock 更保险”，反而可能引发死锁或掩盖真实问题。
- 如果用
queue.Queue，就别在外部再套with lock:包裹put()或get() - 不要试图用
list+ 手动锁模拟队列，那不是线程安全的 -
queue.Queue的阻塞行为（如get(block=True)）也是原子的，不会在“判断非空→取值”之间被中断
为什么 queue.Empty / queue.Full 不该被忽略
调用 get_nowait() 或 put_nowait() 时，队列为空或满会分别抛出 queue.Empty 和 queue.Full 异常。这不是错误，而是设计好的控制流信号——但很多人写成裸 except: 或直接忽略，导致程序静默失败。
典型误用：q.get_nowait() 在空队列下抛 queue.Empty，结果被 except Exception: 吞掉，后续逻辑拿不到数据却无提示。
立即学习“Python免费学习笔记（深入）”；
- 显式捕获
queue.Empty，并决定是重试、跳过还是退出循环 - 设置超时比用
_nowait更可控：q.get(timeout=0.1)抛queue.Empty，且避免忙等 -
maxsize设为 0 表示无限，设为正整数后put()可能阻塞或抛queue.Full，需按需处理
task_done() 和 join() 配合不当会导致主线程永远卡住
当用 queue.Queue 做工作分发（比如生产者-消费者模型），必须严格配对：每个 get() 出来的任务，处理完后要调一次 task_done()；主线程靠 join() 等待所有任务完成。漏调 task_done()，join() 就永远不会返回。
最容易漏的情况是异常路径——任务处理中途抛了异常，没走到 task_done()。
- 务必把
task_done()放在finally块里，或用上下文管理器封装 - 不要在消费者线程里重复调
task_done()，会破坏内部计数器 -
q.unfinished_tasks是受保护的内部计数器，别手动改它
queue.Queue 不适合进程间通信（multiprocessing 场景）
名字叫 Queue，但它不是为多进程设计的。queue.Queue 的锁和条件变量基于 threading，跨进程不生效。在 multiprocessing.Process 中直接传 queue.Queue 实例，会报 PicklingError 或静默失效。
如果你看到“子进程 get() 拿不到数据”“主线程 join() 一直等”，先检查是不是误用了 queue.Queue 而非 multiprocessing.Queue。
- 多线程 → 用
queue.Queue - 多进程 → 用
multiprocessing.Queue（注意它不提供task_done()/join()） - 混合场景（多进程+每进程内多线程）→ 各自用对应 Queue，别混用
真正容易被忽略的是异常路径下的 task_done() 调用，以及把 queue.Queue 当作通用容器去索引、切片或 len() —— 它不支持这些操作，也不该支持。
