彻底解决Golang获取当前项目绝对路径问题
发布网友
发布时间：6小时前
共1个回答
热心网友
时间：6小时前
由于Golang是编译型语言，获取当前执行目录变得复杂。传统做法是通过启动传参或环境变量手动传递路径，但今天发现了一种更便捷的解决方案。
Go程序有两种执行方式：go run和go build。这两种方式在获取当前执行路径时会产生不同的问题。
下面直接展示代码示例。我们编写一个获取当前可执行文件路径的方法，然后通过go run和go build两种方式来测试。
通过对比执行结果，我们发现go run获取到的路径是错误的。原因是go run会将源代码编译到系统TEMP或TMP环境变量目录中并启动执行，而go build只会在当前目录编译出可执行文件，并不会自动执行。
我们可以简单理解为，go run main.go等价于go build & ./main。虽然两种执行方式最终都是一样的过程，但他们的执行目录却完全不一样了。
在我查看服务日志(zap库)时，发现了一种新的解决方案。比如一条简单的日志，服务是通过go run启动的，但日志库却正确地打印出了程序路径D:/Projects/te-server/modules/es/es.go:139。
我发现这是通过runtime.Caller()实现的，而所有Golang日志库都会有runtime.Caller()这个调用。我以为找到了最终答案，然后写代码试了下，结果完全正确！但后来发现，在Linux上运行时，它会打印出Windows的路径，这让我很失望。
我意识到，既然go run时可以通过runtime.Caller()获取到正确的结果，go build时也可以通过os.Executable()来获取到正确的路径；那如果我能判定当前程序是通过go run还是go build执行的，选择不同的路径获取方法，所有问题不就迎刃而解了吗。
Go没有提供接口来区分程序是go run还是go build执行，但我们可以根据go run的执行原理来判断。我们可以直接在程序中对比os.Executable()获取到的路径是否与环境变量TEMP设置的路径相同，如果相同，说明是通过go run启动的，因为当前执行路径是在TEMP目录；不同的话自然是go build的启动方式。
下面是完整代码：
在windows执行
在windows编译后上传到Linux执行
对比结果，我们可以看到，在不同的系统中，不同的执行方式，我们封装的getCurrentAbPath方法最终都输出的正确的结果，perfect！
