从GOPATH迁移到go.mod的困惑：Go1.19为何仍保留GOPATH？

先澄清「不可混用」的真实含义 #

你看到的「GOPATH与go.mod不可混用」，不是说两者完全不能共存，而是指不要在GOPATH模式下运行带go.mod的项目，也不要让模块化项目（有go.mod）依赖GOPATH下未模块化的代码。简单说，模块化项目和非模块化的GOPATH项目不能交叉依赖，但go.mod项目本身会用到GOPATH的缓存，这是正常行为，不算「混用」。

为什么go.mod会通过GOPATH下载依赖？ #

Go的模块依赖默认会下载到GOPATH/pkg/mod目录下，这是全局模块缓存——所有模块化项目都会复用这里的依赖包，同一个版本的包只会下载一次，省空间还快。这和Python虚拟环境完全不一样：虚拟环境是每个项目单独存一份依赖，而Go的这个缓存是全局共享的，GOPATH现在的核心作用之一就是托管这个缓存。

你对GOPATH的理解需要修正 #

GOPATH最初的定位是统一管理项目代码（放在src目录）和依赖包，但模块化（go.mod）出来后，项目代码已经可以放在任意目录（不需要在GOPATH/src里）。现在GOPATH的角色已经大幅缩小，主要负责三件事：

• 存放全局模块缓存（pkg/mod）
• 存放通过go install安装的可执行二进制文件（bin）
• 兼容旧的非模块化项目（如果还有团队在维护这类代码）

Go1.19仍保留GOPATH的原因 #

1. 兼容性需求：还有大量遗留项目是基于GOPATH开发的，Go团队必须保证这些项目能正常运行，不能直接砍掉GOPATH。
2. 缓存复用效率：全局缓存能避免重复下载相同版本的依赖，节省磁盘空间和网络带宽，这是Go设计里注重效率的体现。
3. 平滑过渡：让开发者可以从GOPATH逐步迁移到模块化，而不是强制一刀切，降低迁移成本。

总结你的理解偏差 #

你说GOPATH「仅负责外部依赖」不算完全准确，它现在主要是全局缓存和兼容旧项目；而且它和Python虚拟环境差异很大——虚拟环境是隔离依赖，Go的模块缓存是共享依赖，两者设计思路完全不同。

内容的提问来源于stack exchange，提问作者Zoltan K.