Nginx开启sendfile后跳过用户态缓存校验，结合浏览器HTTP缓存（如ETag未更新），导致修改静态文件后仍返回304；强制刷新（Ctrl+F5）无法清除Chrome磁盘缓存，需配合Disable cache、sendfile off或URL版本控制等手段破缓存。
sendfile 开启时，Nginx 直接走内核零拷贝传输静态文件，跳过用户态缓存校验逻辑，导致浏览器收不到文件变更信号；加上 HTTP 缓存策略（如 ETag、Last-Modified）未更新或被忽略，浏览器就认定“还是同一个文件”，继续用本地缓存。
这不是 bug，是设计使然——但开发阶段它会让你反复怀疑自己改错了路径、没保存、甚至重装浏览器。
为什么 Ctrl+F5 有时也不管用？
强制刷新只绕过内存缓存，不保证清除磁盘缓存；Chrome 尤其激进，会把 .css 和 .js 文件长期存进磁盘缓存，哪怕你改了服务器上的文件，只要 URL 完全一致，它就不发新请求。
- 现象：
Network面板里看到状态码是304 Not Modified，说明浏览器发了条件请求，但服务端返回“没变” - 根因：Nginx 默认开启
sendfile on，且未配置expires或add_header ETag ""等主动控制缓存行为的指令 - 干扰项：某些代理（如 CDN）、浏览器扩展（如广告屏蔽器）也会劫持响应头，伪造
ETag
怎么让修改立即生效（开发阶段）？
别等用户清缓存，自己在本地环境切断缓存链路：
- 打开 Chrome DevTools（
F12），切到Network标签页，勾选Disable cache—— 注意：这个开关只在 DevTools 打开时生效 - 临时关闭 Nginx 的
sendfile：在 server 或 location 块里加sendfile off;，再nginx -s reload - 加个无意义查询参数强制破缓存，比如把
style.css改成style.css?v=ts123456789，用时间戳或 Git commit hash 生成
上线后如何避免用户看到旧 CSS？
靠人工清缓存不现实，得靠构建和部署环节自动处理：
- Webpack/Vite 等工具默认启用 contenthash，生成类似
style.a1b2c3d4.css的文件名，URL 变了，缓存自然失效 - 如果不用构建工具，至少在 HTML 中引用时加版本参数：
<link rel="stylesheet" href="main.css?v=2.3.1">，每次发版改v=后面的值 - 服务端可配
expires -1或Cache-Control: no-cache，但仅限开发或预发环境；生产环境慎用，会增加带宽和延迟
sendfile 和浏览器的缓存行为是两层独立机制，关掉其中一层，另一层仍可能拦住你。调试时得同时看 curl -I 输出的响应头 + Chrome Network 的请求详情，否则你会在“是不是 Nginx 没 reload”和“是不是前端引用写错了”之间来回横跳很久。 
