proxy无法实现真正意义上的“基于全路径捕获”的无侵入式多语言自动翻译引擎，因其仅能拦截js对象属性读写，无法覆盖html硬编码、dom操作、第三方库及canvas等场景；网页需mutationobserver+dom扫描，unity需harmony补丁，二者均依赖底层链路注入而非proxy。
Proxy 无法实现真正意义上的“基于全路径捕获”的无侵入式多语言自动翻译引擎，尤其在实际应用环境中——它不是技术选型问题，而是能力边界问题。
Proxy 的真实适用范围很窄
Proxy 只能拦截 JavaScript 中对普通对象属性的读写操作，例如：
-
i18n.zh.menu.home.title这类明确通过 JS 对象访问的键路径 - 配合
Reflect.get实现嵌套路径 fallback（如i18n['zh-CN'].dialog?.npc || i18n.fallback.dialog.npc）
但它完全无法触达以下常见场景：
- HTML 中硬编码文本：
<h2>Settings</h2>—— 不经过任何 JS 对象 - 批量 DOM 操作：
el.textContent = 'Loading...'或innerHTML赋值 —— Proxy 不监听 DOM 变更 - 第三方库内部字符串：ECharts 图表标题、Monaco 编辑器提示、Three.js UI 文字
- Canvas 渲染文字、Shader UI、SpriteFont 动态生成文本 —— 这些根本不在 JS 内存对象中
所谓“全路径”在网页端靠的是 DOM 扫描，不是 Proxy
真正覆盖页面全部可见文本的方案，是结合以下机制：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- MutationObserver：监听 DOM 新增/更新节点
-
document.querySelectorAll：遍历所有含文本的元素（
p、span、[data-i18n]等白名单） - textContent / nodeValue 提取 + 白名单过滤：跳过 script、style、input value 等干扰项
- requestIdleCallback：在浏览器空闲期执行翻译，避免阻塞渲染
这就是 translate.js 等成熟工具的实际做法 —— 它不依赖对象劫持，而依赖渲染后时机控制。
Unity 游戏场景中 Proxy 完全不可用
Unity 的文本渲染发生在 C# 层，比如 Text.text 或 TMP_Text.text。JS 环境中的 Proxy 根本无法访问或拦截这些字段：
- XUnity.AutoTranslator 使用的是内存级函数 Hook（如 Harmony 补丁），直接修改
Text.get_text的 IL 指令 - 它还依赖
XUnity.ResourceRedirector拦截 AssetBundle 加载，在资源解包时替换字符串 - 这些操作都在运行时注入，与 JS Proxy 所在的环境毫无交集
“无侵入式”的关键其实是控制时机，不是是否改代码
真正的无侵入，是指不修改原始业务逻辑文件，但必须在关键节点取得控制权：
- 网页侧：在 DOM 渲染完成、用户可见前，用
MutationObserver注入翻译 - Unity 侧：在
Text.get_text被调用前，用 Harmony Patch 拦截并返回翻译结果 - 两者都不改游戏或页面源码，但都需要在底层渲染链路中插入一层处理
试图用 Proxy 替代这些机制，会漏掉绝大多数文本，且无法保证一致性与实时性。
