go项目初始化核心是go mod init显式指定合理模块路径（如github.com/yourname/myproject），生成go.mod文件，再立即执行go mod tidy补全依赖并校验导入路径一致性。
go.mod 是否及时生成、以及后续依赖和导入是否能自然对齐。现代 Go 开发（1.11+）默认启用 Modules，go mod init 是唯一不可跳过的起点，其余步骤都围绕它展开。
go mod init 的模块名怎么填才不踩坑
模块名不是项目文件夹名，而是未来被其他项目 import 时使用的路径前缀。填错会导致：外部无法正确引用、本地 go get 失败、IDE 提示包未解析。
- 如果是公开仓库（如 GitHub），直接用完整 URL 路径：
go mod init github.com/yourname/myproject - 如果是本地练习或私有服务，可用任意合法标识符，但建议带域名风格避免冲突：
go mod init example.com/myproject（不用真实存在） - 绝对不要填相对路径、中文、空格或以数字开头的名称
- 执行后检查生成的
go.mod文件第一行是否为module xxx，且内容与命令中一致
main.go 必须放在项目根目录吗
不是必须，但强烈建议。Go 工具链默认把当前目录当作模块根，go run 和 go build 在无参数时会自动查找 main 包下的 main.go。
- 若
main.go放在cmd/myapp/main.go，需显式运行：go run cmd/myapp/main.go - 若同时有多个
main包（如cmd/api/main.go和cmd/cli/main.go），不能靠go run .启动，必须指定路径 -
go build默认只构建当前目录下可执行包；跨目录构建需用go build ./cmd/api - IDE（如 GoLand）依赖模块路径做符号索引，放错位置可能导致跳转失效或 import 红线
初始化后立刻要跑的三个命令
仅执行 go mod init 还不够，模块处于“半激活”状态。下面三步是让工程真正可协作、可构建的关键动作：
- 运行
go mod tidy：拉取缺失依赖、清理未使用项、更新go.sum。即使没写任何import，它也会补上标准库的校验记录 - 运行
go list -m all：确认当前模块及所有依赖是否解析成功。输出里不应出现unknown或invalid - 运行
go build（哪怕只有空main函数）：验证编译器能否识别模块路径。失败常意味着go.mod模块名与实际 import 路径不一致
为什么 GOPATH 不再重要，但 GOPATH/bin 仍可能干扰你
Go 1.16+ 已完全脱离 GOPATH 构建模式，但遗留的 $GOPATH/bin 若在 PATH 中，可能覆盖新版本工具（如旧版 gofmt 或 gomod 插件）。
- 执行
go env GOPATH查看当前值，若非必要可清空该环境变量 - 检查
echo $PATH输出中是否含$GOPATH/bin；如有，临时移除再测试go mod行为 - 私有模块或 replace 调试时，如果发现
go mod download总去拉取旧 commit，大概率是本地缓存或vendor目录残留导致，而非 GOPATH 问题
go.mod，后续所有 import 语句的路径都必须以它为前缀。比如模块名是 example.com/myproject，那在 internal/handler.go 里写 import "myproject/internal/util" 就会报错——正确写法是 import "example.com/myproject/internal/util"。这个约束不会在 go mod init 时提醒，却会在第一次 go build 或 IDE 导入时突然爆发。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
