Go编译iOS库必须用CGO+Xcode工具链：需启用CGO，通过xcrun调用Xcode clang交叉编译arm64/amd64静态库，合并为fat库，并导出C接口供OC/Swift调用。
Go 编译 iOS 库必须用 CGO + Xcode 工具链
Go 官方不支持直接生成 iOS 动态库（.dylib）或静态库（.a），也不能直接输出 .framework。真正可行的路径只有一条：用 CGO_ENABLED=1，调用 Xcode 提供的 clang 和 SDK，交叉编译出 ARM64（或 ARM64 + x86_64 模拟器）目标的静态库。
常见错误现象：build failed: cannot use cgo when cross-compiling —— 这是因为默认 Go 构建会禁用 CGO 跨平台编译；ld: unknown option: -target —— 说明没走 Xcode 的 clang，而是用了系统自带的旧工具链。
- 必须安装 Xcode（≥14.2），且运行过一次图形界面完成授权，否则
xcrun找不到 SDK - 必须显式设置
CC_arm64和CC_amd64，指向 Xcode 内置 clang：xcrun -sdk iphoneos clang -arch arm64 - iOS 真机目标是
darwin/arm64，模拟器是darwin/amd64（M1/M2 模拟器仍需amd64，不是arm64） - 不能用
GOOS=darwin GOARCH=arm64 go build直接跑 —— 这会忽略 SDK 头文件和链接器参数，必然失败
如何导出 C 兼容接口供 Objective-C/Swift 调用
Go 代码本身不能被 iOS 原生代码直接链接，必须通过 export 关键字暴露 C 函数，且所有参数/返回值只能是 C 基本类型或 *C.char、*C.int 等。
常见错误现象：undefined symbol: _MyExportedFunc —— 函数没加 //export 注释；cannot use string as *C.char —— 忘记用 C.CString() 转换；panic: runtime error: cgo result has Go pointer —— 返回了 Go 分配的 slice 或 struct 指针。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每个要导出的函数前必须写紧邻的注释：
//export MyFunc，不能有空行 - 入口必须有
import "C"，且该行前不能有任何 Go 代码（注释除外） - 字符串传入：用
C.GoString(cStr)；传出：用C.CString(goStr)，并手动C.free()（否则内存泄漏） - 避免返回 Go slice、map、channel；如需数组，用
*C.int+ 长度参数，由调用方管理内存
构建通用静态库（arm64 + amd64）的实操步骤
真机和模拟器架构不同，iOS 项目需要 Fat Library（多架构合并），不能只编一个架构。Xcode 不接受单架构 .a，会报 library not found for -lxxx 或架构不匹配。
性能影响：Fat 库体积略大（两份代码），但链接期无额外开销；兼容性上，只要两个架构都包含，就能覆盖所有开发与测试场景。
- 先编译 arm64：
CC_arm64="$(xcrun -find clang) -arch arm64 -isysroot $(xcrun -sdk iphoneos --show-sdk-path)" CGO_ENABLED=1 GOOS=darwin GOARCH=arm64 go build -buildmode=c-archive -o libmylib_arm64.a - 再编译 amd64（模拟器）：
CC_amd64="$(xcrun -find clang) -arch x86_64 -isysroot $(xcrun -sdk iphonesimulator --show-sdk-path)" CGO_ENABLED=1 GOOS=darwin GOARCH=amd64 go build -buildmode=c-archive -o libmylib_amd64.a - 合并：
lipo -create libmylib_arm64.a libmylib_amd64.a -output libmylib.a - 头文件
libmylib.h是自动生成的，必须一并拷贝进 Xcode 工程，且 Header Search Path 要包含其路径
Xcode 中链接 Go 静态库的关键配置
即使 .a 文件和头文件都放对位置，Xcode 仍可能链接失败，多数因为符号未解析或 Objective-C++ 混合问题。
容易踩的坑：Undefined symbols for architecture arm64: "_MyExportedFunc" —— 实际是 C++ name mangling 导致；ld: library not found for -lmylib —— Library Search Paths 没设对，或名字写成 -lmylib 却实际文件是 libmylib.a（Xcode 自动补 lib 和 .a，所以填 mylib 即可）。
- 在 Build Settings → “Header Search Paths” 添加
$(PROJECT_DIR)/path/to/headers，勾选 “recursive” - 在 Build Settings → “Library Search Paths” 添加
$(PROJECT_DIR)/path/to/libs，同样递归 - 在 Build Phases → “Link Binary With Libraries” 添加
libmylib.a（拖入即可，Xcode 会自动处理） - 如果从 Swift 调用，必须建
Bridging-Header.h并#import "libmylib.h"；若在 .mm 文件里调用，需确保该文件被识别为 Objective-C++（文件扩展名 .mm 或在 Build Settings 中设 “Compile Sources As” = “Objective-C++”）
最易被忽略的是 CGO_CFLAGS 和 CGO_LDFLAGS 的隐式依赖 —— 比如你用了 net/http，它底层依赖系统 DNS 解析，而 iOS 的 resolv.h 不可用，会导致链接失败或运行时 panic。这种依赖不会报错在编译期，得在真机运行后才暴露。建议从纯计算逻辑开始验证，再逐步接入标准库高级功能。
