查到的可能原因：
1.本地的go編譯器版本
2. go module構建模式未開啟
3. 是否在go.mod所在目錄執行的go mod tidy

解析

一開始發布的時候 一開始go發布的時候是沒有包管理的
go get命令會根據路徑，把相應的模塊獲取并保存$GOPATH/src
也沒有版本的概念，master就代表穩定的版本
后來引進了Go Module 在GO1.11引入，不再是只有一個版本了，利用go.mod記錄每個包的版本

于是問題就來了

到底是按照$GOPATH的規則走還是按照Go Module來呢？

GO111MODULE是一個環境變量，用于改變go引入包的方式

Go1.11和Go1.12

GO111MODULE=on
這個設置會強迫使用Go modules，即使項目在你的GOPATH里。需要go.mod才能工作。
GO111MOUDLE=off，使用GOPATH的方式，即使在GOPATH外邊
GO111MODULE=auto，默認設置。

當你不在GOPATH內的時候，就類似GO111MODULE=on

當你在GOPATH內的時候，即使存在go.mod，也是GO111MODULE=off的效果

當你在GOPATH內，然后你需要GO modules來做一些操作的時候（如go get一個特定的版本），那就需要這么干：
GO111MODULE=on go get xxxxx

Go 1.13，auto的意思改變了： 如果找到了go.mod，或者在沒有go.mod，但是在GOPATH外，那效果就是GO111MODULE=on（強迫使用go module）。所以你可以把所有的倉庫都保存在你的GOPATH

why?
沒有go.mod的時候，在GOPATH里，效果就是GO111MODULE=off（獲取包并放在$GOPATH/src/）

檢查

1.本地的go編譯器版本

項目版本是1.16，這里有go.mod默認為GO111MODULE=on

2.go module構建模式未開啟

保險起見

win

set GO111MODULE=auto

linux

export GO111MODULE=auto

果然沒有用

go mod指令

3. 是否在go.mod所在目錄執行的go mod tidy

發現是第三個原因

應該在douyinService下執行而不是DouYin

總結