nix-shell可按需拉取指定Go版本并隔离运行，关键在shell.nix中显式导出环境变量、用buildGoModule构建、正确处理src和go.work，避免命名空间污染与路径敏感问题。
用 nix-shell 快速启动干净的 Go 开发环境
不需要全局装 go，也不依赖宿主机的 GOPATH 或 GOROOT，nix-shell 能按需拉取指定版本的 Go 并隔离运行。关键在写对 shell.nix —— 它不是配置文件，而是 Nix 表达式，得显式导出环境变量。
- 必须用
buildGoModule或buildGoApplication（Nixpkgs 23.11+ 推荐）来构建项目，不能只靠go命令本身；否则go build会找不到vendor或模块缓存 -
shell.nix里别写with import <nixpkgs> {};，容易污染命名空间；改用let pkgs = import <nixpkgs> {};显式控制 - 如果项目用了
go.work，Nix 默认不识别，得手动把工作区根目录加进src，否则go run报no Go files in directory
为什么 buildGoModule 比 stdenv.mkDerivation 更稳
buildGoModule 内置了 vendor 解析、go mod download 预热、校验和锁定（go.sum），而手写 stdenv.mkDerivation 很容易漏掉 preBuild 阶段的模块同步，导致构建时网络失败或哈希不匹配。
- 它自动把
GOBIN指向$out/bin，避免二进制被写到临时路径 - 对
//go:embed支持更可靠——普通 derivations 不会自动把 embed 文件打包进源码上下文 - 若项目含 cgo，必须显式传入
pkgs.buildPackages.stdenv.cc，否则报exec: "gcc": executable file not found in $PATH
常见错误：go: cannot find main module 在 nix-build 里反复出现
这不是 Go 的错，是 Nix 没把当前目录当工作区。Nix 构建默认用的是 src 输出的 tarball，而 tarball 里若没保留 go.mod 所在的顶层目录结构，Go 就找不到模块根。
- 检查
src是否用了cleanSourceWith却忘了keepFiles = [ "go.mod" "go.sum" ] - 不要用
./.当src，Nix 会压缩整个目录树并丢掉 git 信息，改用pkgs.nix-gitignore.gitignoreSource [] ./. - 如果
go.mod在子目录（如cmd/myapp/go.mod），就得把subdir传给buildGoModule，否则它只认项目根
CI 中复现失败：本地 nix-shell 正常，GitHub Actions 却报 checksum mismatch
Nix 的哈希计算依赖源码完整性和构建上下文，CI 环境默认禁用 git metadata，而某些 Go 工具（比如 golangci-lint）会读 .git/ 生成版本号，进而影响 go.sum。
立即学习“go语言免费学习笔记（深入）”；
- CI 里跑
nix-build前，确保 checkout action 启用了fetch-depth: 0和submodules: true - 如果用了
gopls或其他 LSP 工具，别把它塞进shell.nix；它不该参与构建，只应在 devShell 里按需启用 - 避免在
default.nix里用builtins.readFile ./go.sum手动注入哈希——Nixpkgs 的buildGoModule已内置校验逻辑，多此一举反而破坏可复现性
最易被忽略的一点：Go 模块校验和是路径敏感的。哪怕 nix-shell 里 pwd 多了一个 /（比如 /path/to/project/ vs /path/to/project），go mod download 生成的缓存路径就不同，Nix 的源码哈希也会变。所以统一用 cleanSource + 显式 name 控制解压路径，比依赖相对路径更可靠。
