核心问题是线程工厂未显式设置daemon属性导致行为不一致；应统一在构造时传入daemon=true/false，禁用已弃用的setdaemon()，按任务职责区分设置，并运行时校验daemon状态。
核心问题在于：线程工厂创建的线程未显式设置 daemon 属性，导致部分线程继承默认值 False，而某些运行环境（如某些测试框架、IDE 调试器或嵌入式解释器）可能在后台悄悄启动了 daemon 线程并影响新线程的初始化逻辑，造成行为不一致——有的线程阻塞主程序退出，有的却随主线程猝死，日志断尾、资源未释放、单元测试挂起等现象由此而来。
统一在线程工厂中强制指定 daemon 值
自定义线程工厂的本质是封装 threading.Thread 实例化过程。只要确保每次新建线程时都显式赋值 daemon，就能彻底消除随机性：
- 必须在调用
.start()之前设置，推荐在__init__或构造参数中直接传入 - 不要依赖
setDaemon()（已弃用），改用关键字参数daemon=True/False - 示例写法：
return threading.Thread(target=target, name=name, daemon=daemon, **kwargs)
避免混用 setDaemon() 和 daemon 参数
setDaemon() 是旧式方法，Python 3.10+ 已标记为弃用；与 daemon= 关键字混用会引发 RuntimeError 或静默覆盖，尤其在多层封装（如配合 concurrent.futures.ThreadPoolExecutor 的 thread_name_prefix）时极易出错：
- 删除所有
t.setDaemon(...)调用 - 检查第三方库文档，确认其线程构造是否接受
daemon参数（如ThreadPoolExecutor本身不暴露该参数，需通过自定义thread_factory注入） - 若使用
ThreadPoolExecutor，务必传入带daemon设置的工厂函数
验证线程实际 daemon 状态
仅靠代码逻辑不能完全信任，运行时应主动校验。可在关键路径加一行调试输出或断言：
assert t.daemon is True, f"Thread {t.name} unexpectedly non-daemon"- 在工厂函数返回前打印
t.daemon，或记录到调试日志 - 对已存在的线程列表，可用
[t.daemon for t in threading.enumerate()]快速扫描异常项
区分场景选择 daemon 值
不是所有线程都该设为 True。需按职责判断：
-
设为
True：纯后台任务，如心跳上报、指标采集、异步日志刷盘——主线程结束即无存在意义 -
设为
False：业务关键子任务，如订单补偿、文件上传回调、数据库事务收尾——必须保证执行完成才允许进程退出 - 若无法静态判定，建议默认
False，再按需逐个调整，比误杀更安全
