translate="no"需精准加在易误译的技术字符串上，如代码标识符、API路径、版本号、CSS类名等；它可继承但input/textarea的value和JS动态插入节点须手动添加；不可全局设于<html>标签。
直接加 translate="no" 是最有效、最轻量的方案，但必须加在具体元素上，不能靠猜哪些该标——只保护那些被翻译后会出错或失义的内容。
哪些技术字符串必须加 translate="no"
不是所有英文都要锁死，关键看是否「语义固定、大小写/符号敏感、机器可读优先」。被误译后会导致代码失效、路径 404、版本含义错乱时，才需要干预：
-
fetch()、useState、props.children——括号、点号、大小写一变，JS 就报错 -
/api/v1/users/:id、X-Auth-Token、user_email——斜杠、冒号、下划线是协议/字段定义的一部分 -
v5.2.0、React 18.3、TPM2.0——数字和点不能变成“五点二零” -
class="btn-primary"、data-testid="submit-btn"——CSS 类名和测试 ID 是运行时关键标识符 -
<time datetime="2024-06-15"></time>外层容器——避免机器把2024-06-15转成本地日期格式（如“2024年6月15日”）
translate="no" 的继承规则和常见漏点
它可继承，但有硬性例外：父元素设了 translate="no"，子元素默认也禁译；但以下情况必须手动补，否则照样被翻：
-
<input>和<textarea>的value值完全不继承——哪怕整个<form>都设了，也得单独给每个标签加translate="no" - JS 动态插入的节点（如
innerHTML或appendChild()添加）不会继承——必须手动调用el.setAttribute("translate", "no") -
<script>和<style>内部文本天然不参与翻译，加该属性纯属冗余 - 用
v-html或dangerouslySetInnerHTML渲染富文本时，translate属性仍生效，但前提是原始 HTML 字符串里已包含它——模板里写的没用
为什么不能全局加 translate="no" 到 <html>
看似省事，实则埋 UX 隐患：
立即学习“前端免费学习笔记（深入）”；
- 按钮文字如
Submit、提示文案如Invalid email全部跳过翻译，用户看到的是中文界面混着英文操作词 - 第三方组件库（如 Ant Design、MUI）输出的 DOM 可能自带
translate策略，你全局覆盖后行为不可控 - 旧版 Edge 或某些翻译插件对全局
translate="no"支持不稳定，局部精准控制更可靠 -
translate="no"必须出现在初始 HTML 的<html>标签中才可能生效；JS 后续执行document.documentElement.translate = "no"完全无效
最容易被忽略的是动态内容：JS 插入的新节点、CMS 输出的富文本、v-html 渲染块——它们不会自动继承，必须手动补属性。验证是否生效，别靠肉眼，直接打开 Chrome DevTools → Elements 面板，查目标元素上是否存在 translate="no" 属性。
