关键是要对齐浏览器缓存、CDN缓存与资源变更节奏：用文件名哈希固化版本，CDN精准设TTL，再配合刷新与预热；按类型差异化缓存JS，源站响应头必须兜底。
要在 CDN 加速节点上让 JavaScript 资源既缓得稳、又更得快，关键不是“全开缓存”或“一刷了事”，而是把浏览器缓存逻辑、CDN 缓存层级、资源变更节奏三者对齐。核心是：用文件名哈希固化版本，靠 CDN 精准控制 TTL，再配合刷新与预热补足时效缺口。
按文件类型设置差异化 CDN 缓存时间
JS 文件不是铁板一块，得分类管理：
-
带哈希的构建产物（如
app.8a3f2d.js）：内容不变则文件名不变，可放心设为Cache-Control: public, max-age=31536000, immutable，CDN 缓存 1 年，浏览器也不再发协商请求 -
通用第三方库（如
lodash.min.js）：不带哈希但更新频率低，建议 CDN 缓存 30 天，并开启ETag + Last-Modified校验，确保版本升级后能及时回源拉取 -
无哈希入口文件（如
main.js或runtime.js）：它是其他 JS 的调度中心，必须短缓存——CDN 设max-age=300（5 分钟），甚至配合no-cache强制每次校验，避免旧入口加载错版模块
刷新策略：精准失效，不伤全局
发布新版本 JS 后，不能等缓存自然过期，要主动干预：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 只刷新变更的 URL，例如
https://cdn.example.com/js/app.9b4e1c.js，避免用目录级刷新（如/js/*）误伤其他稳定资源 - 若使用 Webpack/Vite 构建，每次打包生成新哈希，可结合 CI/CD 脚本自动调用 CDN Purge API，提交本次发布的全部 JS URL 列表
- 刷新后立刻验证：打开浏览器开发者工具 → Network → 找对应 JS 请求 → 查看响应头中是否有
x-cache: HIT（刷新前）和x-cache: MISS（刷新后首次）及再次访问是否变回HIT
预热策略：提前铺路，避开首屏抖动
尤其适用于大体积 JS、活动页、灰度发布场景：
立即学习“Java免费学习笔记（深入）”；
- 在正式上线前 10–30 分钟，将新版 JS 的完整 URL 列表提交给 CDN 预热接口，让边缘节点主动回源拉取并缓存
- 预热优先覆盖高流量区域节点（如华东、华北、美西、欧洲），CDN 控制台通常支持按地域筛选或设置权重
- 预热不是“推”而是“拉”：CDN 模拟用户请求发起 HTTP GET，因此源站必须已部署新文件、且返回正确缓存头（
Cache-Control和ETag）才能被有效缓存
源站响应头必须兜底
CDN 不会替你决定能否缓存——它严格遵循源站返回的 HTTP 头：
- 确保 Nginx / Express / 任意后端对 JS 资源返回：
Cache-Control: public, max-age=31536000, immutable
ETag: "sha256-abc123..."
Content-Type: application/javascript - 若源站返回
Cache-Control: no-store或动态头（如含Set-Cookie），CDN 将直接跳过缓存，所有请求都会回源 - 检查方式：curl -I https://your-origin.com/js/app.js，确认响应头符合预期
