translate="no" 是最轻量且兼容性最佳的禁译方式，但需配合正确 lang 值、加在关键元素（如代码名、路径、版本号、日期、命令行）上，并注意动态内容与第三方组件需手动补全，否则仍可能被 Chrome 翻译。
translate="no" 是目前最轻量、浏览器支持最稳的禁译手段，但它不是万能开关——用错位置、配错 lang、漏掉动态内容，都会让它形同虚设。
哪些元素必须加 translate="no" 才算真正防住
不是所有英文都该锁死。真正需要保护的是那些大小写、符号、顺序一变就失效的内容：
-
fetch()、useState、props.children这类函数名/变量名，被译成“获取()”或“使用状态”就彻底失去技术含义 -
/api/v1/users/:id、user_abc123、XZ-3000这类路径、ID、编号，翻译会破坏结构语义甚至导致 404 -
v5.2.0、React 18.3这类版本号，数字+点一旦变成“五点二零”就无法被开发者识别 -
<time datetime="2024-06-15" translate="no">2024/06/15</time>外层加translate="no"，避免日期被转成本地格式（如“2024年6月15日”）干扰机器解析 -
<input value="API_KEY" translate="no">和<textarea translate="no">npm install -D vite</textarea>，它们的value不继承父级设置，必须单独加
为什么写了 translate="no" 还被 Chrome 翻了
Chrome 只在首次解析 HTML 时读取该属性，且依赖上下文可信度。常见失效原因：
-
<html>标签上没写，或写成了translate="false"/translate=""—— Chrome 只认字面值"no" -
lang值缺失、写错或矛盾：比如中文页面写lang="en"，或只写lang="zh"（缺区域码），Chrome 会判定语言不可信，直接忽略translate="no" - 动态插入的节点（如
innerHTML或appendChild()添加）不会自动继承，必须手动补translate="no" - 第三方组件库（如 Ant Design）渲染出的 DOM 可能自带
translate属性，覆盖前得 inspect 实际输出，不能只看模板源码
translate 和 lang 必须一起用，但各管各的事
lang 声明语言归属，translate 控制是否允许翻译——两者不互换，也不替代。
立即学习“前端免费学习笔记（深入）”；
-
<div lang="en">React</div>→ Chrome 仍可能翻成“反应”，因为没下禁译指令 -
<div translate="no">React</div>→ 若页面lang缺失或错配，Chrome 可能降级处理，照样翻 - 正确写法：
<div lang="en" translate="no">React</div>，显式声明语言 + 显式关闭翻译 -
<html lang="zh-CN" translate="no">是整页禁译最稳组合，但仅限初始 HTML 中声明；JS 后续赋值无效
别踩这些隐蔽坑
最容易被忽略的，是边界场景和继承例外：
-
<script>和<style>内部文本天生不被翻译，加translate属性纯属冗余 -
<select>的<option>文本受继承，但value属性值本身不参与翻译，无需额外处理 -
class="btn-primary"、data-testid="submit-btn"这类属性值不属于“可翻译文本”，不受translate影响，但若混在文本节点里（如<span>class="btn-primary"</span>），就得加translate="no" -
<meta name="google" content="notranslate">对 Chrome 内置翻译完全无效，只影响 Google 搜索页和部分插件，别把它当主力
真正难的不是加属性，而是判断「这段内容到底该不该锁死」——UI 文案（如 Submit）、表单提示（如 Invalid email）加了 translate="no"，反而会让中文化界面出现英文残留，这种错误比漏加更难排查。
