Chrome自动翻译会实际改写DOM文本节点，唯一有效拦截方式是初始HTML中<html>标签的translate="no"且需配合法语种lang值；动态设置、meta标签、错误属性值均无效，input/textarea的value需单独设translate="no"。
Chrome 的自动翻译不是“建议”，而是会实际改写 DOM 文本节点；translate="no" 是唯一被它真正识别的硬性拦截开关，不是可有可无的提示。
为什么 translate="no" 写在 <html> 上有时没用
它必须出现在初始 HTML 的 <html> 标签中，且需配合可信的 lang 值（如 lang="zh-CN"）才能稳定触发。JS 后续执行 document.documentElement.translate = "no" 完全无效——Chrome 只在首次解析 HTML 时读取该属性。
- 动态插入的节点（如通过
innerHTML或appendChild()添加）不会继承父级translate状态，必须手动补上translate="no" - 若页面
lang值缺失、写成lang="zh"（缺区域码）或与实际语言明显矛盾（如中文页写lang="en"），Chrome 可能直接忽略translate="no" -
<meta name="google" content="notranslate">对 Chrome 内置翻译功能无效，仅影响 Google 搜索结果页和部分插件
<input> 和 <textarea> 的 value 为什么总被误译
它们的 value 属性值不继承父元素的 translate 设置，是明确的例外。即使整个 <form> 都设了 translate="no"，里面的 <input value="XZ-3000"> 仍可能被翻成“某物-三千”。
- 必须单独为每个需要保护的
<input>或<textarea>加translate="no" - 若 value 是 JS 动态赋值（如
el.value = "v5.2.0"），得同步调用el.setAttribute("translate", "no") -
<select>的<option>文本受继承，但value属性值本身不参与翻译，无需额外处理
哪些内容真该加 translate="no"，哪些纯属浪费
不是所有英文都该锁死。重点保护的是语义固定、大小写/符号敏感、机器可读优先于人类可读的内容。
立即学习“前端免费学习笔记（深入）”；
- 必须加：
fetch()、useState、/api/v1/users/:id、v5.2.0、XZ-3000、datetime="2024-06-15"外层 - 不该加：按钮文字（
Submit）、提示文案（Invalid email）、菜单项（Settings）——这些本就该被翻译，加了反而导致中文化界面混入英文残留 - 第三方组件库（如 Ant Design）输出的 DOM 可能自带
translate，覆盖前务必 inspect 实际渲染的 HTML，不能只看模板源码
translate 和 lang 混用时最常踩的坑
lang 不控制是否翻译，只声明当前语言；translate 才决定是否允许翻译。两者职责分离，但必须协同生效。
-
<div lang="en">React</div>→ Chrome 仍可能把它译成“反应”，因为没禁译指令 -
<div lang="zh-CN" translate="no">React</div>→ 明确表示“这是中文环境下的一个不可翻译的英文词” - 写
translate="false"或translate=""都无效——Chrome 只认字面值"no"和"yes"，其他值全部忽略
最容易被忽略的其实是动态内容：v-html 渲染的字符串里若含 translate="no"，它依然生效；但若你靠 JS 拼接 HTML 字符串却忘了写这个属性，那段内容就裸奔了。别等客户截图投诉“XZ-3000 被翻成‘型号三零零零’”才想起查 DOM。
