科技 · 实用指南
Python queue.join() 一直卡住？审计未完成任务计数与 worker 存活
区分队列为空与未完成任务账本，暴露已退出消费者，正确处理哨兵和 Python 3.13+ 关闭语义，避免把放弃工作误报为完成。
queue.join() 等待的不是容器看起来为空，而是独立的未完成任务计数归零：每次 put 加一，每次 task_done 减一。worker 取走最后一项后若异常、取消或提前返回，empty() 可以为真，join 仍会正确等待。
先修复计数，再考虑超时。每次成功 get 后都在 finally 中恰好调用一次 task_done，同时监控 worker 与 join；哨兵也要计数。Python 3.13+ 的正常关闭保留 join 不变量，立即关闭则可能在工作未完成时解锁。
1. 证明卡住的是哪个计数
为每次 put、get、task_done 记录任务号、worker 和单调时间，用 put 数减确认数对账。qsize 与 empty 只描述容器，不描述处理完成。
不要清空 queue.queue 或修改 unfinished_tasks。清容器不会补上 join 所需的确认，私有字段修补还可能造成负计数或假完成。
2. 让确认在异常下仍恰好一次
get 成功后，把处理放进 try/finally，并在 finally 调用 task_done。若 get 尚未返回项目就失败或取消，不得凭空确认。
确认只表示本次交付已处理，不等于业务副作用成功。另记成功或失败，并避免重复调用导致 ValueError。
3. 同时观察 worker 存活和 join
finally 无法挽救已经退出且未进入保护范围的消费者。asyncio 应同时等待 queue.join 与 worker；worker 先结束就读取并传播异常。
线程模式要保留 worker 引用、停止信号和未捕获异常日志。超时只是诊断边界，不能当作完成。
4. 哨兵也要对账，并选择关闭语义
哨兵仍是排入队列的项目，消费者退出前必须确认。普通任务之后再放入正确数量的哨兵。
Python 3.13+ 的 shutdown(False) 让已有任务排空；shutdown(True) 可在未执行工作时解锁 join，只能用于明确放弃策略并报告丢弃项。
5. 用故障时间线验收
测试正常排空、处理异常、get 后取消、遗漏哨兵、worker 提前退出、正常关闭和立即关闭，并断言每个取出项只有一次确认。
验收不只看 join 返回，还要证明每个任务有终态、关闭后不能再 put、worker 已停止，放弃项没有被标成完成。
