go模块版本号写死在go.mod中，需由main分支统一管理；feature分支应通过go.work或replace临时重定向依赖，禁止修改require行，避免未验证版本污染主干及合并冲突。
多开发分支并行时，go.mod 中的模块路径和语义化版本标签（如 v1.2.0）不会自动同步或收敛——它们是静态声明，不是动态状态。你不能靠 Git 分支名推导模块版本，也不能指望 go build 自动识别“当前在 feature/auth 分支上就该用 v1.3.0-alpha”。
为什么 go mod edit -require 在 feature 分支里改了版本号反而坏事
模块版本号写死在 go.mod 里，一旦你在 feature/login 分支手动执行 go mod edit -require example.com/lib@v1.3.0-rc1，这个变更就会随 PR 合入 main，导致主干提前锁定未验证的预发布版本。更糟的是：如果多个 feature 分支各自 require 不同的临时版本，合并冲突会直接卡在 go.mod 的 require 行上。
- 真正需要隔离的不是版本号，而是「本地开发时的模块解析路径」——这由
go.work或replace控制，而非require -
require应始终指向已发布的、稳定的语义化标签（如v1.2.0），仅在main分支上更新 - feature 分支中所有对依赖的调整，应只通过
go work use ./xxx或replace临时重定向，且这些修改 不提交 到 Git（加到.gitignore中的go.work）
go.work 文件该放哪、怎么写才不影响 CI 和协作者
go.work 是纯本地开发辅助文件，它的存在与否完全不影响 go build 在标准模式下的行为。CI 流水线、其他协作者的机器，只要没显式运行 go work use，就根本感知不到它。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 必须放在工作区根目录（即所有子模块的共同父目录），且路径必须相对，例如：
use ./internal/user ./internal/order - 不要写绝对路径或
../，否则换机器就失效 - 文件本身不提交 Git；但要在项目文档里说明：“本地多模块联调请执行
go work init && go work use ./internal/...” - CI 脚本里禁止出现
go work相关命令——它默认走单模块模式，靠go.mod+go.sum就够了
如何让不同分支共用同一套版本策略而不互相污染
关键不是“让每个分支有自己版本”，而是“让所有分支都基于同一个权威版本基线演进”。真正的版本锚点只有两个：Git tag 和 go.mod 中的 module 声明。
- 所有 feature 分支都从
main拉出，起始时go.mod中的require行与main完全一致 - 模块大版本升级（如
v1→v2）必须新建 Git 分支（如v2-dev），并在该分支上完成go.mod路径修改、导入路径批量替换、兼容性测试 - 补丁版本（
v1.2.x）只在main上通过 hotfix PR 发布；feature 分支若需紧急修复，应先 cherry-pick 对应 commit，而不是自己 bump 版本号
最易被忽略的一点：Git tag 和 go.mod 中的 module 路径必须严格匹配。比如打了 v2.0.0 标签，但 go.mod 还是 module example.com/lib，下游 go get example.com/lib@v2.0.0 就会失败——Go 不会自动补 /v2，它只认路径字面量。这个校验在本地不报错，但一发布就断链。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
