gomobile bind 是最直接的 Android 工程集成方案，但易因环境配置疏漏导致运行时报 NoClassDefFoundError 或调用失败；关键在于 aar 能否被 Android Studio 正确解析链接，需确保 GOROOT/JAVA_HOME 显式生效、go mod vendor 前置、gradle 配置 transitive = true 且 repositories 指向正确 flatDir。
gomobile bind 是目前最直接、最贴近 Android 工程集成的方案，但它极易因环境或配置疏漏导致编译成功但运行时报 NoClassDefFoundError 或 Java 层调用失败。关键不在于“能不能编译”，而在于“生成的 aar 能不能被 Android Studio 正确解析并链接”。
gomobile init 失败：GOROOT 和 JAVA_HOME 必须显式生效
常见错误是终端里 go env GOROOT 有输出，但 gomobile init 仍报 GOROOT not set。这是因为 gomobile 启动时读取的是其父进程（如 shell）的环境变量，不是当前 shell 的临时设置。
- macOS 用户必须用
launchctl setenv GOROOT /usr/local/go（路径以go env GOROOT输出为准），然后彻底关闭所有终端窗口再重开 - Linux 桌面用户（GNOME/KDE）需在
~/.profile或~/.pam_environment中写入GOROOT DEFAULT=/path/to/go和JAVA_HOME DEFAULT=/path/to/jdk，否则 systemd user session 下的 Android Studio 无法继承 - 验证方式：新开终端后运行
env | grep -E "(GOROOT|JAVA_HOME)"，且该终端中执行gomobile init不报错才算真正就绪
gomobile bind 生成的 aar 缺少 Java 符号：go mod vendor 是硬性前置步骤
如果你的 Go 包依赖了其他模块（比如 github.com/sirupsen/logrus），gomobile bind 默认不会把依赖包的 Go 源码打包进 aar —— 它只打包当前 module 的源码，而 Java 层 wrapper 生成时又会按 import 路径硬编码 class 名。结果就是 Android 端一调用就 NoClassDefFoundError。
- 必须在执行
gomobile bind前运行go mod vendor，让所有依赖落地到本地vendor/目录 -
gomobile bind会自动识别并扫描vendor/，把所有实际参与编译的 Go 包路径映射为 Java 类路径（如github.com/sirupsen/logrus→github.com.sirupsen.logrus） - 不 vendor 的后果不是编译失败，而是 aar 内部 classpath 断裂，且无任何 warning 提示
Android Studio 找不到 aar 类：gradle 配置必须带 transitive = true
即使 aar 文件已放入 libs/ 目录，implementation(name: 'mylib', ext: 'aar') 仍可能让 IDE 显示 “Cannot resolve symbol Mylib” —— 这是因为 aar 自身声明的 classes.jar 未被自动展开为可索引的 source set。
- 必须显式启用传递依赖：
implementation(name: 'mylib', ext: 'aar') { transitive = true } - 确认
repositories块存在且指向正确：flatDir { dirs 'libs' }，注意不是libs/（末尾斜杠会导致路径解析异常） - Java/Kotlin 调用时类名严格按 Go module path 转换：若
go.mod里是module github.com/user/crypto，导出函数Encrypt()，则对应 Java 类是github.com.user.crypto.Crypto.Encrypt()，不是Crypto或crypto.Crypto
混用 Swift 时 framework 报 swiftCore 链接失败
用 gomobile bind -target=ios 生成 framework 后，在 Swift 项目中 link 成功但运行崩溃，典型错误是：ld: warning: Could not find or use auto-linked library 'swiftCore' 或 Undefined symbols for architecture arm64。
- 根本原因是 gomobile 生成的 framework 是纯 Objective-C 接口，不含 Swift 运行时；而你的 Xcode 项目启用了 Swift（
ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES = YES）且未主动 link Swift 标准库 - 解决方案只有两个：要么在 Xcode 的
Build Settings → Linking → Other Linker Flags中手动加-lswiftCore -lswiftFoundation（不推荐，版本耦合强）；要么改用gomobile build -target=ios生成完整 app bundle，绕过 framework 集成 - 这个坑只出现在 iOS + Swift + gomobile framework 三者共存时，Android 端完全不受影响
gomobile 的核心约束很朴素：它不处理跨语言 ABI 兼容性，也不封装构建上下文。你给它什么环境，它就产出什么产物；你漏掉 vendor，它不会提醒；你 JAVA_HOME 没进 launchd，它就卡在 init。真正的门槛不在语法，而在对构建链路每个环节的“可见性”——尤其是那些没报错却悄悄失效的配置。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
