37. 代码混淆与保护

本节目标

明白编译后的 Go 二进制里到底能被看到什么
会用 -obfuscated 生成混淆构建，会用 -garbleargs 调参数
理解混淆模式下绑定从「名字调用」变成「ID 调用」意味着什么
知道哪些前端写法会在混淆后失效，怎么改
分清混淆能解决什么问题、不能解决什么问题

37-1 编译后的程序并不是黑盒

Go 编译出来的是机器码，看着挺安全。但拿 strings 命令扫一遍二进制，你会发现能看到不少东西：

所有函数和方法的完整名字，包含包路径
结构体字段名（因为反射需要它们）
代码里写死的字符串常量
编译机上的源码文件路径

对 Wails 应用来说还多一层：绑定给前端的 Go 方法，名字会原样出现在 window.go.main.App 这个对象上。谁打开 DevTools 都能列出你后端所有可调用的方法。

如果你的应用里有授权校验逻辑、私有算法、或者不想暴露的接口地址，这些信息摆在明面上确实不太舒服。

Note

先把预期放平。混淆是提高逆向成本，不是让代码变成不可破解。有能力有动机的人照样能分析出来，只是需要更多时间。真正的敏感逻辑（比如授权验证的最终判定）应该放在服务端。

37-2 一条参数开启混淆

Wails 集成了 garble，一个 Go 代码混淆工具。用法就一个参数：

wails build -obfuscated

用之前要先装 garble：

go install mvdan.cc/garble@latest

装完确认 garble 在 PATH 里，garble version 能跑通。Wails 是通过调用这个命令来完成混淆的，找不到就会报错。

混淆构建的耗时明显比普通构建长，因为 garble 要重写整个依赖树的代码。项目大的话翻几倍很正常，别以为是卡住了。

37-3 用 garbleargs 调整混淆强度

默认参数是 -literals -tiny -seed=random。想改的话：

wails build -obfuscated -garbleargs "-literals -tiny -seed=myrandomseed"

三个常用选项各自的作用：

-literals —— 混淆字符串常量。代码里的 "https://api.example.com" 不再以明文形式出现在二进制里，而是变成运行时计算出来的值。想藏接口地址、密钥格式之类的东西，这个必开。

-tiny —— 精简模式，去掉更多元信息，产物更小。副作用是 panic 时的堆栈信息几乎不可读，出问题排查会很痛苦。

-seed —— 混淆用的随机种子。默认 random 表示每次构建都用新种子，同一份代码编两次产物不一样。

种子这里有个取舍。用 random 安全性更好，但破坏了构建的可复现性。想要「同样的代码编出同样的产物」，就固定一个种子：

wails build -obfuscated -garbleargs "-literals -seed=A1B2C3D4E5F6"

Warning

固定种子要当密钥管，别提交到公开仓库。种子泄露会让混淆的效果打折。CI 里通过 Secrets 注入是比较合理的做法。

37-4 混淆模式下绑定机制变了

这是本章最需要注意的一点，也是最容易出事的地方。

普通构建：绑定的 Go 方法挂在前端的 window.go 上，调用时用完整限定名。比如 main 包 App 结构体的 Greet 方法，前端通过 window.go.main.App.Greet 触发，底层传的就是这个名字。

混淆构建：方法名已经被 garble 改掉了，用名字调用当然找不到。所以 Wails 改用 ID 来标识每个绑定方法。wailsjs 目录下生成的绑定文件会带上这些 ID，调用机制随之更新。

结论很直接：混淆模式下，前端必须使用 wailsjs 目录下自动生成的绑定。

正确写法：

import { Greet } from "../../wailsjs/go/main/App";

function App() {
  const handleClick = async () => {
    const msg = await Greet("World");
    console.log(msg);
  };

  return <button onClick={handleClick}>打招呼</button>;
}

这样写，构建时绑定文件会用 ID 重新生成，调用能对上。

会出问题的写法：

// 混淆构建后失效
const msg = await window.go.main.App.Greet("World");

直接摸 window.go 在普通构建下能跑，混淆之后方法名对不上，运行时报找不到函数。

Tip

就算暂时不打算混淆，也建议一律从 wailsjs 导入。有类型提示、有 JSDoc、重构时 IDE 能跟着改，好处不止「兼容混淆」这一条。团队里定成规范，以后想开混淆就是加个参数的事。

37-5 把配置写进 wails.json

每次敲一长串参数不现实，写进项目配置：

{
  "name": "myapp",
  "outputfilename": "MyApp",
  "obfuscated": "true",
  "garbleargs": "-literals -tiny -seed=random"
}

配好之后普通的 wails build 就会走混淆流程。

不过这样一来，日常开发时的构建也变慢了。实际项目里常见的做法是配置文件里不开，只在发布脚本里加参数：

# 日常构建
wails build

# 发布构建
wails build -clean -trimpath -obfuscated \
  -garbleargs "-literals -seed=$BUILD_SEED" \
  -platform windows/amd64

-trimpath 顺手加上，它能去掉二进制里的源码路径。这跟混淆是互补的——garble 管符号名，trimpath 管文件路径。

37-6 混淆的边界在哪里

搞清楚它能干什么、不能干什么，比会用参数更重要。

能做到的：

Go 侧的函数名、方法名、类型名被替换成无意义的短标识
开启 -literals 后，字符串常量不再明文可见
前端拿不到有语义的方法名，window.go 上看到的是一串 ID
提高静态分析的门槛，strings 扫一遍看不出什么

做不到的：

保护前端代码。garble 只处理 Go。你的 React 代码、业务逻辑、接口调用全在 JS 里，DevTools 一开就能看。前端要单独用 Vite 的压缩混淆处理。
防住动态调试。程序运行时的行为是真实的，抓包能看到网络请求，调试器能跟踪执行流程。
保护打包进去的资源。图片、配置文件、embed 的静态资源都是原样存在的。
替代真正的安全设计。授权校验放在客户端，混淆得再狠也只是拖延时间，把校验逻辑挪到服务端才是解法。

Warning

混淆后的程序被杀毒软件误报的概率会升高。加固过的二进制在启发式扫描里比较可疑，尤其是再叠加 UPX 压缩之后。对外分发前用 VirusTotal 之类的服务扫一遍，有误报就考虑做代码签名（第 35 章讲过）。

一个务实的组合拳：混淆保护 Go 逻辑 + 前端构建时压缩混淆 + 关键校验放服务端 + 代码签名建立信任。单靠哪一样都不够。

常见误区

没装 garble 就直接加参数。 Wails 会报找不到命令。先 go install mvdan.cc/garble@latest。

前端直接用 window.go 调用。 混淆后必然失效。改成从 wailsjs 导入。

开着 -tiny 还指望看懂崩溃日志。 精简模式把调试信息砍得很干净，线上出问题基本无从下手。要保留排查能力，就别加 -tiny。

把混淆当成安全方案的全部。 它只是提高门槛。真正的秘密不该出现在客户端。

混淆版本没做完整回归测试。 garble 重写代码可能触发一些边缘问题，尤其是重度使用反射的库。混淆构建必须当成一个独立的产物走完整测试，不能拿普通构建的测试结果糊弄过去。

小结

wails build -obfuscated 就是全部入口，配合 -garbleargs 调整强度。-literals 藏字符串，-tiny 减体积但牺牲可调试性，-seed 决定构建是否可复现。

混淆模式下绑定改用 ID 标识，所以前端必须走 wailsjs 生成的绑定文件。这条规则就算不混淆也值得遵守。

混淆保护的是 Go 侧的符号和字符串，保护不了前端代码、网络流量和嵌入的资源。把它当成防御体系里的一层，而不是唯一一层。

下一章讲手动构建——绕开 CLI，用原生 go build 把应用编出来。理解这条路，前面所有参数的行为你都能自己推导出来。