Go 不愧是新时代的语言，其项目依赖的书写方式，实现了老夫很久之前的一个奢望：云依赖。照此路子，将来区块链相关的 IPFS 也许也能加入到底层技术支持栈里面来。

之前的依赖获取，只知道傻瓜式的 go get 就能够自动解决，昨天编译团队里其他小伙伴没有空维护的从 MinDoc 主干分叉出来的版本时才发现，竟然要用到一个叫 dep 的工具。将 dep 和 go get 执行后的本地文件树做一下对比的话，会发现组织方式上有大不同。

go get 会把依赖与主工程置于接近平等的地位，文件以直截了当的方式存放于 src 目录下。而 dep 则不然，它在与 src 平级的 pkg 目录下创建了属于自己的根目录 dep，所有依赖项目均在其下（中间其实还有一层 sources 目录）。各个依赖项目自己的顶级目录，在组织上选择了命名平坦化的路子。光说不够直观，举例，若依赖的项目是 github.com/golang/appengine，则 go get 的话，本地路径会是 src/github.com/golang/appengine，而 dep 管理下则会是 pkg/dep/sources/https—github.com-golang-appengine，然后，把它们搞到主项目的 vendor 目录下一份。

在过程中还发现了 Visual Studio Code 下，微软的 Go 插件 0.11.9 版本的一个 bug。它自动有 lint 功能，保存时会将无效 import 清理掉，项目依赖于 gopkg.in/russross/blackfriday.v2，调用语句则形如 blackfriday.Run() 这样的，这导致每次 Ctrl-S 都会把相应的 import 语句强行干掉，从而导致编译失败。每次眼睁睁看着我自己刚刚粘贴好的那行代码不翼而飞，还是挺诡异的。

另，昨天趁着促销，在 Microsoft Store 里 71 人民币入了 X410 备用，也许用处不大。