go mod init 的路径参数是模块导入标识而非物理路径，必须全局唯一且与 import 一致；生产构建须设 CGO_ENABLED=0 并加 -ldflags="-s -w" 保证静态、精简、一致的二进制输出。
Go 项目不需要“环境搭建”意义上的复杂初始化，架构师真正要控制的是构建一致性、跨平台交付能力和模块边界清晰度。所有其他操作都应围绕这三个目标展开。
go mod init 的路径参数不是物理路径，而是模块导入标识
很多团队误以为 go mod init 的参数必须匹配实际目录结构，导致后续 import 路径混乱或 CI 构建失败。
-
go mod init github.com/myorg/backend只是声明模块的全局唯一标识，与当前目录是否在~/code/github.com/myorg/backend无关 - 只要
go.mod存在，go build和go run就能正确解析依赖和 import 路径 - 模块名中包含组织域名（如
github.com）是为了避免命名冲突，不是强制要求托管在对应平台 - 若项目用于内部私有模块，可用
go mod init internal/backend，只要所有引用统一即可
交叉编译时 CGO_ENABLED=0 不是可选项，而是生产部署前提
默认开启 CGO 会导致二进制文件依赖 libc，在 Alpine 或容器最小镜像中直接报错：standard_init_linux.go:228: exec user process caused: no such file or directory。
- 生产环境静态编译必须设置
CGO_ENABLED=0，否则无法保证零依赖运行 - 若代码中调用了 C 库（如 sqlite、openssl），需改用纯 Go 实现（如
mattn/go-sqlite3的纯 Go 分支或modernc.org/sqlite） - 交叉编译命令示例：
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags="-s -w" -o ./bin/app . - macOS 上构建 Linux 二进制时，
CGO_ENABLED=0是硬性要求；Windows 同理
go build -ldflags="-s -w" 是发布级构建的标配，不是“优化建议”
未加 -ldflags="-s -w" 的二进制体积常多出 30%～50%，且包含调试符号和 DWARF 信息，存在敏感路径泄露风险。
立即学习“go语言免费学习笔记（深入）”；
-
-s：剥离符号表（symbol table），移除函数名、变量名等元数据 -
-w：剥离 DWARF 调试信息，防止通过dlv或gdb反向工程逻辑 - 二者组合后，二进制不可 debug，但这是生产环境的合理取舍
- CI 流程中应将该 flag 写死在构建脚本里，而非依赖开发人员手动添加
真正的规范难点不在命令本身，而在于让所有人——包括新加入的同事和自动化流程——始终以同一方式触发构建。模块路径写法、CGO 开关、链接器参数，这三项一旦松动，就会在不同机器或环境中产生不一致的产物。架构师要盯住的不是“怎么装 Go”，而是“怎么确保每次 go build 输出的二进制语义完全相同”。
