模块路径必须是可被go get引用的url格式，如github.com/yourname/myapp；写成myapp或./myapp会导致ide识别失败、依赖引用异常及ci构建错误。
模块化思维不是用来“搭环境”的，而是用来组织代码、隔离依赖、控制边界——环境搭建本身是前置动作，但它的配置方式会直接影响后续模块化是否能真正落地。
go mod init 时模块路径写错，后续所有依赖都可能失效
模块路径不是项目文件夹名，也不是本地路径。它必须是将来别人 go get 时能用的 URL 格式，比如 github.com/yourname/myapp。
- 写成
myapp或./myapp：IDE 无法识别为模块，go list -m all显示路径不一致，CI 构建失败率陡增 - 私有仓库必须用公司域名，如
git.company.com/team/project，并提前配好GOINSECURE或 git 凭据 - 本地调试可临时用
example.com/local，但上线前必须替换，否则发布语义化版本（如 v1.0.0）时会和实际托管地址冲突
GOROOT/GOPATH 不再决定项目结构，但环境变量仍影响模块行为
Go Modules 启用后，项目可以放在任意路径，GOPATH 不再约束源码位置。但它仍控制两件事：工具安装目录（$GOPATH/bin）和模块缓存位置（$GOPATH/pkg/mod）。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
GOROOT必须指向 Go 安装根目录（如/usr/local/go），否则go build找不到标准库 -
GOBIN可显式覆盖$GOPATH/bin，避免不同用户共享同一 bin 目录导致命令覆盖 - 国内网络下必须设
GOPROXY，否则go mod download会卡在proxy.golang.org；推荐https://goproxy.cn,direct
internal/ 和 pkg/ 目录不是语法强制，但错放会导致隐性耦合
Go 不会报错，但 internal/ 下的包一旦被外部模块 import，编译直接失败；pkg/ 则是团队约定，代表“我承诺兼容”。
-
internal/handler放路由编排逻辑，只供本模块cmd/调用；若误放进pkg/handler，其他项目一引用就锁死你内部实现细节 - 不要在
go.mod里用replace把internal/xxx指向本地路径——这等于绕过 internal 机制，后续升级时难以察觉依赖泄漏 -
pkg/config提供Load()函数即可，别暴露结构体字段；外部项目应只依赖接口或函数，而非具体类型
构建输出路径硬编码，多平台 CI 就容易翻车
go build -o ./bin/app main.go 看似简单，但在交叉编译或容器构建中极易出错：Windows 路径分隔符、Linux 权限、GOOS/GOARCH 变量未生效都会导致输出缺失。
- 正确做法是在项目根目录执行：
GOOS=linux GOARCH=amd64 go build -o ./dist/app-linux-amd64 ./cmd/app -
./cmd/app是包路径，不是文件名；确保该目录下有main.go且含func main() -
./dist/必须加进.gitignore；二进制文件不该进版本库，也不该由go mod tidy管理
最容易被忽略的是：模块路径一旦写进 go.mod，就成为所有依赖的“锚点”。改路径不是改个字符串的事，而是要同步更新所有引用它的下游模块、CI 脚本、Dockerfile COPY 路径，甚至文档里的 go get 命令。它不像变量名可以局部替换，而是牵一发而动全身的契约。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
