QueueHandler 与 multiprocessing 共用同一队列，首次写日志就卡住

子进程启动后，第一条日志就不再返回，主进程一直停在 join()。若给 multiprocessing.get_logger() 装了 QueueHandler，还打开了 DEBUG，应先检查内部日志是否又被送回同一个 multiprocessing.Queue。

队列初始化会写内部诊断日志；诊断日志再调用同一队列，可以形成递归或死锁。这里讨论这个具体配置条件，不把所有多进程日志卡住都归为一条原因。

在写日志前检查 handler 路径

用普通打印检查配置，避免诊断本身再次进入日志队列。以下片段放在 worker 的日志初始化之后、第一条业务日志之前；log_queue 是应用实际使用的队列对象：

import logging
import logging.handlers
import multiprocessing

mp_logger = multiprocessing.get_logger()
print("level:", logging.getLevelName(mp_logger.getEffectiveLevel()))
print("propagate:", mp_logger.propagate)
for handler in mp_logger.handlers:
    same_queue = (
        isinstance(handler, logging.handlers.QueueHandler)
        and handler.queue is log_queue
    )
    print(type(handler).__name__, "same queue:", same_queue)

还需沿传播路径检查实际接收内部日志的其他 logger，不能只看当前列表。跨进程的对象编号也不能直接用来证明是不是同一条队列通路；应看队列怎样传入 worker、handler 如何绑定，以及是否把内部诊断回送到它本身。

标准队列的首次 put 可能启动 feeder thread，在初始化期间发出 DEBUG 日志。若这条日志经 handler 再次进入相同队列，卡住可以发生在数据真正交给监听器之前。只增加 listener、扩大队列长度或延长 join 超时，不能修正这个循环。

给内部诊断一条不回到业务队列的输出路径

应用日志仍可以走集中队列，但 multiprocessing 内部诊断不能通过使用同一队列的 QueueHandler 回送。由应用拥有的日志配置入口调整已确认冲突的 handler，必要时将内部诊断送到独立的直接输出 handler，并明确传播设置。

不要在框架运行期间清空全部 handler，或把所有 logger 强制重新配置。先保存各进程的 handler、级别、传播和监听器设置，只处理已确认的循环路径；还要避免重复初始化后再次添加冲突的 handler。

若业务允许关闭这一路 DEBUG，调整相应级别可以避开这一触发条件，但会减少诊断信息，并非所有卡住的通用修复。需要保留 DEBUG 时，应修正输出路径。私有的 q._start_thread() 不是稳定公开接口，不适合作为正式配置方案。

Python 当前文档仍明确提示相同队列的死锁或递归风险，不能把某条问题已关闭理解为运行时已经允许这种配置。多进程场景也不能简单换成 SimpleQueue：标准文档建议这类用途使用 multiprocessing.Queue，并避免 SimpleQueue。

listener 退出与队列满是另两项检查

若排除了回送循环，继续查看 worker 是否正在执行其他阻塞操作、listener 是否仍在消费、日志是否可序列化，以及退出流程是否过早停止监听器。需要在正常 worker 结束并完成所需日志排空后，再按应用流程停止监听器；不要以强杀进程作为验收方式。

有界队列满时，QueueHandler 还可能丢弃消息，具体取决于错误处理配置。那通常表现为缺日志或处理错误，不等于本文的首次写入卡住。basicConfig 没覆盖已有 handler，则是另一层配置问题，可看 已有 handler 导致 basicConfig 不生效。

在隔离环境检查每个 worker 的第一次日志、后续日志和正常退出，确认内部诊断没有回送同队列，业务日志仍由原监听器接收。保留修改前配置以便恢复；若诊断不成立，按原配置入口回退并保存阻塞线程或进程的实际堆栈，不删除日志、清队列或全局提高级别掩盖故障。