彻底解决Golang获取当前项目绝对路径问题
发布网友
发布时间:22小时前
我来回答
共1个回答
热心网友
时间:22小时前
由于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!