Go 交叉编译到 macOS 时，可执行文件无需扩展名（如 .exe），遵循 Unix 传统；若面向终端用户分发，推荐打包为 .app 目录结构或 .dmg 安装镜像；命令行工具则应无扩展名并确保 +x 权限。
go 交叉编译到 macos 时，可执行文件无需扩展名（如 `.exe`），遵循 unix 传统；若面向终端用户分发，推荐打包为 `.app` 目录结构或 `.dmg` 安装镜像；命令行工具则应无扩展名并确保 `+x` 权限。
在 macOS 上，可执行文件的本质不依赖文件扩展名，而是由文件权限位（chmod +x）和系统内核的 execve() 系统调用共同决定。这与 Windows 的 .exe 强绑定机制截然不同——macOS 继承自 Unix，其可执行性完全由文件权限（如 -rwxr-xr-x）控制，而非后缀名。
✅ 正确实践：按用途区分命名与分发方式
-
命令行工具（CLI）：
推荐不使用任何扩展名，例如：# 构建命令（Linux 交叉编译 macOS） CGO_ENABLED=0 GOOS=darwin GOARCH=amd64 go build -o mytool main.go
生成的 mytool 文件天然符合 macOS 习惯。用户可通过 ./mytool 直接运行（需先 chmod +x mytool）。若希望支持 mytool 全局调用，建议将二进制放入 /usr/local/bin 或用户 $PATH 下的目录，并确保其具备可执行权限。
-
图形界面应用（GUI）：
macOS 用户期望的是 .app 包（本质是特殊结构的目录），例如 MyApp.app/，内部包含 Contents/MacOS/myapp（真正的 Go 可执行文件）及 Info.plist 等元数据。即使你无法在 Linux 上完整构建 .app（因依赖 codesign 和 bundle 结构），也不应直接分发裸二进制文件并命名为 myapp.app——这是错误的：.app 是目录，不是文件扩展名。正确做法是：- 在 macOS 主机上用 hdiutil 打包为 .dmg（含拖拽安装体验）；
- 或提供 .zip 压缩包，内含已组织好的 MyApp.app/ 目录结构（可借助 go-bindata 或脚本自动化生成基础 bundle）；
- 明确文档说明：“请将 MyApp.app 拖入 /Applications 文件夹”。
-
避免的误区：
- ❌ mytool.exe、mytool.bin、mytool.macos：无意义且违背平台惯例；
- ❌ mytool.app（作为文件）：系统无法识别，双击报错“找不到应用程序”；
- ❌ 忽略签名与公证（Notarization）：macOS Catalina 及以后版本默认阻止未签名/未公证的下载程序，尤其从非 App Store 渠道分发时，必须通过 Apple Developer ID 签名并提交公证（xcrun notarytool submit），否则用户会遇到“已损坏，无法打开”的警告。
? 交叉编译注意事项（Linux → macOS）
# 推荐构建命令（静态链接，免依赖） CGO_ENABLED=0 GOOS=darwin GOARCH=arm64 go build -ldflags="-s -w" -o mytool main.go # 若需调用 C 函数（如 GUI 库），启用 CGO 并指定 SDK 路径（需 macOS SDK） # （通常需在 macOS 上构建更可靠）
⚠️ 提示：CGO_ENABLED=0 是跨平台安全首选，避免因目标系统缺失 libc 或 libSystem 版本导致 panic；但若使用 cgo（如 github.com/therecipe/qt），则必须在 macOS 上构建并签名。
? 总结
| 场景 | 推荐命名/格式 | 关键要求 |
|---|---|---|
| 终端命令行工具 | mytool（无扩展名） | chmod +x，加入 PATH，提供 Homebrew tap 更佳 |
| 图形桌面应用 | MyApp.app/ 目录 | 正确 Bundle 结构、Developer ID 签名、Apple 公证 |
| 分发包 | .dmg 或 .zip | 内含 .app 或清晰安装说明，避免裸二进制直链 |
最终，尊重平台惯例比技术可行性更重要：macOS 用户看到 mytool 会自然尝试 ./mytool；看到 MyApp.dmg 会双击挂载安装；而看到 mytool.exe 会本能怀疑是否下错平台。一次规范的命名，就是对用户体验最轻量却最有力的承诺。
