问题阐述

Go 语言在依赖包管理一共经过三个重要阶段：仓库模式、vendor、modules，关于这三个模式在另一篇文章中有详细介绍。

新的 Go 项目往往采用了 go modules 管理包依赖，不需要关注项目放置的位置，根据项目根路径的 go.mod 文件去读取加载依赖内容。

由于历史项目的特殊性，比如以及上线运营，评估升级风险过高等原因会要求基于旧的版本持续维护。

对于旧项目、历史项目，如果直接导入到本地 GoLand 之后往往会出现全面飘红或者某些依赖飘红，这时候就要关注一些早期版本的内容了。

GOPATH

Go 在 1.5 版本以前，GOPATH 是一个非常重要的环境变量。

它将标识着代码编译时去寻找实际代码所在的位置，一般从 $GOPATH/src 下寻找代码。

在处理旧项目飘红的整个处理过程往往就是围绕着 GOPATH 来处理的。

处理过程

代码放置 src 下

对于历史项目而言，我们优先考虑将项目放到 GOPATH/src 目录下。

首先查看你的公共 GOPATH 配置，如果没有的话建议创建一个，这个环境变量 GoLand 也能够读取到。

历史项目建议直接移到 $GOPATH/src 目录下，src 目录不存在的话可以手工建一个。

为什么要放在 src 下呢？

因为 GOPATH 下存在三个功能目录（约定目录）：

1. src：默认约定编译时查找代码的地方，也是我们项目代码存放的地方。
2. bin：二进制文件下载目的地，主要存放 go get 安装的内容，以及项目编译后的可执行文件也存放于此。
3. pkg：编译过程文件（.a 格式）存放路径，如果编译时发现源码没有变动，就不会重新编译 .a 文件。

注意：GOPATH 可以配置多个，一般多用于特殊情况下（比如同项目多版本并行开始），正常避免混乱，建议配置一个习惯的目录即可。

Project GOPATH

如果只是单纯不想放在 /src 下，少年！我劝你耗子尾汁！

但是对于某些特殊的项目，比如其依赖的某个包的版本比较特殊，其他大部分项目用的是别的版本，这时候可以考虑 Project GOPATH。

GoLand 提供了一个 Project GOPATH 配置项，可以理解为项目级的 GOPATH 环境变量配置，仅仅对当前项目生效。

你可以将具体项目的位置配置进来，该配置也均需约定目录的规则，相当于增加一个独立的 GOPATH 位置。

Project GOPATH 和 直接配置多个系统 GOPATH 还是有很大区别的：

1. Project GOPATH 仅对当前项目生效。
2. Project GOPATH 可以理解为系统 GOPATH 的定制化补充，实际编译依旧会尝试去系统 GOPATH 寻找代码。

形象一点来说是一个私有化的 GOPATH，只有自己可以使用和访问。

其他错误

正常来说，只要代码放在 $GOPATH/src 目录下，使得编译器能够寻找到，几乎可以解决所有问题。

特殊引用路径

这里记录一个有趣的案例。

实际上最终还是没有脱离 $GOPATH/src 的问题。

导入一个旧工程发现，main.go 中 import 飘红，发现子目录下确实存在一个叫 run 的包，但是就是导入不进来，为什么？

答：依照 import 的 URL 相对于 src 目录调整一下项目的外部目录结构（归根结底还是编译器在 src 下找不到对应的代码所致）。