语言包JSON文件必须纳入Git跟踪并作为核心资产统一管理，严禁离线导出或忽略提交；需强制校验data-i18n键存在性、版本化i18n运行时逻辑、部署时绑定哈希校验以确保线上一致性。
语言包 JSON 文件必须用 Git 跟踪，不能只存本地
语言包（zh.json、en.json、ja.json）是国际化的核心资产，不是“配置文件”，而是产品文案的正式交付物。它们必须和源码一起纳入 Git 仓库，且每次文案变更都要提交——否则上线后发现翻译漏译、错译，根本没法回溯是谁改的、哪天改的、改了什么。
- 禁止把语言包放在
public/lang/下却忽略.gitignore规则，导致实际未被提交 - 禁止用“导出 Excel → 手动转 JSON”这种离线流程，中间环节无法审计
- 推荐在
src/i18n/locales/下按语言+版本组织，例如zh-v2.3.json，便于灰度发布时比对
HTML 模板里的 data-i18n 属性变更要同步更新语言包键名
当你改了 <h2 data-i18n="user.profile.title"></h2> 为 user.settings.title，不只是改 HTML —— 必须立刻在所有语言包里删掉旧键、补上新键。Git 提交时若只改了 HTML，CI 流程应自动校验：所有 data-i18n 值是否在当前语言包中存在，缺失则报错阻断构建。
- 可用简单脚本提取全部
data-i18n值，生成keys.txt，再用jq检查每个 JSON 是否覆盖全部 key - 不要依赖人工核对，尤其当项目有 5+ 种语言、200+ 翻译键时，漏一个就会导致线上空白文本
- 如果用了模块化拆分（
common.json、form.json），更要检查跨文件引用一致性
切换逻辑 JS 文件本身要版本锁定，避免 runtime 行为漂移
负责加载语言包、遍历 data-i18n、调用 textContent 更新的那段核心 JS（比如 i18n.js），行为变化会直接影响所有语言渲染结果。它不能随心所欲迭代，必须像 API 一样管理兼容性。
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
- 重大变更（如从同步加载改为
Promise.all并行加载）需升主版本号，并在文档中标明“v2.x 不兼容 v1.x 的 fallback 逻辑” - 禁止在不改版本号的前提下，悄悄修改
document.documentElement.lang设置时机或默认 fallback 链（URL → localStorage → navigator.language） - 建议把该文件放入
src/i18n/runtime/，并用 ESM 导出明确接口，避免直接操作 DOM 的散装函数
备份 ≠ 归档：生产环境语言包必须带哈希校验
部署时拷贝的 en.json 和你本地 Git 提交的是否一致？靠肉眼或文件名无法保证。真正可靠的备份，是在构建阶段生成语言包内容的 SHA-256，写入 manifest.json 或注入 HTML 的 data-i18n-hash 属性。
立即学习“前端免费学习笔记（深入）”；
- 上线后可通过浏览器控制台执行
fetch('/lang/en.json').then(r => r.text()).then(t => console.log(crypto.subtle.digest('SHA-256', new TextEncoder().encode(t))))对比 - CDN 缓存失效策略应绑定语言包哈希，而非固定 TTL，避免旧包被长期缓存
- 不要把“备份”理解成定期 zip 压缩整个
lang/目录——没校验值的压缩包，等于没备份
