我承认我之前偏见很大：看到有人说“91官网不对劲”，第一反应不是怀疑页面本身，而是怀疑浏览器、缓存、CDN这些看不见的中间人。后来亲自验证过几次，结论很明确——遇到莫名其妙的页面行为，先别急着骂站方或换浏览器，先从缓存管理查起（不服你来试）。
为什么先查缓存？
- 缓存遍布整个请求链：浏览器缓存、操作系统 DNS 缓存、本地代理、CDN、反向代理、服务器端缓存、以及开发者可能部署的 service worker。任何一环出问题，都能把“正常页面”变成“怪异页面”。
- 缓存导致的问题常表现为：旧资源被强制复用、内容不更新、样式错位、脚本逻辑不一致、403/500 与正常不同、1% 的用户出现异常等。排查缓存比重装浏览器更省时间。
快速自测清单（1–5 分钟内判断） 1) 用匿名/无痕窗口打开
- Chrome/Edge: Ctrl+Shift+N；Firefox: Ctrl+Shift+P。无痕模式绕过大量浏览器缓存和扩展干扰。 2) 强制刷新
- Windows: Ctrl+F5 或 Ctrl+Shift+R；macOS: Shift+Command+R。对加载的静态资源发起强制重新请求。 3) 添加时间戳强制不走缓存
- 在 URL 后加 ?ts=时间戳，例如 https://91***.com/?ts=202602201230。若页面立刻变化，说明缓存在作怪。 4) 用 curl 看响应头
- curl -I -L https://91***.com
- 关注：Cache-Control、Expires、Age、ETag、Last-Modified、Server、Via。Age 非零或 Cache-Control 表示中间层缓存。 5) 禁用浏览器缓存（开发者工具）
- 打开 DevTools（F12），Network 标签勾选 “Disable cache”，然后刷新。若问题消失，问题就是缓存。
系统与网络层面排查（中级）
- 清 DNS 缓存
- Windows: 在命令行运行 ipconfig /flushdns
- macOS (新版): sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
- Linux (systemd): sudo systemd-resolve --flush-caches 或重启 nscd：sudo /etc/init.d/nscd restart
- 检查 hosts 文件是否被篡改（有时为广告或拦截）
- Windows: C:\Windows\System32\drivers\etc\hosts
- macOS/Linux: /etc/hosts
- 检查本地代理或 VPN：临时断开 VPN 或代理，看问题是否存在。
- 查看是否被公司/学校/ISP 的缓存加速：切换到手机数据网络或用热点进行对比。
CDN 与服务器端缓存（站长向）
- 通过 curl 观察 Age 字段和 Via 字段，判断是否经过 CDN 或缓存节点。
- 若是静态资源（JS/CSS/图片），设置合理的 Cache-Control：静态资源采用长期缓存 + 版本号（Cache-Control: public, max-age=31536000），更新时改文件名或 querystring。
- 动态页面用 no-store 或 must-revalidate，避免 CDN 或客户端缓存误收紧。
- 使用缓存清理（Purge）API 或控制面板即时清除 CDN 缓存；不要只依赖短缓存时间来“解决问题”。
- 检查 ETag/Last-Modified 的生成逻辑，避免不同节点生成不一致的 ETag 导致 304 不正确。
- 注意 Vary 头（特别是 Vary: Accept-Encoding），错误配置会让缓存命中错乱。
- Service Worker：若站点注册了 service worker，旧版 SW 会拦截并返回缓存内容。DevTools → Application → Service Workers，执行 Unregister 并清除存储。
调试技巧（给喜欢动手的你）
- 比较两次请求的完整响应头：
- curl -I -L https://91***.com
- curl -I -H "Cache-Control: no-cache" -L https://91***.com 对比差异，看看是否返回 304、Age 或其它缓存相关字段。
- 模拟不同地理位置：用在线检测（webpagetest.org）或 curl 通过远程服务器测试，排除地域缓存问题。
- 用浏览器 Network 面板查看 Size/Time 列：
- 若显示 from disk cache 或 from memory cache，说明浏览器直接命中。
- 若看见 304 Not Modified，说明服务器/中间缓存在工作。
常见误判与真实原因（我踩过的坑）
- 以为是浏览器 bug，其实是被旧的 service worker 缓存住了。
- 以为站点被篡改，其实是 CDN 的某个 POP 节点没有同步新版本。
- 以为是 DNS 劫持，其实 hosts 被境外某工具默认修改导致。 这些都能通过上述步骤定位出来，省掉许多指责与焦虑。
给站长的建议（快速清单）
- 静态资源走长期缓存 + 文件指纹（hash）或版本号；动态页面短缓存或禁止缓存。
- 提供清晰的缓存策略说明文档，遇到问题时用户能按步骤清理浏览端缓存。
- 在部署流水线里自动触发 CDN purge 或采用智能更名策略，避免人工忘记清缓存。
- 监控 Age、304 比率与缓存命中率，发现异常及时回滚或清理。
结语——不服你来试 遇到“91官网不对劲”这类问题，先不要立刻怀疑人家的网站可信度。照着上面的顺序做几步检查：无痕窗口、强制刷新、时间戳、curl 看头信息、清 DNS、看 service worker。若经过这些步骤依然有问题，再去找站方或社区反馈：把你看到的 response headers、curl 输出、复现步骤贴上去，大家更容易定位。
最后一句挑战：下次遇到“某站不对劲”，先做三件事——无痕、新时间戳、curl -I，然后把结果贴上来，不信你试。