Goを始めたばかりでgo modやgo getやgo mod vendorがよくわかってないので、そのメモ
間違ってる可能性はあるので、そこはご了承ください
go.modファイルはGemfile.lockやpackage-lock.jsonみたいなもので、go.sumファイルはgo.modのchecksum
go get <ライブラリのpath>で、go.modとgo.sumにライブラリ名がバージョン明示で書き込まれ、GOPATH/pkg/mod配下にgo.modに書かれたバージョンのそのライブラリがインストールされる（Gemfileに欲しいgemを追記してbundle installしてgemを取り込むのとは流れが違う）
アプリケーションのコード内で外部ライブラリを使用する際はimportの記述が必要なわけだが、go.modに書かれたバージョンが適用され、goがGOPATH/pkg/mod配下にインストールされたものを参照しにいく
なのでAプロジェクトではバージョン2.2のXライブラリを、Bプロジェクトではバージョン3.3のXライブラリを使用したいとなった場合でも、GOPATH/pkg/mod配下にバージョン2.2とバージョン3.3のXライブラリが両方インストールされていれば、プロジェクトごとで使い分けることができる
また、go1.15まではgo getしなくても、先にアプリケーションのコードに外部ライブラリのimportの記述をしてgo buildやgo testをすることでも、go.modとgo.sumに記述が追加されたりGOPATH/pkg/mod配下に外部ライブラリをインストールしてくれていた
既存プロジェクトの環境構築する際は自分のローカルpc（GOPATH/pkg/mod配下）に不足している外部ライブラリをインストールしなければいけないのだが、その時はgo mod tidyを使うのが良い
go mod tidyはプロジェクトの全てのgoファイルのimportの記述を見て、go.modを書き換えてくれて、さらにGOPATH/pkg/mod配下に不足しているライブラリをインストールもしてくれる
go mod vendorでgo.modにファイルに記載されているライブラリを、vendor以下にコピーしてくれる
vendorディレクトリがある場合、アプリケーションのコードが外部ライブラリを参照する際GOPATH/pkg/mod配下ではなく、vendorディレクトリ以下にある外部ライブラリを参照するようになる
go1.11が出るまでは、glide,depといったサードパーティを使うか上記で述べたvendorディレクトリを用意するやり方でないとプロジェクト毎に外部ライブラリのバージョンを分けるということができなかったが
go1.11以降はgo modules（go.mod）が出てきたのでvendorを用いるやり方やglide,depといったサードパーティを使うやり方は無くなってきている
参考サイト
https://ren.nosuke.me/blog/202002/20200222/
https://qiita.com/eihigh/items/9fe52804610a8c4b7e41
https://blog.mmmcorp.co.jp/blog/2019/10/10/go-mod/