Nginx的sendfile机制会导致浏览器缓存误判：启用sendfile on后，内核零拷贝绕过用户态，使文件mtime变化不被感知，触发304响应但内容已更新；临时关闭sendfile可验证，生产环境应配合ETag或expires精准控制。

静态文件改了但浏览器没变，不是代码没保存，也不是Nginx没重启，而是传输链路和缓存机制在“联手屏蔽”更新。核心问题通常出在三个环节：Nginx的sendfile机制、浏览器缓存策略、以及反向代理或CDN层的中间缓存。

检查 Nginx 的 sendfile 配置是否干扰文件实时读取

默认sendfile on启用内核零拷贝，它会让Nginx绕过用户态缓冲区直接送文件——这虽快，但会导致文件系统修改时间（mtime）未被有效感知，尤其在开发环境频繁覆盖同名文件时，浏览器可能收到“未变化”的响应（304），实际内容却已不同。

• 临时解决：在http或server块中设sendfile off;，再执行nginx -t && nginx -s reload
• 验证是否生效：用curl -I http://your-domain/style.css看响应头，若仍返回200且内容已更新，说明问题在此
• 注意：生产环境不建议长期关闭，可搭配expires或ETag精细控制

确认浏览器是否在用旧缓存

Chrome对静态资源缓存最激进，普通F5或点击刷新几乎无效；Firefox稍宽松，但也不可靠。

Linux Ai Server

Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。

下载

• 强制重载方式：打开开发者工具（F12），右键刷新按钮 → 选“清空缓存并硬性重新加载”，或快捷键Ctrl+Shift+R（Windows/Linux）/Cmd+Shift+R（macOS）
• 更彻底：在开发者工具的Network标签页勾选“Disable cache”，再刷新，确保所有请求都走200
• 检查响应状态码：若看到大量304，说明浏览器认定资源未变，需同步排查服务端ETag或Last-Modified逻辑

排查反向代理或CDN是否缓存了旧版本

如果你用Nginx做反向代理（比如前端Vue项目代理到后端API），或前端套了CDN（如Cloudflare、阿里云DCDN），它们会独立缓存静态资源，且TTL常达数小时甚至1天。

• 查Nginx反向代理缓存：确认配置中是否有proxy_cache相关指令，如有，临时注释掉并重载
• 查CDN缓存：登录对应平台控制台，手动触发“刷新URL”或“预热”，或临时将缓存策略设为no-cache
• 快速验证：用curl -H "Cache-Control: no-cache" http://your-domain/app.js对比响应内容，若与浏览器不一致，基本锁定中间缓存

验证静态文件路径与权限是否真实生效

有时你以为改的是Nginx服务的文件，其实访问的是另一个目录，或者Nginx进程根本没权限读取新文件。

• 确认root路径：在对应location块里查root或alias值，然后用ls -l /your/root/path/index.html核对文件修改时间
• 检查Nginx运行用户：用ps -aux | grep nginx看worker进程以哪个用户运行，再用sudo -u nginx ls /your/root/path测试能否读取
• 留意SELinux或AppArmor：CentOS/RHEL上可能因安全模块拦截，临时用setenforce 0测试是否与此有关