查到的可能原因：
1.本地的go编译器版本
2. go module构建模式未开启
3. 是否在go.mod所在目录执行的go mod tidy
GO111MODULE
参考
中文：https://learnku.com/go/t/39086
英文原文：https://dev.to/maelvls/why-is-go111module-everywhere-and-everything-about-go-modules-24k
解析
一开始发布的时候
一开始go发布的时候是没有包管理的
go get命令会根据路径，把相应的模块获取并保存在
G
O
P
A
T
H
/
s
r
c
也
没
有
版
本
的
概
念
，
‘
m
a
s
t
e
r
‘
就
代
表
稳
定
的
版
本
后
来
引
进
了
G
o
M
o
d
u
l
e
在
G
O
1.11
引
入
不
再
是
只
有
一
个
版
本
了
利
用
g
o
.
m
o
d
记
录
每
个
包
的
版
本
于
是
问
题
就
来
了
到
底
是
按
照
GOPATH/src 也没有版本的概念，`master`就代表稳定的版本 后来引进了Go Module 在GO1.11引入 不再是只有一个版本了 利用go.mod记录每个包的版本 于是问题就来了 到底是按照
GOPATH/src也没有版本的概念，‘master‘就代表稳定的版本后来引进了GoModule在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
1.13
使用Go 1.13，auto的意思改变了：
如果找到了go.mod，或者在没有go.mod，但是在GOPATH外，那效果就是GO111MODULE=on（强迫使用go module）。所以你可以把所有的仓库都保存在你的GOPATH
why?
没有go.mod的时候，在GOPATH里，效果就是GO111MODULE=off（获取包并放在$GOPATH/src/）
https://ask.csdn.net/questions/1010756?spm=1005.2026.3001.5635&utm_medium=distribute.pc_relevant_ask_down.none-task-ask-2defaultOPENSEARCHRate-1-1010756-ask-1010756.pc_feed_download_top3ask&depth_1-utm_source=distribute.pc_relevant_ask_down.none-task-ask-2defaultOPENSEARCHRate-1-1010756-ask-1010756.pc_feed_download_top3ask
项目版本是1.16，这里有go.mod默认为GO111MODULE=on
保险起见
win
set GO111MODULE=auto
linux
export GO111MODULE=auto
果然没有用
go mod指令
发现是第三个原因
应该在douyinService下执行而不是DouYin
