go modules 从 go 1.16 起强制启用，必须用 url 风格路径执行 go mod init；internal/ 是工具链隐式访问控制边界，pkg/ 是需维护兼容性的公共模块；go build 应用环境变量驱动而非硬编码路径；go get -u 不适用于生产依赖升级，应指定版本后运行 go mod tidy。
Go Modules 是默认开启的依赖管理机制，不是可选项——从 Go 1.16 起已强制启用，go mod init 是项目初始化唯一可靠起点，别再用 GOPATH 模式建项目。
go mod init 的模块路径必须是 URL 风格
模块路径写成 myapp 或 ./myapp 看似能跑通，但会立刻引发三类问题：其他项目无法 go get 引入你、IDE（如 GoLand）识别为“无模块”导致自动导入失效、后续打 tag 发布时 go list -m all 显示路径不一致。
正确做法是按代码托管地址根路径来写，哪怕还没 push 到远程：
- GitHub 项目用
github.com/yourname/myapp - 公司私有 GitLab 用
gitlab.company.com/team/myapp，并提前配好go env -w GOPRIVATE=gitlab.company.com - 本地快速验证可用
example.com/local/myapp，但上线前必须替换 - 路径中禁用大写字母和下划线，只用小写字母 + 短横线（kebab-case）
internal/ 和 pkg/ 不是目录名，而是访问控制契约
internal/ 不是语法关键字，而是 Go 工具链的隐式规则：任何包若路径含 /internal/，就只能被其父目录或祖先目录下的包导入。它本质是“防误用”的边界，不是“功能分组”工具。
pkg/ 是社区约定，代表你愿意对外提供稳定接口的公共能力模块，比如 pkg/auth 或 pkg/storage。它的存在意味着你要对 API 做向后兼容承诺。
常见踩坑点：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 把
internal/handler加进go.mod的replace里——这等于绕过 internal 规则，让外部可直接 import，破坏封装 - 在
pkg/里放未抽象的业务逻辑，导致其他项目强耦合你的实现细节 - 把配置加载逻辑放在
internal/config却又让cmd/app直接调用其内部结构体，而不是通过函数封装
go build 输出路径别硬编码，用环境变量驱动
写 go build -o ./bin/app main.go 在本地开发看似方便，但在 CI/CD 或多平台交叉编译时极易出错：路径权限、Windows 反斜杠、不同架构输出名冲突等问题都会暴露。
更可靠的做法是利用 Go 默认行为 + 环境变量组合：
- 入口包路径写完整，如
./cmd/app（不是./cmd/app/main.go），确保该目录下有main.go且含func main() - 用
GOOS和GOARCH控制目标平台：GOOS=linux GOARCH=arm64 go build -o ./dist/app-linux-arm64 ./cmd/app - 输出目录（如
./dist）加进.gitignore，不提交二进制文件 - Windows 下避免依赖 WSL 构建，CI 中统一用
GOOS=windows原生构建
go get -u 不该用于日常依赖升级
go get -u 只更新直接依赖的最新 minor/patch 版本，完全忽略间接依赖（transitive deps），也不会处理版本冲突。它适合早期探索，不适合维护阶段。
真正安全的升级流程是：
- 明确指定要升级的模块和版本：
go get github.com/gorilla/mux@v1.8.1 - 运行
go mod tidy：清理未使用依赖 + 补全缺失间接依赖 + 校验go.sum - 检查
go.mod中是否引入了意外的高版本间接依赖（比如某个旧版库悄悄拉了 v2+ 的 transitive dep） - CI 流程中固定用
go mod download预热缓存，避免构建时网络抖动失败
最易被忽略的是 go.sum 文件的校验逻辑——它不只记录哈希，还隐含模块路径与版本映射关系；一旦手动编辑或 replace 使用不当，go build 可能静默跳过校验，埋下供应链风险。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
