gomobile是Go复用已有算法模块的胶水工具，不支持原生UI开发；需规范包路径、导出函数及C兼容类型，避免内存崩溃与体积膨胀。
Go 语言本身不直接支持 iOS/Android 原生 UI 开发，gomobile 是一个有限场景的胶水工具，只适合把 Go 逻辑封装为可被 Java/Kotlin 或 Objective-C/Swift 调用的库，不能写完整 App。
gomobile build 失败：no Go files in current directory
这是最常见卡点——gomobile build 不接受当前目录作为模块根，它要求你明确指定包路径，且该包必须含 main 函数（仅限 Android APK）或导出函数（iOS Framework）。你不能在随便一个目录下执行命令就生成产物。
- 确保项目是合法 Go module（有
go.mod），且包名是main（Android）或main+//export注释（iOS） - Android 示例：
gomobile build -target=android -o app.aar github.com/your/repo/app，路径必须指向含main.go的包 - iOS 示例：包内需有
//export Add注释的函数，再运行gomobile bind -target=ios github.com/your/repo/mathlib - 别用
.当前路径；gomobile 会忽略main.go以外的文件，也不识别go.work
调用 Go 函数时崩溃：Java/Kotlin 或 Swift 收到 nil / EXC_BAD_ACCESS
根本原因是 Go 的内存模型与原生平台不互通——所有传入/传出的数据必须是 C 兼容类型（int, float64, *C.char, []C.int 等），Go 的 slice、map、struct、channel 不能直接暴露。
- 导出函数签名只能含基础类型或 C 指针，例如：
func Add(a, b int) int✅，func Process(data []byte)❌（需转为*C.uchar+ 长度参数） - 字符串必须用
C.CString转换，且调用方负责C.free（Java/Kotlin 侧用ByteBuffer或 byte[]，Swift 侧用UnsafePointer<Int8>） - 不要在导出函数里启动 goroutine 并异步写回结果——没有回调机制，必须同步返回
- iOS 上若用
gomobile bind生成 framework，Swift 需加@objc兼容桥接，且所有方法名首字母小写（如add而非Add）
gomobile bind 后体积暴涨：framework 或 aar 超 20MB
默认 gomobile 静态链接整个 Go 运行时（包括 GC、调度器、net/http 等），哪怕你只用了一个加法函数。这不是 bug，是设计使然——Go 没有“按需链接”机制。
立即学习“go语言免费学习笔记（深入）”；
- 精简依赖：移除
log,net/http,encoding/json等重型包；用unsafe+C替代简单 JSON 解析（仅限可信输入） - Android 可用
-ldflags="-s -w"去符号和调试信息（加在gomobile命令后需改用gomobile build -ldflags="-s -w"） - iOS 无法剥离运行时，但可限制架构：
gomobile bind -target=ios/arm64（跳过 simulator 架构） - 别指望它替代 Kotlin Multiplatform 或 Rust —— gomobile 的定位是“已有 Go 算法模块复用”，不是跨端 UI 框架
gomobile 的真正价值在于已有成熟 Go 工具链（比如密码学、音视频编解码、协议解析）想快速嵌入移动端，而不是从零开始写 App。一旦涉及 UI、生命周期、推送、后台任务，就得切回原生代码，Go 层只做纯计算或数据处理。这点容易被教程带偏。
