go mod init 模块路径必须与分支命名策略对齐，main分支用example.com/myapp/v2，dev分支用example.com/myapp/v2-dev，切分支后需同步更新go.mod首行，否则引发import冲突。
go mod init 时模块路径要与分支命名策略对齐
模块路径不是随便起的，它直接影响 go get 拉取依赖时的解析逻辑，尤其在多分支协作中。比如团队约定 main 分支对应生产发布，dev 分支对应日常开发，那 go mod init 的参数就得反映这个结构——不能统一用 example.com/myapp，而应按分支动态调整：
-
main分支：运行go mod init example.com/myapp/v2（语义化版本号显式升级） -
dev分支：运行go mod init example.com/myapp/v2-dev或example.com/myapp@dev（避免与正式版冲突） - 切分支后必须检查
go.mod第一行是否变更，否则go build可能误用旧模块路径导致 import 冲突
GOOS/GOARCH 编译目标需随分支用途差异化设置
不同分支承担不同交付角色，编译配置不该一刀切。比如 release 分支产出最终可执行文件，ci 分支只做 Linux 测试，demo 分支要打包 Windows 安装包——这些都该通过环境变量或 Makefile 控制：
-
release分支：默认启用CGO_ENABLED=0+GOOS=linux GOARCH=amd64，生成静态二进制 -
ci分支：固定GOOS=linux GOARCH=arm64，配合 CI runner 架构验证兼容性 -
demo分支：在.goreleaser.yml中指定builds[].goos: [windows, darwin]，而非硬编码在脚本里 - 别在
main.go里写// +build windows这类条件编译标记，它和分支无关，容易混淆
go.work 多模块工作区要绑定分支生命周期
go.work 不是全局配置，它应该和分支共存亡。一个团队项目常含多个子模块（如 api、worker、cli），不同分支可能只修改其中一部分：
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
-
feature/auth分支只需激活./api和./shared，运行go work use ./api ./shared -
release/v1.5分支需锁定所有模块版本，用go work sync生成go.work.sum并提交 - 切分支后若
go.work未更新，IDEA/VS Code 可能仍加载旧模块路径，导致跳转定义失败或go list -m all输出异常 -
go.work文件本身必须纳入 Git，但go.work.sum要加进.gitignore（它含哈希值，每次sync都变）
GOPROXY 和 GOSUMDB 配置得按分支网络环境切换
内网开发分支和开源贡献分支对代理的需求完全不同。硬编码 GOPROXY=https://goproxy.cn 在某些场景会失败：
立即学习“go语言免费学习笔记（深入）”；
- 公司内网
internal分支：设GOPROXY=http://10.0.1.100:8081（私有 Nexus 代理），禁用GOSUMDB（内网无校验服务） - 对外开源
upstream分支：恢复GOPROXY=https://proxy.golang.org+GOSUMDB=sum.golang.google.cn - 用
go env -w GOPROXY=...是全局生效，实际应结合make build命令传参：GOOS=linux GOPROXY=$(PROXY) go build，再由 Makefile 根据分支名自动赋值PROXY - 千万别把
go env -w命令写进.bashrc，它会污染所有分支的本地调试环境
go env -w GOPATH）都会让后续切换变得不可预测。 
