translate="no"必须加在直接包裹目标文本的元素上才真正起作用，如fetch()；加在父容器（如或）上无效，且的value、内容不继承该属性，须单独设置。
translate="no"加在哪才真正起作用
必须加在直接包裹目标文本的元素上，不能靠父容器“继承”来偷懒。比如fetch()要防翻译，就得写<code translate="no">fetch()，而不是给外层<div>加。常见错误是把<code>translate="no"放在<form></form>或<section></section>上，结果按钮里的React 18.3照样被译成“反应 18.3”。<input value="API_KEY">和<textarea></textarea>更特殊——它们的value属性完全不继承父级设置，必须单独加translate="no"。
哪些内容非加不可，哪些加了反而坏事
只锁那些“一翻就错”的内容：大小写敏感的函数名（useState）、含符号的路径（/api/v1/users/:id）、版本号（v5.2.0）、CSS类名（btn-primary）、时间字符串（<time datetime="2024-06-15" translate="no">2024/06/15</time>）。但别给<button>Submit</button>加——它本该随页面语言切换，加了反而让用户看到中英文混杂的界面。品牌词如Stripe、Apple Pay可以加，但若按钮文案本身需本地化（比如“支付”），就得拆开处理：用data-brand存品牌名，CSS ::after注入显示。
为什么写了translate="no"还是被Chrome翻了
三个硬伤最常被忽略：
— lang值缺失或矛盾：中文页没写lang="zh-CN"，或写了lang="en"却放中文内容，Chrome会判定语言不可信，直接无视translate="no"
— 动态插入节点没补属性：JS用innerHTML或appendChild()加的新元素，必须手动调用el.setAttribute("translate", "no")
— 属性值写错：Chrome只认字面值"no"，写成"false"、"off"或空字符串都无效
验证是否生效不能只靠肉眼
右键菜单里“翻译成中文”变灰 ≠ 真的锁住了。真正要测的是开启Chrome全页自动翻译后，目标文本是否变化。更可靠的做法：
— 打开DevTools → Elements面板，确认目标元素上真实存在translate="no"属性（不是JS临时加又删了）
— 在地址栏输入chrome://settings/languages，确保“提供网页翻译”已开启，并添加英语为可翻译语言
— 检查第三方组件（如Ant Design）实际渲染出的DOM，它们可能自带translate策略，覆盖你的设置
最易被忽略的点是动态内容和第三方组件输出——它们不会自动继承，必须手动补；而lang和translate必须同时存在且语义一致，缺一不可。
