go mod init 是 go 项目依赖管理的第一步，用于在根目录生成 go.mod 文件，声明模块路径、go 版本及依赖，实现版本锁定与构建可重现。
go mod init 生成 go.mod 文件
Go 项目构建依赖的第一步不是写 Makefile，而是初始化模块——go mod init 会生成 go.mod 文件，这是 Go Modules 的核心配置文件，没有它，go build 仍能运行，但依赖无法版本化锁定，协作和部署时极易出错。
执行前确保你在项目根目录（即包含 main.go 的目录），且该目录名能反映模块路径语义（如 github.com/yourname/toolname）：
-
go mod init github.com/yourname/toolname—— 推荐显式指定模块路径，避免默认用本地目录名导致后期 import 路径不一致 - 若当前目录已含
go.mod，重复执行会报错；若只改了模块路径，需手动编辑go.mod中的module行并运行go mod tidy修正依赖 - Windows 下路径含空格或中文？别用——
go mod对非 ASCII 路径支持不稳定，容易在 CI 或他人机器上触发invalid module path
go build 默认行为与 -o 控制输出文件名
go build 不生成构建文件，它直接产出可执行二进制；所谓“构建文件”常被误指为 Makefile 或 go.mod，但真正影响构建结果的是命令参数和当前模块状态。
常见误区：在子目录下执行 go build 却期望生成根目录同名可执行文件——实际它只会编译当前包（若非 main 包则报错 no main package）。
- 在项目根目录（含
main.go和go.mod）运行go build→ 输出文件名为目录名（Linux/macOS）或目录名.exe（Windows） - 想指定输出名？必须用
-o：go build -o bin/mytool，注意路径需存在，go build不自动创建父目录 - 加
-ldflags="-s -w"可减小体积、去掉调试信息，适合发布场景；但调试时慎用，会丢失 stack trace 行号
要不要写 Makefile？看团队和交付频率
Makefile 不是 Go 构建必需品，但当项目需要多平台交叉编译、清理产物、跑测试+构建+推送一体化流程时，它比记忆一长串 go build 参数更可靠。
一个最小可用的 Makefile 示例（注意缩进必须是 Tab，不是空格）：
build: go build -o bin/mytool build-linux: GOOS=linux GOARCH=amd64 go build -o bin/mytool-linux clean: rm -f bin/mytool bin/mytool-linux
- 目标名用蛇形（
build-linux），避免中划线或驼峰，防止某些 shell 解析异常 - 交叉编译环境变量（
GOOS/GOARCH）必须写在go build命令同一行，写成两行不会生效 - CI 流水线里用
make build比裸写go build更易维护——换构建逻辑只需改 Makefile，不用翻每个脚本
go.sum 不是“构建文件”，但忽略它等于放弃依赖一致性
go.sum 是自动生成的校验文件，记录所有直接/间接依赖的模块路径、版本和哈希值。它不参与编译过程，但 go build 在启用 module mode（即有 go.mod）时默认校验它。
- 删掉
go.sum后首次go build会重新生成，但可能拉到不同 commit（尤其当依赖没打 tag），导致“在我机器上能跑，在你机器上 panic” -
go mod tidy会同步更新go.mod和go.sum，但不会删除未使用的依赖项的go.sum条目——这是设计使然，保留历史哈希用于审计 - 提交代码时必须连同
go.sum一起提交，否则别人go build可能因校验失败中断
go.mod（依赖）、go.sum（校验）、命令参数（行为）三处；少任何一个环节，都可能让二进制在另一台机器上静默失效。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
