translate="no" 是最直接有效的方案，因它是w3c标准属性，浏览器解析dom时即跳过翻译，兼容chrome/edge/firefox/safari，且比class="notranslate"更可靠稳定。
为什么 translate="no" 是最直接有效的方案
浏览器自动翻译通常会忽略带有 translate="no" 属性的 HTML 元素及其子内容。这不是 hack，而是 W3C 规范明确支持的属性，Chrome、Edge、Firefox（新版）、Safari 均已实现。它比 CSS 或 JS 干预更轻量、更可靠——因为翻译引擎在解析 DOM 时就跳过这些节点，不触发后续处理逻辑。
常见错误是写成 translate="false" 或 data-translate="no"，这完全无效。必须用原生 translate 属性，且值只能是 "no"（字符串，不是布尔值）。
- 对单个元素生效：
<div translate="no">版本号：v2.3.1</div> - 对整块区域生效：给最外层容器加该属性，内部所有文本自动继承（除非子元素显式设为
translate="yes"） - 避免套在
<script></script>或<style></style>内——它们本就不被翻译，加了也无意义
哪些地方必须加，哪些加了也没用
需要屏蔽翻译的典型内容包括：版本号、API 路径、代码片段、品牌名缩写（如 SDK、JWT）、时间格式（2024-05-20T14:30:00Z）。这些一旦被翻译，轻则语义错乱，重则导致功能异常。
但以下情况加了 translate="no" 也无效：
- 纯文本节点直接挂在
下（无包裹标签），浏览器无法挂载属性 → 必须用标签包裹 - 通过 JavaScript 动态插入的文本，若插入后未同步设置
translate="no"→ 需在插入 DOM 后立即设置属性，或在模板中预置 - 内联 SVG 中的
<text></text>标签内容 →translate属性对 SVG 元素无效，需改用<foreignobject></foreignobject>包裹或服务端预渲染
和 notranslate class 的区别在哪
class="notranslate" 是 Google Translate 早期使用的非标准约定，部分浏览器（如旧版 Chrome）曾兼容，但现在已被弃用。它依赖翻译工具“主动识别”这个 class 名，稳定性差，且对非 Google 翻译引擎（如 Edge 的 Bing Translator）基本无效。
而 translate="no" 是 HTML 标准属性，由浏览器原生解析，不依赖任何第三方翻译服务的实现逻辑。实测中，同一段代码在 Edge 和 Chrome 下，translate="no" 生效率 100%，class="notranslate" 在 Edge 中常被忽略。
- 不要混用：
<span class="notranslate" translate="no"></span>→ 多余，只留translate="no" - 不要指望 CSS 伪类或
content属性生效 —— 翻译发生在 DOM 解析阶段，不是渲染后 - 服务端渲染页面时，务必确保该属性随 HTML 一起下发，不要等到 JS 执行后再 patch
遇到翻译残留怎么办：检查 DOM 实际状态
有时明明写了 translate="no"，右键仍看到“翻译此段落”选项，或实际加载后部分内容被误翻。这时不是属性失效，而是 DOM 结构没覆盖到真实文本节点。
打开开发者工具，选中疑似被翻的文本，往上逐级查看父元素是否真的带有 translate="no"。特别注意：
- Vue/React 组件中，JSX 或 template 里写了属性，但最终渲染出的 DOM 可能被框架抹掉（比如 React 18 对未知属性默认过滤）→ 需用
domProps或dangerouslySetInnerHTML显式透传 - 富文本编辑器（如 TinyMCE、Quill）输出的 HTML，可能 strip 掉自定义属性 → 需配置其白名单，允许
translate - 某些 CDN 或 SSR 工具（如 Next.js 的
getStaticProps）会对 HTML 做 minify，意外删掉空格分隔的属性 → 检查构建后源码是否保留该属性
最稳妥的做法：在页面加载后，用 document.querySelectorAll('[translate="no"]') 检查是否真实存在，再结合 getComputedStyle 确认文本节点是否被正确排除。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
