HTML文件不能加contenthash后缀，因其作为入口调度页需实时更新以确保data-i18n等新键生效，且避免引用旧哈希JS导致404；必须设no-cache+ETag协商缓存，而JS/CSS/字体等静态资源才应加contenthash并配immutable强缓存。
HTML静态资源本身不参与国际化加载——真正要加载、切换、校验的，是语言包（JSON）、字体（woff2）、图标（SVG）等外部资源；HTML文件只负责调度和承载，必须保持无哈希、走协商缓存。
为什么 HTML 文件不能加 contenthash 后缀
加哈希后缀（如 index.a1b2c3.html）会导致每次构建生成新文件名，但 HTML 是入口调度页：它引用的 JS/CSS 路径写死在源码里，若 HTML 本身也变名，CDN 或浏览器缓存中旧 HTML 仍会请求旧哈希的 JS，而该 JS 可能已被清理，引发 404。更关键的是，HTML 必须每次都能被用户拿到最新版本——比如新增了 data-i18n="footer.copyright"，旧 HTML 不知道这个键，就漏翻译。
所以 HTML 必须：
• 响应头设 Cache-Control: no-cache
• 配合 ETag（基于文件内容生成）做协商缓存
• 绝对不加任何哈希后缀或版本号参数（如 ?v=1.2.3）
JS/CSS/字体等静态资源必须加 contenthash 并配 immutable
这些资源一旦发布，内容不变就不该被重复下载。加 contenthash（Webpack/Vite 默认支持）可确保：内容变 → 文件名变 → 浏览器强制拉新；内容不变 → 文件名不变 → 复用强缓存。
立即学习“前端免费学习笔记（深入）”；
实操要点：
• 输出路径如 js/app.a1b2c3.js、fonts/inter.45d6e7.woff2
• HTTP 响应头设 Cache-Control: public, immutable, max-age=31536000
• ETag 必须与文件内容严格一致（不能是 mtime 或 inode），否则协商缓存失效
• HTML 中引用这些资源时，路径必须由构建工具自动注入（如 Webpack 的 HtmlWebpackPlugin），不能手写硬编码
语言包（locales/*.json）的加载与缓存怎么配才安全
语言包是纯数据，体积小、更新频次高，既不能强缓存（否则改了文案用户看不到），也不能完全不缓存（重复 fetch 拖慢切换）。折中方案是：
• 路径固定为 ./locales/zh-HK.json 这类 BCP 47 格式，不带 hash
• 响应头设 Cache-Control: no-cache, must-revalidate
• 依赖 ETag 协商：服务端每次返回 JSON 时，根据文件内容生成 ETag，客户端带 If-None-Match 请求，命中则返回 304
• 若用 CDN，需配置忽略查询参数、透传 ETag，并禁止对 .json 后缀做默认强缓存
常见翻车点：
• 用 fetch('./locales/en.json?v=' + Date.now()) 伪刷新 → 绕过 ETag，浪费带宽
• 服务端返回 Content-Type: text/plain → 浏览器拒绝解析 JSON，response.json() 抛错静默失败
• 语言包字段不齐（如 zh.json 缺 "form.required" 键）→ JS 查不到 key 就留空，UI 出现“undefined”
字体和图标资源的多语言适配要注意什么
字体不是“翻译对象”，但不同语言需要不同字重、字形覆盖范围。比如中文字体需包含 GB2312/Unicode 扩展区，阿拉伯语需支持连字（ligature），日文需对应 JIS X 0208 字符集。实际中：
• 不要用单一 Inter.woff2 打天下；按语言分发字体子集（如 inter-zh.woff2、inter-ar.woff2）
• CSS 中用 @font-face + unicode-range 精确控制加载范围
• 图标 SVG 若含文字（如带“EN”标签的设置图标），应剥离文本、改用 <title></title> 或 aria-label 描述，再由 i18n runtime 动态注入对应语言 label
• 所有字体/图标资源仍需加 contenthash + immutable，因为它们属于静态资源，变更极少且必须精准命中
最易被忽略的一点：语言包的 ETag 和 HTML 的 ETag 必须独立生成、各自协商——不能共用同一套哈希算法或缓存策略。前者决定文案是否更新，后者决定页面结构是否更新，混在一起就会出现“HTML 已更新，但语言包还在用旧版”的错位现象。
