module path必须与未来公开地址一致，推荐用github.com/username/project等托管路径；本地开发可用example.com/myproject，禁用localhost；一旦设定不可随意更改，否则需同步更新所有import语句。
go mod init 时 module path 怎么选才不踩坑
模块路径不是随便起个名字就行，它直接影响 import 路径、依赖解析和未来发布。用本地路径（如 myproject）会导致：import "myproject/internal/user" 在其他机器上直接报错 —— Go 不会从当前目录找包，而是按 module path 去 GOPROXY 或本地缓存查。
正确做法是模拟将来可能公开的地址，哪怕只是本地开发：
- GitHub 用户：用
github.com/yourname/myproject - GitLab / 私有 Git：用实际域名，如
gitlab.example.com/team/proj - 完全离线或暂无远程仓库：至少带一级域名占位，比如
example.com/myproject（别用localhost或127.0.0.1，Go 不认）
一旦 go.mod 生成，module path 就不该再改 —— 否则所有 import 语句都要同步更新，go mod tidy 也会混乱。
internal/ 和 pkg/ 目录边界在哪
很多人把 internal/ 当成“还没写好”的临时存放区，这是错的。internal/ 的唯一作用是**禁止外部模块导入**，Go 编译器会硬性检查 import 路径是否包含 /internal/ 且调用方不在同一 module 下，不符合就报错：use of internal package not allowed。
pkg/ 则相反：它是设计为可被其他项目复用的公共能力，比如通用校验、加解密工具、HTTP 客户端封装。但要注意：
-
pkg/util这种命名太泛，容易变成“垃圾桶”，建议按职责收敛，例如pkg/httpclient、pkg/validator - 如果
pkg/里某个子包只被本项目用，却暴露了复杂接口，反而增加维护负担 —— 宁可挪回internal/ -
go list -f '{{.ImportPath}}' ./pkg/...可快速确认哪些包能被外部 import
编译产物命名与跨平台构建的实际约束
go build 默认生成的可执行文件名来自主目录名（如 myproject/ → myproject），但 Windows 下是 myproject.exe。想统一命名？必须显式用 -o：
go build -o bin/app ./cmd/app
跨平台构建更麻烦：Go 不能在 macOS 上直接编译出 Windows 二进制，得靠环境变量控制：
- 编译 Linux 版：
GOOS=linux GOARCH=amd64 go build -o bin/app-linux ./cmd/app - 交叉编译 ARM64 Linux：
GOOS=linux GOARCH=arm64 go build -o bin/app-arm64 ./cmd/app - Windows 下记得加
.exe后缀：GOOS=windows go build -o bin/app.exe ./cmd/app
注意：CGO_ENABLED=0 在交叉编译时几乎必加，否则可能因缺失 C 工具链失败；静态链接也靠它实现（默认动态链接 libc）。
go.sum 文件为什么不能删，也不能手动改
go.sum 是模块 checksum 数据库，记录每个依赖的精确哈希值。删掉它，下次 go mod download 会重新拉取并生成新哈希 —— 看似没问题，但团队协作时，你和同事的 go.sum 可能不一致，导致 go mod verify 失败或 CI 拒绝构建。
常见误操作：
- 合并冲突时手工删掉几行
go.sum—— 错！应运行go mod tidy自动修复 - 看到某依赖哈希变了就怀疑被篡改 —— 先确认是否升级了小版本（
v1.2.3 → v1.2.4），这是正常行为 - 私有模块没配
GOPRIVATE，go.sum里出现// indirect行但校验失败 —— 必须配置GOPRIVATE=*.corp.example.com（替换成你的真实域名）
真正要关注的，是 go.sum 里有没有陌生域名或可疑哈希 —— 那才值得查证来源。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
