Go模块系统不支持合并多个go.mod为单一逻辑模块；应优先用go.work统一管理，replace泛滥时可降级为子包，跨仓库则通过GOPRIVATE+统一模块路径前缀实现协同。
不能直接“合并”多模块项目，Go 的模块系统不支持把多个 go.mod 合并成一个逻辑模块而不破坏语义和工具链行为。真正需要的不是合并，而是统一依赖视图、消除本地替换、收敛发布节奏——这取决于你当前的工程形态和目标。
判断是否真需合并：先看 go.work 是否已解决痛点
如果你已在用 go.work 管理多个本地模块（如 service/user、pkg/auth），那“合并”通常是个伪需求。workspace 模式本就提供统一构建、调试和测试能力，无需物理合并。
- 运行
go work list确认所有模块已被纳入工作区 - 检查
go build ./...是否能在根目录下成功构建全部命令（cmd/下） - 若 CI 中仍需单独
cd service/user && go test，说明 workspace 配置未覆盖全部场景，应补全路径而非合并
replace 指令泛滥时：收敛为单一模块更可控
当 go.mod 里堆满 replace（例如 replace example.com/lib => ./internal/lib），且这些被替换的路径实际从未对外发布，说明模块边界虚设——此时移除 go.mod、将其降级为普通子包是合理选择。
- 删除子目录下的
go.mod文件（如internal/lib/go.mod） - 确保该目录不含
module声明，也不被外部项目 import（否则会触发 “no required module provides package” 错误） - 在根
go.mod中保留其导入路径（如example.com/project/internal/lib），Go 工具链会自动解析为相对路径 - 注意：此举后，
internal/lib将无法独立go test或go vet，需通过根目录命令执行
跨仓库模块想统一管理：用 GOPRIVATE + 统一域名前缀
如果多个模块已拆成独立 Git 仓库（如 github.com/org/user-service、github.com/org/auth-lib），又希望像单体一样管理版本和依赖，则不应合并代码库，而应统一模块路径和私有代理策略。
- 所有模块
go.mod的module行使用相同前缀，如example.com/platform/user、example.com/platform/auth - 设置
GOPRIVATE=example.com/platform/*，避免 Go 工具链尝试从 proxy 下载 - 在根项目
go.mod中直接require example.com/platform/auth v0.3.1，而非用replace指向本地路径 - 版本 tag 必须真实存在远程仓库（如
v0.3.1），否则go get会失败
真正的难点不在操作步骤，而在模块边界的重新判定：哪些该保留在内部（internal/）、哪些必须暴露为独立模块（pkg/）、哪些其实只是临时开发捷径（replace）。一旦边界模糊，任何“合并”动作都只是掩盖问题，而不是解决问题。
