debug/macho 读不到本地 macOS 可执行文件，是因为其仅支持标准 Mach-O 格式，而 App 二进制常被签名、加壳或动态重写，导致 magic number 错误；fat binary 需手动解析 slice，符号表需优先通过 Symtab/Dysymtab 获取，且 stripped 文件可能无符号表。
为什么 debug/macho 读不到你本地的 macOS 可执行文件？
Go 的 debug/macho 包只支持解析 Mach-O 文件格式，但它对文件结构非常挑剔：必须是完整、未裁剪、未加密、且架构匹配的二进制。常见失败不是因为代码写错，而是你手里的文件根本“不标准”。
- 你双击安装的 App（比如
/Applications/Safari.app/Contents/MacOS/Safari）通常是带签名、加壳、或被 Apple 的dyld动态重写过的，OpenFile+macho.NewFile会直接 panic："bad magic number"或"not a Mach-O file" - Go 编译出的二进制（
GOOS=darwin GOARCH=amd64 go build）能被正常解析；但用go run启动的临时二进制不在磁盘上，自然无从解析 - 如果目标文件是 fat binary（含多个架构），
debug/macho默认只读第一个 slice —— 你得手动用File.FatHeader和File.Archs拆解，否则可能误判为“非 Mach-O”
macho.File 解析后怎么安全取符号表？别直接遍历 Symbols
Symbols 字段返回的是原始符号数组，但它不保证已去重、不包含调试符号、也不按地址排序。直接 for-range 容易漏掉 _main 或把 __Z12myFunctionv 当成普通函数。
- 真实符号逻辑应优先走
File.Symtab+File.Dysymtab：前者含所有符号（包括调试用的N_STAB类型），后者只含动态链接需要的（N_SECT等），更干净 - 判断一个 symbol 是否为导出函数，得同时检查：
Symbol.Type & macho.STAB == 0（排除调试符号）、Symbol.Section > 0（在有效段中）、Symbol.Name != "" - 注意：Go 1.21+ 中
Symbol.Value是地址偏移（非虚拟地址），若需真实 VA，得加上对应 segment 的Addr字段
跨平台解析 Mach-O 时，runtime.GOOS 不影响 debug/macho 行为
debug/macho 是纯解析器，和运行时 OS 无关。你在 Linux 上用 Go 交叉编译一个 darwin/amd64 程序，只要传入合法 Mach-O 字节流，它就能工作。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 但路径操作容易翻车：比如用
filepath.Join("/usr/bin", "ls")在 Linux 上拼出的路径，在 macOS 上根本不存在；别依赖GOOS去构造文件路径，而是由用户显式传入或通过os.Stat验证存在性 -
macho.Load内部用io.ReadAt，所以支持<em>bytes.Reader</em>、os.File甚至网络响应体 —— 这意味着你可以从 HTTP 下载 Mach-O 后直接解析，无需落地磁盘 - 性能上，
macho.NewFile是惰性加载：只读 header 和 load commands；真正访问 symbol table 或 section data 时才触发 IO。如果只是查 CPU 架构，用File.Cpu就够了，别急着调File.Symbols()
常见错误："no symbol table" 不代表没符号，而是没找到 LC_SYMTAB 命令
很多现代 macOS 二进制（尤其是 Swift 编译或启用 LTO 的）把符号表放进 __LINKEDIT 段并用 LC_DSYMTAB 描述，debug/macho 的 File.Symbols 方法只认 LC_SYMTAB，所以返回空切片。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法是：先检查
File.Dysymtab是否非 nil，再用File.ImportedSymbols()或File.ExportedSymbols()—— 它们内部会自动 fallback 到Dysymtab - 若连
Dysymtab都为空，那大概率是 stripped 二进制（如 App Store 发布版），此时唯一可读的元信息只剩File.Loads里的 segment 名称和权限位，比如判断是否含__RESTRICT段来推测 hardened runtime 状态
解析 Mach-O 最麻烦的从来不是 API 调用，而是你手上的文件到底“算不算 Mach-O”——magic 字节对、fat header 对、segment offset 对、symbol table 存在哪，每层都可能断掉。别假设文件“看起来像”，先用 file 命令确认：file -b your_binary，输出里必须含 Mach-O 三个字，否则后面全是白忙。
