Flask热更新需用--reload而非--debugger；默认仅监听Python文件，模板需配置TEMPLATES_AUTO_RELOAD；非Python文件须用watchdog手动监听；importlib.reload()风险高，推荐切换数据+统一访问入口。
Flask开发时改代码不生效？先确认是不是用了--reload而不是--debugger
Flask自带的热更新能力其实就靠--reload开关，不是--debugger——后者只开调试器，不触发重载。很多人在PyCharm里配了python -m flask run --debugger，改完保存，服务纹丝不动，就是卡在这儿。
-
flask run --reload：监听Python文件变化，自动重启整个进程（推荐开发用） -
flask run --debugger --reload：带调试器 + 重载，更完整（但别漏掉--reload） -
app.run(debug=True)：等价于启用--debugger --reload，但仅限脚本直接运行，不适用于flask run命令模式
如果你用的是FLASK_APP=app.py flask run，那必须显式加--reload；否则哪怕debug=True写在代码里也没用——因为flask run命令不读取应用内部的debug配置。
为什么--reload有时不工作？常见静默失效场景
它不是万能的，尤其在非标准项目结构或路径配置下容易“假装在工作”。典型失效原因：
- 修改的文件没被
watchdog（Flask底层用的监听库）纳入监控范围，比如放在utils/、models/等非sys.path默认路径下的模块 - 用了
from mypkg import xxx导入，但mypkg不在当前工作目录或PYTHONPATH中，--reload压根看不到它 - 静态文件（
.html、.js）或模板（templates/）改动不触发重载——Flask默认只监Python文件，app.jinja_env.auto_reload = True和app.config['TEMPLATES_AUTO_RELOAD'] = True才能让模板生效
验证是否真在监听：启动时看终端有没有打印* Detected change in 'xxx.py', reloading。没有？说明文件根本没进watchlist。
想监控任意文件（如JSON配置、模型bin）并热更新？别硬改--reload，自己接watchdog
Flask的--reload只管Python源码，对数据文件、配置、模型权重完全无感。真要实现“模型每天更新、接口自动加载新版本”，得绕过它，用watchdog手动监听+触发逻辑。
- 安装：
pip install watchdog - 监听目标路径（比如
models/latest.pkl），在独立线程里跑FileSystemEventHandler - 检测到
modified事件后，调用你封装好的load_model()，再set_model()更新全局变量（别直接importlib.reload()，极易引发对象类型错乱） - 关键点：所有对外服务的函数都应通过
get_model()取实例，而不是在模块顶层model = load_model()
示例核心逻辑：
from watchdog.observers import Observer
from watchdog.events import FileSystemEventHandler
<p>class ModelReloadHandler(FileSystemEventHandler):
def on_modified(self, event):
if event.src_path.endswith("latest.pkl"):
new_model = load_model("latest.pkl")
set_model(new_model) # 安全替换全局缓存注意：watchdog需自己管理线程生命周期，别让它随Flask主进程意外退出而消失。
用importlib.reload()强行重载模块？风险远大于收益
网上有些方案教你在路由里写importlib.reload(my_module)，听起来很“热”，实际是埋雷：
- 旧模块里的类实例（比如已创建的
ModelProcessor()对象）仍指向老class，调用方法还是旧逻辑 - 如果模块里有全局状态（
CACHE = {}）、单例、线程局部变量，reload()不会清理它们，新旧逻辑混跑 - 依赖该模块的其他模块不会自动重载，可能引发
AttributeError或NameError
真正安全的热更新，从来不是“重载代码”，而是“切换数据+收敛访问入口”。把模型、配置、规则都做成可替换的对象，所有业务逻辑走统一getter，这才是生产级做法。
复杂点在于设计初期就要把“可变部分”和“稳定骨架”切开——很多人后期补，结果发现90%的代码都散落在各处new对象，没法收口。这时候不如老实定时重启服务。
