20240926 关于Goland处理wsl-GOROOT原理猜测
GOROOT的原理
go sdk与java jdk类似，是go的编译工具链的集合。
在windows上，我们通过在系统环境变量中添加GOROOT并设置为go sdk地址，使得命令行可以访问到go sdk并执行go test、build等命令，这样设置的变量是全局生效的；
而在linux中，我们并没有修改系统环境变量，而是安装go后，将go sdk地址写为GOROOT写在/home/user_name/.bashrc中，并export PATH=$PATH;$GOROOT/bin来调用go sdk，这样设置的变量只在bash中生效（重点来了）
GOPATH已经被弃用，影响不是很大。
问题在哪里？
所以，当Goland调用make时，GOROOT实际上并没有定义，而为了弥补这一点，Goland非常“聪明”地将ide保管的GOROOT、GOPATH加入环境变量发送给make，从而使它能调用go sdk。
这样有什么问题呢？这一套在windows上啥问题也没有，甚至可以支持自定义go sdk版本，但是，聪明的读者可能已经发现，这个GOROOT和make看到的GOROOT根本不是一个东西！！！
我们通过在makefile开头打印GOROOT变量来看一下Goland干了什么好事？
好家伙，他直接把//wslUbuntu给发了过去，这不是三体人和地球人聊科学吗？make直接看不懂了，直接罢工。
解决办法：有，但是极为丑陋
只说结论的话，确实是有的。
步骤：
- 右上角齿轮->Go设置->GOROOT->无SDK
- 右上角三个点->编辑配置->取消包含系统变量->添加用户环境变量（GOROOT=“/usr/local/go/bin/”）
- 在makefile中添加GOLOCAL=$(GOROOT)/go
- 使用GOLOCAL进行GO操作
代价：
- 正常wsl开发需要设置Go sdk，这下又要重新设置
- 正常终端开发需要用这个makefile的话，又要把makefile改回去