setDaemon(True)必须在start()前调用，否则抛出RuntimeError；守护线程不执行finally和__del__，无法保证清理，应仅用于可随时终止的轻量任务。
setDaemon(True) 必须在 start() 之前调用，这不是建议，是 Python threading 模块的硬性约束——一旦线程已启动，再设守护状态就会立刻抛出 RuntimeError: cannot set daemon status of active thread。
这个限制背后有明确的设计逻辑：守护属性是线程对象创建时就应确定的“生命周期契约”，不是运行时可动态切换的开关。它决定了该线程是否随主线程退出而被强制终止，系统必须在调度前就知晓这一语义。
以下是帮你真正记住并避开踩坑的几个关键点：
守护属性只能在“未启动”状态下设置
线程对象刚创建出来时处于 NEW 状态，此时可安全调用 setDaemon(True)；一旦执行 start()，状态变为 RUNNING，属性即冻结。
- ✅ 正确顺序：
t = threading.Thread(target=task) t.setDaemon(True) # 或构造时直接 daemon=True t.start()
- ❌ 错误写法（会崩溃）：
t = threading.Thread(target=task) t.start() t.setDaemon(True) # RuntimeError！
构造时传 daemon=True 是更现代、更安全的写法
Python 3.9+ 推荐直接在初始化时指定，既避免顺序错误，也提升可读性：
t = threading.Thread(target=task, daemon=True) # 一行搞定，无隐患 t.start()
这种方式从源头杜绝了“先 start 后 setDaemon”的误操作可能。
守护线程不执行 finally 和 del，没有清理机会
这是你必须牢记它的根本原因：它被设计为“可随时粗暴终止”的轻量后台任务（比如心跳上报、日志轮转），不能承担资源释放、文件关闭、数据库提交等需要保证执行的任务。
如果你发现某任务“本该清理却没清理”，第一反应应是检查它是否被错误设为守护线程，而不是补 finally ——那根本不会运行。
实际调试中一眼识别问题
当程序异常退出、子线程行为诡异、或反复报 RuntimeError 时，快速定位方法：
- 搜索代码中所有
.setDaemon(调用 - 确认其是否紧邻
threading.Thread(...)创建之后、.start()之前 - 优先替换成
daemon=True构造参数，一劳永逸
不复杂但容易忽略。
