本文转载自微信公众号《我的脑子是炸鱼》，作者陈建宇。转载本文请联系脑筋急转弯公众号。大家好，我是学蒸鱼的建宇。前几天，Go语言社区受到了?的冲击，而最近Go1.16中Go模块的变化又点燃了社区浪潮。经过三天的冷静期，整体人气基本下降了。建宇打算换个角度说说，看如何去掉GOPATH？希望能给大家带来新的思考。什么是GOPATHGOPATH是Go语言的早期产物。说白了就是一个环境变量，可以指定Go项目的工作目录。重点是Go代码必须运行在GOPATH下，没有依赖版本控制的各种功能（可怕）。图片来自付费专栏。这时候，有些朋友就迷糊了。Google这么大的公司，代码量这么大，还是这个模式？主要原因是谷歌是一个大仓库模型，有自己独特的代码治理模型。业界没有这样的使用场景，自然也不存在。为什么官方没有提供Gomod，但是社区/行业需要。自然而然，后台社区诞生了很多第三方依赖管理，杂乱无章。直到围棋官方被迫出手，也有争吵，无法统一意见。最终，rsc顶着各方意见，强行推进了Gomodules。在Gomodules最受争议的时候，rsc被社区喷了很久，现在黑粉居多。为什么删除GOPATHGo语言中有两种项目管理模式：一种用于GOPATH，另一种用于Go模块。会带来以下问题：从语言的角度：肯定不直观。项目运行环境的培训和交流，你得问问人家跑的是GOPATH还是Gomodules。从设计的角度来看：这不符合Go语言所标榜的简单、少即是多、冗余的老概念。从实践经验来看：最常见的是新老项目的维护。你可能需要关注项目使用的是什么，然后调整你拉取依赖的行为（GOPATH拉取依赖需要爬一个梯子）。从麻烦的角度来看：将GOPATH迁移到Go模块时很容易卡住。在IDE模式之间切换也很痛苦，Go的内部源码也需要处理两套逻辑。错综复杂，任何一个程序员可能都不想过多维护两套，更何况是设计原则为简单的Go语言团队。社区意见征集早在2018年，rsc就表达了对Gomodules和GOPATH的看法：从长远来看，对于Gomodules，我们希望人们停止设置GOPATH，因此GOBIN可能更重要（或者增加压力，DefaultstoGOPATH[0]/箱）。结合消息来源，即Go官方博文《New module changes in Go 1.16》：原意更多的是“计划”，注意最后标注的是“Ifthereareproblemsthatpreventyoufrom迁移，请考虑提交问题或经验报告。”结合表达和经验，很明显“删除GOPATH”是未来技术上正确的决定。但从Go的历史项目来看，这可能违反了Go1的兼容性承诺。假设你有一个正在维护的Go历史项目。你不知道Go1.17已经彻底去掉了GOPATH，如果直接升级，程序会直接崩溃。或者，如果您的图像默认拉最新，那将是令人兴奋的。综上所述，Go官方文章《New module changes in Go 1.16》不仅仅是宣传，还包含了Go官方向社区征求意见的作用。目前，从国内评论区来看，大部分支持下架。但其实有困难的小伙伴已经在issues中反馈了：回到最开始的问题，这道题放大来看是“Go1shouldremoveGOPATH”。Go1.17能否彻底去除GOPATH还有待商榷：目前Go官方还在探索GOPATH的未来，并不一定是完全去除GOPATH。不要太心急，这个目标大概率会通过其他方式实现。
