刚开始用 Go Modules，本地 replace 比复制代码省事得多

刚从 GOPATH 思维切到 Go Modules 时，很多人最直观的感受是目录终于自由了，不一定要把项目放在固定路径下。可真正让我觉得它实用的，是本地联调依赖仓库时，不用再靠复制粘贴代码或者临时改 import 路径硬顶过去。

依赖联调最怕的是“本地能跑，别人环境不一样”

以前调一个还没发布的新依赖，经常是把代码直接拷到本地某个目录，或者临时改成一个只在自己机器上成立的路径。短期能跑，过几天自己回头看都很难恢复，更别说团队里其他人同步环境了。

Go Modules 把依赖声明放进 go.mod 以后，项目状态明显更可描述。你至少能一眼看见当前项目依赖哪些模块、版本指向哪里，不用再靠目录结构去猜。

replace 适合本地联调，不适合长期混着提交

replace 真正好用的场景，是你手头两个仓库都在开发中，想让主项目临时指向本地模块目录，快速验证改动是否配套。这样既不用发布测试版，也不用手工复制文件，联调速度会快很多。

但它更像开发期的桥梁，而不是长期方案。因为一旦把本地路径的 replace 直接留在共享分支里，别人拉下来往往跑不起来。所以我更习惯把它当成显式的本地配置，用完后及时清理，或者改成团队都能访问的统一地址。

联调完成后，记得把模块状态收干净

很多 Go Modules 的混乱不是出在功能本身，而是联调结束后状态没收尾。比如 replace 忘记去掉、require 里还挂着旧版本、无用依赖没有清理，最后项目虽然还能跑，模块文件却越来越脏。

我一般会在联调完成后顺手把 go.mod 和 go.sum 重新整理一遍，确认当前依赖关系和预期一致。这样下次别人接手时，不至于先花半小时猜“这条本地 replace 到底是不是必须的”。

模块化真正带来的，是依赖关系可见

Go Modules 不是为了让依赖配置更花哨，而是让项目和依赖之间的关系变得可记录、可复现。尤其是多人协作时，这种明确性比单机上能不能跑更重要。

所以刚开始接触它时，我觉得最值得先掌握的，不是所有命令参数，而是几个基本习惯：模块路径写清楚，本地联调用 replace，联调结束及时收尾。把这几件事做好，日常开发已经会顺很多。