Flask内置静态服务不自动感知文件变更，其send_from_directory不检查文件修改时间、不动态设置Last-Modified或ETag，且url_for生成的静态URL无版本信息，导致浏览器缓存旧文件；构建加哈希是安全推荐方案，而Nginx前置时Flask缓存配置完全失效。
Flask内置静态服务不自动感知文件变更
Flask的send_from_directory（即默认/static/路由）只读取文件内容并返回，它**不会检查文件修改时间**，也不会在响应头里动态加入Last-Modified或校验ETag是否匹配。它只按SEND_FILE_MAX_AGE配置决定是否加Cache-Control，但这个值是全局、静态的——改了代码，文件内容变了，URL却没变，浏览器就继续用旧缓存。
url_for('static', ...) 生成的 URL 不带版本信息
模板里写{{ url_for('static', filename='main.css') }}，永远输出/static/main.css。哪怕你本地重写了main.css，URL不变，浏览器认为这是同一个资源，直接走缓存。
- 没有哈希、没有时间戳、没有查询参数，URL不具备“内容指纹”特性
-
SEND_FILE_MAX_AGE设再大，也救不了这种场景：用户看到的永远是第一次加载的版本 - 即使你手动在
url_for里加v=123，Flask默认静态视图会忽略查询参数，不触发新缓存（因为send_from_directory只看路径，不管?v=）
强制刷新缓存的常见方案及其代价
真要让浏览器认出“这是新文件”，必须让URL变化。可行但各有坑：
-
构建时加哈希：如
main.a1b2c3d4.css，配合构建工具（Webpack/Vite）+ 模板中url_for('static', filename='main.a1b2c3d4.css')——安全、推荐，但需要构建流程 -
运行时加mtime参数：重写
@app.context_processor，在url_for里注入q=1718991234——简单，但每次请求都要os.stat()，IO开销明显，不适用于高并发 -
重写
send_static_file：自己解析q或v参数，调用send_from_directory前做文件存在性校验——绕过Flask默认逻辑，需手动控制ETag/Last-Modified，容易漏掉304支持
Nginx前置时，Flask的缓存配置可能完全失效
生产环境大多用Nginx直接托管/static/路径，此时Flask根本收不到静态请求，SEND_FILE_MAX_AGE和自定义send_static_file全不生效。
立即学习“Python免费学习笔记（深入）”；
- Nginx默认对
.js、.css等后缀配expires 1y，但若没开启add_header ETag ...或if_modified_since，协商缓存就残缺 - 如果Nginx配置了
location /static { alias /path/to/static; }，又没配etag on和expires modified +1h，那连304都返回不了 - 此时“手动处理缓存刷新”的战场，其实已经从Flask转移到了Nginx配置或CDN规则里
SEND_FILE_MAX_AGE就万事大吉，结果部署到Nginx后，所有缓存行为都由Nginx定义，Flask配置形同虚设。而前端开发时又习惯本地跑Flask看效果，导致缓存问题只在上线后爆发。 
