main.go 应放在模块根目录或 cmd/{name}/ 下，必须属 main 包；go.mod 必须在模块根目录以正确定义 import 路径；测试文件需与源码同目录同包名且以 _test.go 结尾。
main.go 该放在哪一级目录
Go 项目没有强制的目录结构，但 main.go 必须在 main 包里，且通常放在模块根目录下——不是必须，但几乎所有工具链（go build、IDE、CI 脚本）都默认从这里找入口。
常见错误：把 main.go 放进 cmd/myapp/ 后忘了用 go run cmd/myapp/main.go，结果 go run . 报错 no Go files in current directory。
- 如果项目只含一个可执行程序，直接放根目录最省事
- 多个命令（如
myapp-cli和myapp-server），就按cmd/{name}/main.go组织，每个main.go自成一个main包 - 别在
internal/或pkg/里放main.go——它们是库路径，go build不会识别
pkg 和 internal 的区别到底在哪
pkg/ 是约定俗成的公共库目录，internal/ 是 Go 原生支持的“仅限本模块使用”边界。关键不是名字，而是 Go 编译器对 internal 的导入检查。
现象：把工具函数放进 internal/utils/，然后在外部模块（比如另一个 git repo）里 import 它，go build 直接报错：use of internal package not allowed。
-
internal/下的包只能被同一模块（即同个go.mod根目录）下的代码 import -
pkg/没有语言级限制，但若你没发布它为独立模块，外部项目 import 会走相对路径或 replace，容易出版本混乱 - 别为了“看起来规范”硬套
pkg/；如果某段逻辑确定只供本项目用，就用internal/，更安全
go.mod 文件位置决定模块边界
go.mod 所在目录就是模块根，也是 import 路径的起点。很多人在子目录里乱跑 go mod init，结果导致 import 路径和实际目录不一致，IDE 找不到符号，go get 更新失败。
典型错误：myproject/api/v1/handler.go 里写 import "myproject/internal/db"，但 go.mod 在 myproject/api/ 下——这时 Go 认为模块名是 myproject/api，根本找不到 myproject/internal/db。
- 一个项目通常只有一个
go.mod，放在仓库根目录 - 子模块（如想单独发布
myproject/pkg/logger）应拆成独立仓库 + 独立go.mod，而不是靠目录嵌套模拟 -
go mod tidy会根据代码里的 import 行反推依赖，所以 import 路径必须和go.mod声明的模块名完全匹配
测试文件命名和位置怎么才不被忽略
Go 只认 *_test.go 文件，且必须和被测代码在同一个包里（同目录），否则 go test 不会加载它，也不会报错——静默跳过是最容易踩的坑。
现象：写了 service_test.go 放在 tests/ 目录下，go test ./... 显示 no test files；或者把测试文件放在 internal/service/test/ 里，结果包名变成 test，和待测 service 包不一致，编译失败。
- 测试文件必须和源文件同目录，例如
internal/service/service.go对应internal/service/service_test.go - 测试文件里的
package声明必须和源文件一致（比如都是service），不能写service_test - 需要隔离测试依赖？用
//go:build integration+go test -tags=integration，别挪目录
go.mod 或多一层的目录，就会让 go run、go test、甚至 go list 表现不一致——这些地方不报错，只静默失效。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
