translate="no"仅在Chrome 104+、Firefox 115+、Safari 16.4+中有效，作用于、等文本容器及、可见文本，对表单控件、placeholder、SVG text及JS动态文本无效，且具有单向继承性。
translate="no" 在现代主流浏览器中基本可用，但存在关键兼容性断层：Chrome 104+、Firefox 115+、Safari 16.4+ 原生支持；Edge 基于 Chromium 版本同步跟进；而 Safari 16.3 及更早版本完全忽略该属性，且所有浏览器在表单控件（如 <input>、<textarea></textarea>）上均不生效。
哪些元素上 translate="no" 真正起作用
它只对**文本内容可被浏览器自动识别并触发翻译建议的 HTML 元素**有效，典型场景包括：
-
<p></p>、<div>、<code><span></span>、<h1></h1>~<h6></h6>等包裹纯文本或内联文本的容器 -
<button></button>的可见文本（非value属性值） -
<label></label>中的文本内容 -
不生效的典型情况：
<input placeholder="Search">中的placeholder文本、<option></option>的文本、SVG 内的<text></text>、以及任何通过 JavaScript 动态插入的文本（除非 JS 显式设置该属性） - Google Chrome / Edge：不再在右键菜单显示“翻译成中文”选项，且页面级翻译工具栏（如 Google Translate 插件）会跳过该节点及其子树
- Firefox：同样抑制右键翻译入口，但部分旧版对嵌套子元素处理不一致（建议避免在
translate="no"容器内混用translate="yes"） - Safari：仅从 16.4 开始遵守；此前版本即使写了也完全当不存在，且无降级提示
-
注意：
translate="no"不阻止机器翻译 API 调用，也不影响开发者手动调用翻译服务 - 对关键文本（如品牌名、代码片段），改用
<code>或<var></var>语义化标签——多数翻译工具默认跳过这类元素 - 用 CSS
text-rendering: optimizeLegibility+ 字体微调虽不能禁翻译，但可降低自动识别置信度（非常规手段，慎用） - 服务端渲染时，对必须禁译的字段加注释
<!-- no-translate -->，配合前端脚本扫描并动态补translate="no"（适用于已知 DOM 结构） - 最稳妥的做法：将敏感文本转为图片或 SVG 文本（牺牲可访问性与 SEO，仅限极少数 logo 类文案）
translate="no" 和 translate="yes" 的行为差异
浏览器默认对大多数元素启用翻译（等价于 translate="yes"），但显式设为 "no" 后：
替代方案与兜底策略（当兼容性不可控时）
若需覆盖 Safari 16.3–16.3.1 或旧 Firefox，不能只依赖 translate 属性：
真正容易被忽略的是：该属性对 contenteditable 区域无效，且一旦父元素设为 translate="no"，子元素无法再用 translate="yes" 激活翻译——这个继承规则是单向强制的。
