XUnity.AutoTranslator采用Harmony补丁技术实现无侵入式翻译，通过Hook Unity引擎的UI渲染、资源加载和字符串构造三层.NET方法，在内存中动态拦截并替换文本，而非依赖JavaScript Proxy。
不能用 Proxy 实现基于全路径捕获的无侵入式多语言全自动翻译引擎——它根本捕获不到 Unity 游戏里的文本。
Proxy 无法拦截 Unity UI 渲染调用
Proxy 是 JavaScript 的语言级机制，只对 JS 对象属性访问有效。Unity 游戏（尤其是 IL2CPP 构建版本）运行在 .NET 运行时上，UI 文本渲染走的是 TextMeshPro.SetText()、UnityEngine.UI.Text.set_text() 等原生方法调用链，和 JS Proxy 完全不在一个执行环境里。试图在浏览器里用 Proxy hook 游戏内存或 Unity C# 方法，就像拿渔网捞海底火山喷发的岩浆——对象都不存在。
真实可行的路径是运行时方法补丁（如 Harmony），而非语言代理：
- Harmony 可以 patch
TextMeshPro.SetAlpha()或CanvasRenderer.SetColor()等底层渲染入口，顺带拿到待显示文本 - Proxy 在 Unity WebGL 构建中也仅作用于 JS 层胶水代码，对实际 UI 组件无感知
- 即使强行用 Proxy 包裹某个 JS 封装的“文本桥接对象”，只要游戏绕过该桥接（比如直接调用 C#）、或使用 AssetBundle 动态加载文本，就立刻失效
“全路径捕获”实际依赖的是资源加载钩子，不是对象代理
所谓“全路径”，指的是对 Unity 资源加载全流程的拦截点覆盖，例如：
Resources.Load<textasset>("Dialogues/quest_01")</textasset>AssetBundle.LoadAssetAsync<textasset>("items.json")</textasset>-
ScriptableObject.Instantiate()加载本地化表单
这些调用必须通过 XUnity.ResourceRedirector 模块 Hook Resources.Load 和 AssetBundle.LoadAsset 等底层 API 才能劫持——它们是 .NET 方法，不是可被 Proxy 代理的 JS 对象。配置里常见的 RedirectResources=true 或 HookAssetBundles=true，背后全是 IL 织入或函数指针替换，和 Proxy 无关。
真正起效的“无侵入”靠的是三重运行时注入，不是代理模式
XUnity Auto Translator 的无侵入性来自三个不可替代的运行时干预层：
- UI 渲染层：用 Harmony 补丁
TextMeshPro.SetText()和CanvasRenderer.SetVertices()，捕获每一帧要画的文本 - 资源加载层：Hook
Resources.Load和AssetBundle.LoadAsset，替换原始文本资源为翻译后版本 - 字符串构造层：针对
string.Format()或StringBuilder.Append()等动态拼接场景，需额外 patchString.Concat()或注入自定义格式化器
这三者全部发生在 .NET 运行时，且需适配 Mono/IL2CPP 两种后端。任何试图用 Proxy 替代其中任一环的行为，都会导致文本漏捕、格式错乱或直接崩溃——尤其在 TextMeshPro 使用 RichText 标签或动态字体图集时，Proxy 根本看不到最终合成的渲染文本。
真正需要关注的，是 Harmony 补丁的稳定性、缓存命中率（CacheTranslations=true）、以及翻译服务响应延迟（MaxTranslationDelayMs=80）——这些参数直接影响“全自动”是否卡顿、是否漏翻。Proxy 在这个技术栈里，连配角都算不上。
