Proxy多语言自动翻译实现方法

本文深入剖析了Proxy在构建多语言自动翻译引擎时的根本局限性：它仅能拦截JavaScript对象属性的读写，完全无法覆盖HTML硬编码文本、DOM动态操作、第三方库UI、Canvas渲染及Unity等原生环境中的字符串，因此无法实现真正“全路径捕获”的无侵入式翻译；实际可行的方案依赖于更底层的时机控制——网页端依靠MutationObserver结合DOM扫描与空闲期翻译，Unity则需通过Harmony补丁直接HookC#层文本访问逻辑，二者虽不修改源码，却必须在渲染链路关键节点注入处理，揭示了“无侵入”的本质是控制权而非技术表象。

Proxy 无法实现真正意义上的“基于全路径捕获”的无侵入式多语言自动翻译引擎，尤其在实际应用环境中——它不是技术选型问题，而是能力边界问题。

Proxy 的真实适用范围很窄

Proxy 只能拦截 JavaScript 中对普通对象属性的读写操作，例如：

• i18n.zh.menu.home.title 这类明确通过 JS 对象访问的键路径
• 配合 Reflect.get 实现嵌套路径 fallback（如 i18n['zh-CN'].dialog?.npc || i18n.fallback.dialog.npc）

但它完全无法触达以下常见场景：

• HTML 中硬编码文本：

  Settings

  —— 不经过任何 JS 对象
• 批量 DOM 操作：el.textContent = 'Loading...' 或 innerHTML 赋值 —— Proxy 不监听 DOM 变更
• 第三方库内部字符串：ECharts 图表标题、Monaco 编辑器提示、Three.js UI 文字
• Canvas 渲染文字、Shader UI、SpriteFont 动态生成文本 —— 这些根本不在 JS 内存对象中

所谓“全路径”在网页端靠的是 DOM 扫描，不是 Proxy

真正覆盖页面全部可见文本的方案，是结合以下机制：

• 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 替代这些机制，会漏掉绝大多数文本，且无法保证一致性与实时性。

好了，本文到此结束，带大家了解了《Proxy多语言自动翻译实现方法》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！