go项目结构直接决定构建、测试与维护效果；go.mod是唯一入口，模块路径须与磁盘路径一致，internal/为编译器强制可见性边界，项目不应置于gopath/src下。
Go 项目结构不是“选一个模板就行”，而是直接决定你能否顺利 go build、go test、被他人正确 go get，以及上线后是否容易维护。现代 Go（1.11+）下，go.mod 是唯一事实入口，GOPATH 已退居为缓存目录，硬塞进 $GOPATH/src 反而会引发导入冲突或模块识别失败。
go mod init 后的项目根目录必须是模块路径的物理起点
模块路径（如 github.com/yourname/myapp）不是随便起的字符串，它必须与项目所在磁盘路径一致——仅指“能被 go 工具链从当前目录向上解析到的最短合法路径”。
- ✅ 正确：项目在
~/code/myapp，执行go mod init github.com/yourname/myapp，之后所有子包导入都以该路径为前缀（如"github.com/yourname/myapp/internal/service"） - ❌ 错误：项目在
/tmp/myapp却执行go mod init github.com/yourname/myapp，后续go build会报cannot find module providing package ...，因为工具链找不到对应磁盘路径 - ⚠️ 注意：
go mod init不校验远程仓库是否存在，也不强制要求域名真实可访问；但若未来要发布到公共模块代理（如 proxy.golang.org），路径需与实际 Git 地址匹配，否则其他用户go get会失败
internal/ 目录不是约定，而是编译器强制的可见性边界
internal/ 下的包不能被模块外部导入，这是 Go 编译器在 go build 阶段硬编码的规则，和 go.mod 内容无关。它比注释或文档约束更可靠。
- ✅ 正确用法：把业务逻辑、数据库访问、配置加载等不对外暴露的代码放
internal/下，例如internal/repository/user.go，外部模块即使知道路径也无法import "github.com/yourname/myapp/internal/repository" - ❌ 常见误用：把
internal/当作“只是个文件夹名”，在cmd/或测试中直接跨模块 import 它——编译会直接报错use of internal package not allowed - ? 提示：如果某个包确实需要被外部复用（比如通用加密工具），就放到
pkg/下，并确保其go.mod中声明了正确的模块路径，而非依赖internal/的变通写法
本地开发时不要碰 GOPATH/src，但要理解它的残留影响
即便启用 Go Modules，go install、go get（无 @version 时）仍默认把可执行文件和源码缓存写入 $GOPATH/bin 和 $GOPATH/pkg/mod。但你的项目源码绝不能放在 $GOPATH/src 下——除非你明确想回退到 GOPATH 模式。
- ✅ 推荐做法：将项目放在任意路径（如
~/projects/myapp），只靠go.mod管理依赖；GOPATH保持默认（$HOME/go）即可，无需修改 - ❌ 高危操作：把项目软链接进
$GOPATH/src，或手动设置GOPATH指向项目根目录——这会导致go build混淆模块路径与 GOPATH 路径，出现 “found modules in multiple locations” 报错 - ? 验证方式：运行
go env GOPATH和go list -m，前者应输出稳定路径（如/home/user/go），后者应只显示当前模块（如github.com/yourname/myapp），而非一堆golang.org/x/...或空行
真正卡住人的往往不是目录怎么命名，而是 go mod 和 go build 在背后悄悄做了什么——比如自动补全 replace、忽略未使用的 import、或因 go.sum 校验失败而拒绝构建。这些行为不会报错提示，只会让依赖看起来“有时工作，有时不工作”。动手前先跑一遍 go mod tidy 和 go list -m all，比反复改目录结构更有效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
