Go 1.18中指向本地模块的replace指令是否可提交到仓库？

你在go.mod里写的相对路径replace提交到仓库本身在固定目录结构下可以正常运行，但完全不推荐这么做——你已经在Go 1.18版本配置了go.work工作区，完全不需要在子模块的go.mod里保留replace规则，强行提交反而会踩很多没必要的坑。replace指令的设计初衷确实是临时测试未发布/修改过的第三方包，不适合作为本地多模块依赖的长期方案提交到代码库。

• 强耦合目录结构：只要后续有人调整仓库目录层级、单独拷贝某个lambda目录做独立部署/二次开发，相对路径会直接失效，执行go mod download/go build时会直接报找不到本地模块的错误。
• 干扰正常依赖解析：只要这行replace存在，无论你之后是否把pkg/customOne发布到远端仓库、打了正式版本tag，Go永远会优先读取本地相对路径下的代码，不会拉取远端版本。很容易出现“本地调试正常，CI/CD环境或者其他协作者拉代码构建失败”的问题——尤其是如果你的CI流程是单独进入lambda目录构建、没有把上层pkg目录完整带入构建上下文的话，会直接构建失败。
• 埋下依赖不一致的隐患：Go构建时只有主模块的replace规则会生效，依赖模块自带的replace会被忽略。如果之后有其他项目引用你写的lambda模块，下游不会感知到你写的replace规则，会直接去拉取远端的github.com/user/proj/app/pkg/customOne包，如果你没发布过这个包、或者发布的版本和你本地调试的版本不一致，会直接出现构建失败或者运行逻辑不符合预期的问题。

Go 1.18推出的go.work工作区机制，本来就是为了解决monorepo下多本地模块互相引用的问题，把工作区配置和单模块的依赖定义做了拆分，完全可以替代子模块里的replace规则：

• 直接删掉lambdaFuncOne、lambdaFuncTwo两个目录下go.mod里的replace配置即可。你现在的go.work已经通过use声明把三个模块都加入了工作区，只要在go.work所在的app根目录执行Go相关命令，会自动识别本地的pkg/customOne作为依赖，不需要额外修改子模块的go.mod。
• 如果担心有协作者习惯单独进入lambda子目录操作、找不到本地依赖，可以做两个约定：
  • 团队统一在go.work所在的工作区根目录执行Go相关命令
  • 本地调试需要临时加replace的话，不要提交到仓库，调试完成后直接删掉即可，避免把本地临时配置带到公共分支。

你写的replace github.com/user/proj/app/pkg/customOne => ../pkg/customOne，只要满足两个条件就可以正常解析：

1. go.mod文件和pkg/customOne的相对位置不变，也就是始终保持lambda目录和pkg目录同属app下的同级目录
2. 相对路径指向的位置存在带合法go.mod的customOne模块
   需要注意的是：Go解析replace里的相对路径，是以go.mod文件本身所在的目录为基准，不是你执行Go命令时的终端所在目录，所以不会因为你执行命令的位置变化导致路径失效。但还是那句话，有go.work的前提下完全没必要留这行配置。

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