Proxy无法实现全路径捕获自动翻译，因其仅拦截JS对象属性访问，无法感知HTML硬编码、框架内联字符串、DOM批量写入及第三方库文本；可靠方案是MutationObserver配合DOM扫描与路径还原。
Proxy 无法实现真正意义上的“全路径捕获”自动翻译，强行用它做主干机制，会漏掉 DOM 中绝大多数文本，且在现代框架中极易引发副作用。
为什么 Proxy 拦截不到页面里实际显示的文本
Proxy 只能拦截对 JavaScript 对象属性的读写操作，比如 i18n.messages.home.title 这种显式访问。但它完全不感知以下场景：
- HTML 中硬编码的文本：
<h2>Dashboard</h2>—— 不经过任何 JS 对象，Proxy 根本看不到 - React/Vue 组件内未绑定响应式数据的字符串：
return <div>Loading...</div>—— AST 已编译为函数调用，不是对象属性访问 - 通过
textContent或innerHTML批量写入的节点内容 —— Proxy 不监听 DOM 属性变更 - 第三方库内部生成的文本（如 ECharts 图例、Monaco 编辑器提示、Canvas 绘制文字）—— 完全脱离 JS 对象路径
哪些地方 Proxy 看得见、但依然不可靠
只有当你把所有待翻译文本**显式组织成嵌套 JS 对象**，并**全程只通过点号访问路径**时，Proxy 才可能介入。例如：
const i18n = new Proxy({ en: { home: { title: 'Home' } } }, {
get(target, path) {
return translate(target.en[path]);
}
});
但这带来三个硬伤：
立即学习“前端免费学习笔记（深入）”；
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 必须提前把所有文本塞进这个对象 —— 失去“自动捕获”意义，变成手动维护键值对
- 无法处理动态拼接：
`Welcome, ${user.name}`这类模板字符串不会触发get拦截 - 一旦业务代码绕过该对象（比如直接写
'Settings'），翻译就彻底失效
真正能覆盖“全路径”的替代方案是什么
所谓“全路径”，本质是“所有用户可见文本的完整 DOM 路径 + 上下文”。可靠做法是放弃 Proxy 主导，改用：
-
MutationObserver监听 DOM 新增/更新，配合document.querySelectorAll('*')扫描文本节点 - 白名单过滤：跳过
script、style、textarea、pre等非 UI 文本容器 - 路径还原：用
node.getRootNode().documentElement.compareDocumentPosition(node)或递归parentNode构建唯一 CSS 路径（如body > div#app > main .header h1） - 防重机制：对已翻译过的节点打标记（如
data-translated="true"），避免重复处理
这也是 translate.js 实际采用的方式 —— 它不依赖对象劫持，而依赖渲染后、用户可见前的 DOM 时机。
如果非要保留 Proxy，它该放在哪一层
Proxy 唯一合理的位置，是作为**翻译结果缓存层**，而非文本捕获层：
- 接收来自 DOM 扫描的真实文本字符串（如
'Save changes'） - 用该字符串作 key，查缓存或调用翻译 API：
cache.get('Save changes') - 返回翻译后字符串，并记录原始路径用于调试（如
body > form button:first-child） - 不重写
textContentsetter，不包装Intl，不碰原型链 —— 避免破坏 Vue/React 的响应式或第三方库行为
复杂点在于：DOM 文本没有天然“路径 ID”，相同文案可能出现在多个位置；缓存需支持模糊匹配（如忽略空格、标点）、大小写归一化、占位符剥离（'User {name} logged in' → 'User {} logged in'）。这些都不是 Proxy 能自动解决的。
