Dependencies should now be referenced with modules(源自the vgo project)：

Go 1.11 adds preliminary support for a new concept called “modules,” an alternative to GOPATH with integrated support for versioning and package distribution.
Using modules,developers are no longer confined to working inside GOPATH,version dependency information is explicit yet lightweight,and builds are more reliable and reproducible.

见Defining a module.(和original design proposal)

2015年6月更新：第一次支持vendoring正在进入Go 1.5！
见c/10923/：

When GO15VENDOREXPERIMENT=1 is in the environment,this CL changes the resolution of import paths according to the Go 1.5 vendor proposal:

• If there is a source directory d/vendor,then,when compiling a source file within the subtree rooted at d,import "p" is interpreted as import "d/vendor/p" if that exists.
• When there are multiple possible resolutions,the most specific (longest) path wins.
• The short form must always be used: no import path can contain “/vendor/” explicitly.
• Import comments are ignored in vendored packages.

2015年3月更新：go团队正在考虑定义与该语言集成的go依赖管理系统：辩论是in this thread.

We think it’s time to start addressing the dependency & vendoring issue,especially before too many conflicting tools arise and fragment best practices in the Go ecosystem,unnecessarily complicating tooling. It would be nice if the community could converge on a standard way to vendor.

Our proposal is that the Go project,

1. officially recommends vendoring into an “07006” directory with import rewriting (not GOPATH modifications) as the canonical way to pin dependencies.
2. defines a common config file format for dependencies & vendoring
3. makes no code changes to cmd/go in Go 1.5. External tools such as “godep” or “nut” will implement 1) and 2). We can reevaluate including such a tool in Go 1.6+.

godep的一个可能的缺点是你不能再直接使用“go build”或“go test”了.
您需要在这些命令之前使用godep(或类型godep save).

另一种选择是glide,它仍然与经典的go命令兼容.

• Manage project-specific GOPATHs
• Ease dependency management
• Support versioning packages
• Support aliasing packages (e.g. for working with github forks)
• Remove the need for “vendoring” or munging import statements
• Work with all of the go tools

更一般地,文章“Know your guarantees,Go edition”很有趣：

It’s also a deliberate choice,where the Go authors chose not to implement a feature when they felt that the trade-offs were no good.

One low-level reason they made this choice is to avoid slow compilation and bloated binaries (which are two sides of the same coin).
Remember,packages depend on other packages. So Foo might depend on Bar 2.1. Foo might also depend on Baz which in turn depends on Bar 1.9,and on down the tree. So that would mean compiling and linking several copies of nearly identical code.

Depending on several versions of the same package also means knowing which version one is calling,whereby the dependency mess seeps into your source code.

Which leads us to the high-level reasoning behind the Go platform punting on this feature: they did not have a logical solution they considered acceptable. It’s not that they don’t understand the problem; it’s that,at the moment,there is not a solution they like. So they choose no feature over over a regressive one.