如何让go mod tidy不拉取远程私有包而是引用monorepo本地包

replace 指令是Go modules原生提供的路径遮蔽（masking/shadowing）机制，优先级高于所有远程源、校验库配置，匹配规则的导入路径会被直接重定向到指定位置，go mod tidy执行时会优先读取该规则，完全不会触发对应包的远程拉取请求，是最直接的解决方案。

原生Go工具链配置（无额外依赖，100%兼容go mod tidy） #

1. 配置私有包环境变量，让Go工具链跳过对应路径的公网校验、代理拉取逻辑：

   go env -w GOPRIVATE=github.com/user/ticketing/*
   

   该配置会对所有匹配github.com/user/ticketing/前缀的包生效，跳过GOPROXY、sum.golang.org的公网请求。
2. 在monorepo根目录的go.mod中添加强制本地映射规则，彻底遮蔽远程路径：
   • 如果你是单go.mod架构（整个monorepo只有根目录一个go.mod，module声明为github.com/user/ticketing），添加如下规则：

     module github.com/user/ticketing
     
     go 1.22 // 替换为你实际使用的Go版本
     
     // 强制将当前仓库的所有导入路径指向本地根目录
     replace github.com/user/ticketing => ./
     

     这种架构下你提到的github.com/user/ticketing/tickets/models/connection这类子包，本身就属于当前模块的一部分，加完规则后go mod tidy会直接遍历本地目录解析依赖，不会发起任何远程请求。
   • 如果你是多go.mod架构（比如tickets目录下有独立的go.mod，声明为独立子模块），则针对子模块添加精确映射：

     // 根go.mod中添加
     replace github.com/user/ticketing/tickets => ./tickets
     

3. 验证配置效果：执行go mod tidy -x，从输出的执行日志可以看到，不会出现针对github.com/user/ticketing路径下包的git拉取、HTTP下载请求，所有相关包的解析路径都指向本地目录。

Bazel方案说明 #

你的判断是正确的：纯Bazel侧的依赖规则（比如gazelle自动生成的BUILD配置）不会对go mod tidy的行为产生影响，因为go mod tidy是Go官方工具链命令，不会读取Bazel的配置文件。如果要在Bazel工作流中彻底脱离远程拉取，可以配合如下配置：

• 先按上述Go原生方案配置好go.mod的replace规则，保证go mod tidy可以正常在本地执行完成。
• 执行go mod vendor把所有依赖（包括monorepo内的本地包）导出到根目录的vendor文件夹，Bazel构建时直接读取vendor目录下的源码，不需要触发任何远程依赖拉取。
• 配置gazelle的replace_directives参数，让自动生成的BUILD规则和go.mod中的replace映射保持一致，避免Bazel构建时出现路径解析错误。

部署流程注意事项 #

在skaffold构建容器镜像时，需要把整个monorepo的源码目录作为构建上下文传入，不要仅传入单个服务的子目录，否则本地replace规则会因为找不到对应路径的文件报错。

内容的提问来源于stack exchange，提问作者reactor