go跨平台交叉编译成功的关键是同时显式设置goos和goarch并关闭cgo_enabled=0；漏设任一变量或启用cgo，易导致目标机器报cannot execute binary file或no such file or directory。
Go 模块本身跨平台完全一致，真正出问题的从来不是 go.mod 文件内容，而是模块初始化路径、环境变量残留、cgo 启用状态和构建目标设定这四点。只要它们对齐，Linux 上写的代码在 Windows 上 go run 也不会报错。
为什么 go mod init 在 Windows 和 macOS 上生成不同 module 名
这不是系统差异，是当前目录是否落在 $GOPATH/src 下导致的误判。Go 会按旧 GOPATH 规则推导 module 名，比如在 C:\Users\xxx\go\src\myproj 下执行 go mod init，可能生成 src/myproj 这种非法路径。
- 先运行
go env GOPATH确认当前 GOPATH 路径 - 再用
pwd（macOS/Linux）或cd（Windows）看当前路径是否在其src/子目录内 - 如果是，直接
cd到任意非 GOPATH 路径（如~/myapp或C:\work\myapp），再执行go mod init example.com/myapp - 顺手删掉项目根目录下残留的
vendor/目录——除非你明确用了go mod vendor
GOOS/GOARCH 交叉编译失败的三个真实原因
报错不一定是语法写错，更可能是 cgo、工具链或路径隐性冲突。
-
CGO_ENABLED=0必须显式加：即使没写import "C"，标准库中net、os/user、database/sql等包在某些场景下也会触发 cgo；不加就默认启用，跨平台编译时会卡在找不到头文件或链接器错误 -
GOARM容易被忽略：当设GOARCH=arm时，必须同时指定GOARM=7（树莓派 4+、主流 ARM Linux 发行版），否则生成的二进制运行时报runtime: this CPU has no floating point unit - 输出名后缀必须匹配目标系统：Windows 二进制必须带
.exe后缀，否则双击无反应；Linux/macOS 不需要后缀，但加了也无害
VS Code 中 gopls 提示失效或跳转失败
根本不是插件问题，而是工作区没对齐模块根目录——gopls 只认含 go.mod 的那个目录为项目起点。
- 打开 VS Code 时，确保「文件 → 打开文件夹」选的是
go.mod所在的最外层目录，不是父级 monorepo 或桌面路径 - 状态栏右下角应显示
Go (example.com/myapp)，而不是Go或空白 - 如果已打开错误路径，关掉窗口，重新用正确路径打开；别指望 reload window 解决
-
go.mod被.gitignore忽略、或文件权限为只读，也会导致gopls无法加载模块上下文
cgo 是跨平台模块行为分叉点：它让 Go 编译器从纯 Go 模式切换到 C 工具链依赖模式，一旦启用，GOOS/GOARCH 就不再是“设置完就能跑”，而变成“得配对目标平台的 C 编译器”。多数项目其实不需要 cgo，CGO_ENABLED=0 应该是默认起点，而不是最后才想起来加的补救措施。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
