用户线程需显式join以释放资源，守护线程由解释器自动终止且不执行清理；二者不可混用，关键任务用用户线程，无状态后台任务用守护线程，推荐优先使用threadpoolexecutor等高级抽象。

关键在于明确两类线程的生命周期责任：用户线程必须被显式等待或管理，守护线程则交由解释器自动回收，不能混用资源释放策略。

用户线程要主动 join 或统一收尾

用户线程承载核心逻辑，Python 不会替你回收其资源。若不处理，线程函数退出后仍占用栈空间和系统句柄，形成“僵尸线程”。

• 必须在主线程退出前调用 t.join()，确保子线程自然结束并释放资源
• 多个用户线程建议集中管理：用列表收集，统一遍历 join()，避免遗漏
• 如需超时控制，可传入参数 t.join(timeout=3)，防止无限阻塞
• 若线程可能长期运行（如监听循环），应配合 threading.Event 提供优雅退出信号，而非粗暴 kill

守护线程只用于可中断的后台任务

守护线程不是“省事开关”，而是语义承诺：它的任务不重要、可随时丢弃。设置 daemon=True 后，Python 在主线程及所有用户线程结束后立即终止它，不执行清理逻辑。

• 仅适用于无状态、无副作用的任务，比如定时日志刷盘、心跳上报、缓存预热
• 绝不能在守护线程中持有文件句柄、数据库连接或锁——因为没有机会执行 finally 或 close()
• 设置必须在 start() 之前完成，例如：t.daemon = True；之后设无效
• 守护线程启动的子线程默认也是守护线程，无需重复设置

避免混合使用导致资源泄漏

常见错误是把本该 join 的用户线程误设为守护线程，或反过来让守护线程承担关键清理工作。

• 检查线程用途再决定类型：业务主流程 → 用户线程；辅助支撑 → 守护线程
• 不要依赖守护线程做资源释放，例如“用守护线程 close 数据库连接”是危险的
• 若需后台自动清理，改用 atexit.register() 或上下文管理器（with 块）在进程退出前统一处理
• 调试时可用 threading.enumerate() 查看当前存活线程，确认无意外残留

更稳妥的替代方案

原生线程手动管理容易出错。对多数场景，推荐升级为更高阶抽象：

• threading.ThreadPoolExecutor：提交任务即托管生命周期，shutdown(wait=True) 自动等待全部完成
• concurrent.futures.as_completed()：按完成顺序获取结果，天然规避 join 顺序问题
• 对周期性后台任务，用 schedule 库 + 守护线程封装，把调度逻辑和执行分离