最稳妥做法是将translate.js置于</body>前并在DOM解析完成后执行；动态内容需启用translate.listener.start()；Vue/React中应封装为生命周期可控的逻辑单元；须显式指定服务通道如server.baidu并配置私有代理。
直接引入 translate.js 就能跑，但得选对加载时机
页面 DOM 尚未就绪时调用 translate.execute() 会导致部分元素漏译，尤其是动态渲染的内容（比如 Vue/React 组件挂载后才插入的文本）。最稳妥的做法是把脚本放在 </body> 前，并确保在所有 HTML 解析完成后再执行翻译。
- 不要放在
<head>里，除非加defer或监听DOMContentLoaded - 如果页面有大量异步加载内容（如分页、懒加载模块），需配合
translate.listener.start()开启动态监控 - 使用构建工具（Webpack/Vite）时，避免把
translate.js打包进主 bundle——它本身是独立运行的客户端脚本，直接 CDN 引入更合理
Vue/React 项目里别用全局 script 标签硬塞
在现代框架中，直接在 index.html 里写两行 <script> 看似省事，但会绕过框架生命周期，导致组件卸载后翻译残留、重复初始化、或与 SSR 冲突。推荐封装成可控制的逻辑单元。
- Vue 中：在
main.js或根组件mounted钩子中调用translate.execute()，并用onBeforeUnmount清理监听器（如有） - React 中：用
useEffect控制初始化和销毁，避免多次执行translate.execute() - 注意：
translate.js默认会操作整个document.body，若只希望翻译某块区域（如弹窗、侧边栏），需提前用translate.config.setScope(selector)限定范围
翻译服务通道选错会导致白屏或超时
translate.service.use('client.edge') 和 translate.service.use('server.baidu') 表现差异极大。前者走浏览器内置 Edge 翻译 API，快但依赖用户本地系统语言设置；后者走服务端百度翻译，稳定但需配置密钥且有调用量限制——而默认不设服务时，它会自动 fallback 到 client.edge，但某些内网环境或旧版 Edge 浏览器可能根本不支持。
- 国内生产环境建议显式指定
translate.service.use('server.baidu')并私有部署后端代理，避免前端暴露密钥 - 开发阶段可用
translate.service.use('mock')模拟响应，防止调试时被限流打断流程 - 检查控制台是否报
Failed to execute 'fetch' on 'Window'或Edge Translation API not available，这是服务通道失效的明确信号
HTML 注释和代码块不会被翻译，但自定义标签容易误伤
translate.js 默认跳过 <pre>、<code> 和 HTML 注释（<!-- ... -->），这点很安全。但它会处理所有带文本节点的元素，包括你用来做语义标记的自定义标签（比如 <lang-zh> 或 <i18n>），一旦这些标签没设 display: none，就会被当成普通文本渲染出来。
立即学习“前端免费学习笔记（深入）”；
- 若要用自定义标签做 i18n 占位符，务必加 CSS 隐藏：
lang-zh, i18n { display: none; } - 想保留注释双语对照？不行——它压根不读注释，得用其他方案（比如正则提取 + CLI 批量翻译）
- 表格
<th>和表单<label>默认会被翻译，但<input placeholder>需手动启用：translate.config.enablePlaceholder = true
真正难的是让翻译行为和工程链路对齐：构建时要不要预生成多语言 HTML？CI 流程里怎么校验翻译完整性？这些不是 translate.js 能解决的，得靠你把它的触发时机、作用域、错误回调真正嵌进自己的构建和测试环节里。
