应在 flake.nix 中使用 nixpkgs.go_1_22（而非 nixpkgs.go）暴露 Go 工具链，通过 devShells 注入 go、gopls、delve 等，并为 cgo 添加 gcc 和 pkg-config；buildGoModule 需匹配 nixpkgs ≥ 23.11，显式处理 go.work 和 vendorSha256，避免硬编码 version；GOPATH 不必设置，现代工具依赖 GO111MODULE=on；CI 发布版需禁用 strip 并控制 ldflags，调试版应单独定义最小化 packages。
如何在 flake.nix 里正确暴露 Go 工具链给 shell 和构建？
直接用 nixpkgs.go 不行——它只是源码包，没带 go 命令或 GOPATH 环境。得用 nixpkgs.buildGoModule 或显式拉取预编译的 go 包（如 nixpkgs.go_1_22），再通过 devShells 注入。
实操建议：
- 优先用
nixpkgs.go_1_22（或对应稳定版），别用nixpkgs.go—— 后者不提供可执行文件 - 在
devShells.default的packages里加gopls、delve等常用工具，NixOS 不会自动推导它们的依赖关系 - 别指望
buildGoModule自动给你 shell 环境；它只管构建，环境得自己配 - 若项目含 cgo，必须同时注入
gcc和pkg-config，否则go build在 shell 里直接报exec: "gcc": executable file not found
buildGoModule 构建失败：常见原因和绕过方式
典型错误是 error: attribute 'buildGoModule' missing，或构建时提示 cannot find module providing package —— 这通常不是 Go 本身的问题，而是 Nix 对模块路径、vendor、go.mod 版本的解析逻辑和 Go CLI 不一致。
实操建议：
- 确保 flake 使用的
nixpkgs输入版本 ≥ 23.11（旧版buildGoModule对 Go 1.21+ 的go.work支持极弱） - 如果项目用了
go.work，buildGoModule默认忽略它；必须手动设src = ./.;并显式传subPackages列表 - vendor 目录不是必须的，但若存在，得加
vendorSha256；漏掉会导致校验失败，错误信息里不会明说“vendor 有问题”，只会卡在 unpack 阶段 - 避免在
buildGoModule中硬编码version；改用src = builtins.fetchGit {...};+rev，否则go mod download可能因代理/网络策略失败而静默退出
为什么 go env GOPATH 在 devShell 里总显示空？
因为 Nix 不设置 GOPATH —— Go 1.14+ 默认使用模块模式，GOROOT 和 GOPATH 都非必需。但某些工具（比如老版本 gocode 或自定义脚本）仍会查它，导致行为异常。
实操建议：
- 不要在
shellHook里盲目 exportGOPATH=$HOME/go；这会让go build把缓存写到用户目录，破坏纯函数性 - 真需要
GOPATH时，用GO_ENV = { GOPATH = "${placeholder "out"}/gopath"; };配合buildGoModule的输出路径，保持隔离 - 更推荐方式：检查工具是否支持
GO111MODULE=on和go.work；绝大多数现代 Go 工具已弃用GOPATH依赖 - VS Code 的
gopls若连不上，先运行go env GOMOD确认当前目录是否被识别为 module root；NixdevShell不改变工作目录逻辑，这点和普通终端完全一致
Flake 输出 packages vs devShells：该选哪个部署 CI 或远程构建？
如果你把 Go 二进制构建成 packages.myapp，它默认不含 go 命令、不带调试符号、也不打包 embed.FS 引用的静态文件 —— 因为 buildGoModule 默认启用 strip 且不处理 embed 资源的依赖跟踪。
实操建议：
- CI 构建发布版：用
packages，但必须显式关掉 strip：stripDebug = false;，并加ldflags = [ "-s" "-w" ]手动控制 - 远程机器部署调试版：别直接复用
devShells；它包含大量开发工具，体积大、启动慢；应另写一个最小packages.debugApp，只含go+ 二进制 +dlv - 嵌入静态资源时，
embed.FS路径必须是相对go.mod的；Nix 构建时若src没包含全部嵌入文件，go build会静默跳过，不报错也不警告 - 跨平台交叉编译（如 Linux → Darwin）必须用
crossSystem，不能靠targetPkgs；Nix 的 Go 构建规则对GOOS/GOARCH是硬编码适配的，随意覆盖环境变量大概率失败
Go 的模块缓存、vendor 处理、embed 资源绑定，这些在 Nix 里都不是透明桥接的点；每个环节都得主动对齐 Go CLI 的实际行为，而不是假设 Nix 会替你做决定。
