当 `go build` 尝试将可执行文件输出为 `test.go`（因目录名含 `.go` 后缀）时，该二进制文件被误识别为 go 源码，导致读取二进制内容时遇到 nul 字节而报错。根本原因是 go 工具链会扫描当前目录下所有 `.go` 文件（包括非源码的同名可执行文件）参与构建。
Go 的构建机制在设计上简洁高效，但也隐含一个关键约定：当前目录中所有以 .go、.c、.h 或 .s 为后缀的文件，均被视为包的一部分。这意味着，若 go build 输出的可执行文件恰好命名为 xxx.go，它将在下一次构建时被 Go 工具链当作 Go 源文件加载——而二进制可执行文件包含大量 NUL（\x00）字节，自然触发 unexpected NUL in input 错误。
典型复现场景如下：
$ git clone https://example.com/project/test.go # 远程仓库名为 test.go $ cd test.go $ go build # 成功，输出文件：./test.go（二进制） $ go build # ❌ 失败！因为 ./test.go 被当作源文件解析
根本原因在于 go build 的输出命名规则：
当执行 go build（无参数）且当前包为 main 时，输出文件名默认取自当前目录的 basename（即 basename $PWD）。 因此，目录名为 test.go → 输出文件为 test.go → 触发命名冲突。
✅ 正确解决方案是避免目录名以 .go 结尾：
# 方案1：重命名目录（推荐） $ cd .. $ mv test.go myapp $ cd myapp $ go build # ✅ 输出 ./myapp，不再冲突 # 方案2：显式指定输出路径（临时规避） $ go build -o ./bin/app . # 方案3：使用模块模式（现代 Go 项目标准实践） $ go mod init example.com/myapp $ go build # 输出仍为 ./myapp（目录名不含 .go），安全可靠
⚠️ 注意事项：
- 不要依赖 GOPATH=$PWD 这类非常规设置；现代 Go（1.11+）推荐使用 go mod 管理依赖；
- 自动化工具（如 gin、air）会在检测到文件变更后自动 go build，若存在 xxx.go 二进制文件，每次保存都会触发错误；
- 可通过 go list -f '{{.Name}}' . 验证当前包名，用 find . -name "*.go" -type f 检查是否混入了非法 .go 文件（如二进制）；
- 若已污染目录，执行 rm -f *.go（谨慎！确保无真实 .go 源码）或 git clean -fdx（仅限 Git 仓库）快速清理。
总结：Go 工具链的“约定优于配置”原则要求开发者主动规避命名歧义。永远不要将 Go 项目根目录命名为 xxx.go —— 这不是 bug，而是设计使然：.go 后缀是源码的专属标识符，绝不应与可执行产物共享。
