要不要移除 GOPATH？

Go modules 争议最大的时候，rsc 被社区喷了好久，现在黑转粉居多了。

为什么移除 GOPATH

在 Go 语言中存在两种可用项目管理模式：一种 GOPATH，另外一种 Go modules。会带来下述问题：

1. 从语言层面来看：肯定是不直观的，培训和交流工程运行环境，还得问问人家是跑在 GOPATH，还是 Go modules 上。
2. 从设计层面来看：这不符合 Go 语言标榜的简洁，少即是多的理念，冗余的老理念。
3. 从实际经验来看：最常见的就是新老项目的维护，你可能需要关注这个项目到底用的什么，再调整自己拉取依赖的行为(GOPATH 拉依赖需要爬梯)。
4. 从麻烦的角度来看：在 GOPATH 迁移到 Go modules 时很容易踩坑。在 IDE 的模式上切来切去也比较痛苦，Go 内部源码也得处理两套逻辑。

这么错综复杂，任何一个程序员可能都不会太想维护两套，何况是简洁为设计原则的 Go 语言团队。

社区意见征集

早在 2018 年，rsc 就针对 Go modules 和 GOPATH 表示过其观点：

原意更多是 “计划”，留意到最后标有 “如果存在阻止您迁移的问题，请考虑提交 issue 或 experience report。”

结合表述和经验，可以明确面向未来 “移除 GOPATH” 是技术上正确的决策。但从 Go 历史项目来看，这可能违背了 Go1 兼容性承诺。

假定你有一个 Go 历史项目在维护。你不知道 Go1.17 彻底移除了 GOPATH，直接升级了，那程序直接就崩了。又或是你的镜像默认拉取的就是 lastest，那就刺激了。

总结

Go 官方这篇《New module changes in Go 1.16》在宣传的同时，也包含着 Go 官方向社区征集意见的作用。

目前从国内的评论区来看，绝大部分都是支持移除的。但其实有难处的小伙伴，早已经在 issues 反馈了：

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!