蘑菇影视官网更新后，页面或资源加载异常，常常不是“代码出错”，而是缓存没跟上。遇到“明明改了内容，用户却看到旧页面”“播放器或样式表现怪异”这类情况，先别慌——先检查下面两个地方，绝大多数问题都能在这里找到根源并解决。
一、前端缓存（浏览器 / CDN / Service Worker） 为什么会出问题
- 浏览器会缓存静态资源（JS、CSS、图片）以加速访问；更新了文件但文件名没变，浏览器很可能继续使用旧版本。
- 使用CDN分发站点时，CDN有自己的缓存策略，节点未及时刷新会把旧文件继续返回给用户。
- 如果站点用了Service Worker，可能会拦截并返回缓存内容，导致更新无效。
如何检查
- 打开浏览器开发者工具 → Network，勾选“Disable cache”（在DevTools打开时有效）后刷新，观察是否加载的是新文件。
- 用 curl 查看响应头：curl -I https://your.site/path/file.js，重点看 Cache-Control、Expires、ETag、Last-Modified 等字段。
- 检查响应头里是否有 CDN 标识或缓存标志（如 X-Cache、Age、Via 等），这些可以提示是否走了缓存层。
- 在浏览器中强制刷新（Windows: Ctrl+F5；Mac: Cmd+Shift+R）或用无痕窗口访问，排除浏览器本地缓存影响。
- 如果用了Service Worker，在浏览器的 Application（或 Storage）面板里查看并注销/更新 Service Worker。
如何解决
- 清理/刷新CDN缓存：在CDN控制台执行 purge（清除缓存）或按文件/路径批量清除。部分CDN提供 API，可在部署脚本中加入自动清理步骤。
- 采用资源指纹或版本号：把 JS/CSS/图片等文件名加上 hash 或版本号（例如 app.1a2b3c.js 或 app.v202601.js），每次部署更新时变更文件名，强制浏览器拉新资源。
- 合理设置 Cache-Control：静态资源可以长期缓存但要配合文件名版本化；HTML 页面可设置短缓存或 no-cache 以确保能及时拉取新引用的资源。
- 解除或更新 Service Worker：如果 Service Worker 拦截了旧资源，发布新版本时要在生命周期内激活并清除旧缓存；临时可在浏览器里 unregister 或发布一个空的 Service Worker 来强制更新。
二、后端缓存（服务器缓存 / 应用缓存 / 缓存层如 Redis、Memcached / Opcode Cache） 为什么会出问题
- CMS 或应用通常会使用页面缓存、片段缓存或对象缓存来提升性能，更新逻辑或模板后，如果缓存未清理，用户会看到旧内容。
- 反向代理（如 Varnish、Nginx 的 proxy_cache）或负载层缓存也会返回旧响应。
- PHP 的 Opcache、模板引擎缓存或其他进程内缓存可能导致新 PHP/模板代码未被加载。
如何检查
- 观察响应头中是否标注缓存来源：Varnish 可能有 X-Varnish、X-Cache；应用层缓存也可能带自定义头（X-Cache-Status 等）。
- 登录服务器或应用管理后台，查看缓存插件或缓存服务的状态（例如 Redis、Memcached 的 key 数量、最后写入时间）。
- 对比不同路径、不同用户（或清理 cookie 后）访问结果，确认是否是应用层的会话/用户缓存导致差异。
- 在服务器上重启或刷新缓存组件试验：如清空 Redis 缓存、重启 PHP-FPM、重置 Opcache，然后再访问看是否生效。
如何解决
- 在应用后台或部署脚本中加入清空缓存的步骤，针对所用缓存组件执行适当命令（例：Redis 可用 redis-cli DEL/FLUSHDB，缓存插件通常有“清除缓存”按钮）。
- 如果使用反向代理或 Nginx proxy_cache，使用相应的 purge/ban 命令或配置适当的缓存键策略。
- 对于 Opcache：在部署后执行 opcache_reset() 或重启 PHP-FPM/Apache，确保新代码被载入。
- 避免在生产环境使用过长的缓存 TTL（针对动态页面），或为动态内容设置条件缓存策略。
快速故障排查清单（可复制执行）
- 用无痕窗口或不同设备访问看问题是否复现（排除浏览器缓存）。
- 在 DevTools Network 中查看资源是否加载自 200（ok）还是 304（not modified）；304 表示浏览器走了条件请求，可能是缓存问题。
- curl -I 查看响应头，查找 Cache-Control、Age、X-Cache、ETag 等字段。
- 在 CDN 控制台执行一次 purge，或在部署后触发 CDN 清理 API。
- 登录服务器清空应用缓存、重启 PHP-FPM、Opcache 重置，或在部署脚本里加入缓存清理操作。
- 检查是否启用了 Service Worker，必要时注销或升级 Service Worker 脚本。
避免下次再被缓存拖后腿的建议（部署层面）
- 采用资源版本化（文件名带 hash），并在部署流程中统一更新引用。
- 部署脚本里自动触发 CDN 清理和后端缓存清空。
- 为不同类型资源设置合理的缓存策略：静态文件长缓存+版本化，HTML/动态接口短缓存或 no-cache。
- 对缓存层做好监控：记录缓存命中率、Age 值、CDN 分发延迟等，能更早发现问题。
结语 遇到更新后“缓存管理莫名其妙”的情况，先从前端缓存（浏览器/CDN/Service Worker）和后端缓存（应用/反向代理/Opcache）两大方向检查，按照上面的检查步骤执行一般能快速定位并解决。抓住“谁在返回旧内容”和“缓存在哪一层没被刷新”这两个核心，就能把问题迅速收拾干净。
