gomobile init 失败主因是 GOROOT 或 JAVA_HOME 未显式设置，需用 launchctl（macOS）或 shell 启动脚本（Linux）固化环境变量，JDK 限 11/17；bind 生成 aar 需先 go mod vendor 并在 Gradle 中启用 transitive；iOS framework 需嵌入签名且禁用 Enable Testability；Go error 应转为结构体返回以保留错误信息。
gomobile init 失败：找不到 $GOROOT 或 JDK 路径
多数人卡在第一步，gomobile init 报错说 GOROOT not set 或 Failed to find Java SDK。这不是 gomobile 本身的问题，而是它依赖 Go 和 Java 环境的显式校验——它不会读取 shell 的动态环境变量，只认启动时就存在的值。
实操建议：
- macOS 上用
launchctl setenv GOROOT /usr/local/go（或你实际的go env GOROOT输出），然后重启终端；Linux 用户需确保在 systemd user session 或桌面环境启动脚本里导出GOROOT和JAVA_HOME - JDK 必须是 JDK 17 或 JDK 11（JDK 21 不支持），且
JAVA_HOME指向根目录（如/Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home），不是bin子目录 - 验证方式：在新终端中运行
gomobile version，成功才继续
gomobile bind 生成 aar 但 Android Studio 找不到符号
常见现象是 Android Studio 导入 .aar 后，调用 NewMyGoLib() 报红，提示 “Unresolved reference”，或者运行时报 NoClassDefFoundError: go/.../MyGoLib。本质是 gomobile 默认生成的 aar 缺少 Java 层 wrapper 的完整 classpath 依赖声明。
实操建议：
- 必须在
gomobile bind前执行go mod vendor，否则 aar 内部的 Go 包路径引用会断裂 - Android 端 gradle 中不能只写
implementation(name: 'mylib', ext: 'aar')，要额外添加transitive = true并确认repositories { flatDir { dirs 'libs' } }指向正确目录 - Java/Kotlin 调用时，类名是全路径：比如 Go 包叫
github.com/user/mylib，导出函数DoWork()，对应 Java 类就是github.com.user.mylib.Mylib（注意点号变斜杠再变点），不是按文件夹结构拼的
gomobile build 生成 iOS framework 后 Xcode 链接失败
Xcode 报 ld: warning: Could not find or use auto-linked library 'swiftCore' 或直接 Undefined symbols for architecture arm64，尤其在启用 Swift 并混用 Go 时高频出现。这是因为 gomobile 生成的 framework 是纯 Objective-C 接口，不带 Swift 运行时，而你的项目启用了 Swift 并设置了 ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES = YES。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
- iOS 工程 Build Settings 中关闭
Enable Testability（Debug only），该选项会注入 Swift 调试符号，与 Go framework 冲突 - 确保
VALID_ARCHS包含arm64和x86_64（模拟器），但不要加armv7——gomobile 不再支持 32 位 - 在 Xcode 的 Target → General → Frameworks → “+” 添加生成的
MyGoLib.framework后，必须勾选Embed & Sign，不能选Do Not Embed，否则运行时找不到 dylib
Go 函数返回 error 时移动端收不到具体信息
你在 Go 里写了 return nil, fmt.Errorf("network timeout")，但 Android 上收到的是空字符串或 java.lang.Exception，iOS 上只看到 NSGenericException。这是因为 gomobile 对 error 的桥接是单向的：它把 Go error 转成平台原生异常，但丢弃了原始 error message 的细节。
实操建议：
- 不要依赖返回
error传消息，改用结构体返回：type Result struct { Data string; ErrMsg string }，在 Go 层统一捕获并转成字符串字段 - 如果必须用 error，Android 端 catch
GoException后调用e.getMessage()，iOS 端捕获NSException后读reason字段——但这两者内容不可靠，取决于 gomobile 版本和构建参数 - gomobile v0.4.0+ 支持
-tags=gomobile_debug编译，可让错误栈更完整，但仅限 debug 构建，发布前务必关掉
真正麻烦的不是编译通不过，而是 runtime 行为不一致：Go 的 goroutine 在移动端被映射成 pthread，但生命周期不受 Java/Kotlin 或 Swift 控制；一次 gomobile bind 生成的接口，Android 上可能触发 JNI 全局引用泄漏，iOS 上可能因 ARC 和 Go GC 不同步导致野指针。这些没法靠加参数解决，得在 Go 层主动做资源 cleanup，并在移动端调用后显式释放句柄。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
