go.work用于多模块项目开发，通过go work init和use声明参与开发的模块，统一解析依赖但各自构建；CI/CD中需禁用工作区。
用 go.work 管理多个模块项目，避免依赖污染
当一个代码仓库里包含多个服务（如 auth-service、payment-service）、工具子模块（如 devtools）或共享库时，硬塞进同一个 go.mod 会导致依赖爆炸、构建变慢、甚至版本冲突。Go 1.18+ 的 go.work 是官方推荐的解法——它不替代各项目的 go.mod，而是“声明哪些模块一起参与当前开发会话”。
- 在项目根目录执行
go work init初始化工作区 - 把各服务/子模块加入工作区：
go work use ./auth-service ./payment-service ./shared - 此时
go run、go test会统一解析所有被use模块的依赖，但go build仍按各自go.mod构建，互不影响 - 注意：CI/CD 中默认忽略
go.work，生产构建应禁用工作区（加-modfile=go.mod或直接删掉go.work文件）
项目级 Go 版本隔离靠 .tool-versions + asdf，不是改 GOROOT
不同项目可能要求 Go 1.20（老系统兼容）、1.21（泛型稳定）、1.22（性能优化），手动切换 GOROOT 容易出错且无法自动生效。真正可靠的做法是用 asdf + .tool-versions 实现“进目录即切换”。
- 安装
asdf后添加 Go 插件：asdf plugin add golang - 在每个项目根目录写
.tool-versions：golang 1.20.14或
golang ref:6a9e75c2（指定 commit）
- 进入目录后，
go version自动指向该版本；ide（如 vs code）需启用asdfshell 集成才能识别 - 陷阱：别用
goenv local或gvm pkgset混用——它们原理不同，asdf是目前跨语言、跨团队最一致的选择
配置文件与敏感信息分离：Viper + 环境变量优先级必须设对
多项目共用一套配置结构（如 config.dev.yaml、config.prod.yaml），但密码、密钥绝不能写死在 YAML 里。Viper 的加载顺序决定了安全性底线：命令行 > 环境变量 > 配置文件 > 默认值。一旦环境变量没设对，就会意外读到配置文件里的占位符（比如 db.password: "changeme"）。
- 初始化 Viper 时显式关闭自动加载：
viper.AutomaticEnv()并设置前缀，如viper.SetEnvPrefix("app")，这样APP_database_PASSWORD就能覆盖database.password - 禁止调用
viper.ReadInConfig()前未设置viper.AddConfigPath("./configs")和viper.SetConfigName(fmt.Sprintf("config.%s", env)) - CI/CD 流水线中，用
env_file加载密钥（如.env.prod），而非写死在脚本里
开发工具链独立成模块，用 build tag 控制编译范围
调试器（delve）、Mock DB、本地消息队列这些只在开发期需要的依赖，如果放进主模块的 go.mod，会导致生产二进制体积膨胀、安全扫描告警、甚至意外触发初始化逻辑。
立即学习“go语言免费学习笔记（深入）”；
- 新建
devtools/目录，初始化独立模块：go mod init myorg/devtools - 在
devtools/profiler/main.go顶部加：//go:build dev，并在
main.go中只放调试入口 - 运行时明确指定标签：
go run -tags=dev ./devtools/profiler，生产构建（无-tags）完全不会编译该包 - 切忌用
import _ "myorg/devtools"方式“自动加载”，这会让所有构建都引入无关依赖
真正难的不是搭起多项目结构，而是让每个项目对自己的 Go 版本、模块依赖、配置来源和构建行为有**确定性声明**——而不是靠文档、口头约定或 IDE 插件猜测。只要 .tool-versions、go.work、go.mod 和 -tags 四者齐备且位置正确，切换项目就只是 cd 一下的事。