聊一聊，Golang “相對”路徑問題

前言

Golang 中存在各種運行方式，如何正確的引用文件路徑成爲一個值得商議的問題

以 gin-blog 爲例，當我們在項目根目錄下，執行 go run main.go 時能夠正常運行（go build也是正常的）

[$ gin-blog]# go run main.go
[GIN-debug] [WARNING] Running in "debug" mode. Switch to "release" mode in production.
 - using env:    export GIN_MODE=release
 - using code:    gin.SetMode(gin.ReleaseMode)

[GIN-debug] GET    /api/v1/tags              --> gin-blog/routers/api/v1.GetTags (3 handlers)
...

那麼在不同的目錄層級下，不同的方式運行，又是怎麼樣的呢，帶着我們的疑問去學習

問題

1. go run

我們上移目錄層級，到 $GOPATH/src 下，執行 go run gin-blog/main.go

[$ src]# go run gin-blog/main.go
2018/03/12 16:06:13 Fail to parse 'conf/app.ini': open conf/app.ini: no such file or directory
exit status 1

1. go build，執行 ./gin-blog/main

[$ src]# ./gin-blog/main
2018/03/12 16:49:35 Fail to parse 'conf/app.ini': open conf/app.ini: no such file or directory

這時候你要打一個大大的問號，就是我的程序讀取到什麼地方去了

---

我們通過分析得知，Golang的相對路徑是相對於執行命令時的目錄；自然也就讀取不到了

思考

既然已經知道問題的所在點，我們就可以尋思做點什麼 : )

我們想到相對路徑是相對執行命令的目錄，那麼我們獲取可執行文件的地址，拼接起來不就好了嗎？

實踐

我們編寫獲取當前可執行文件路徑的方法

import (
    "path/filepath"
    "os"
    "os/exec"
    "string"
)

func GetAppPath() string {
    file, _ := exec.LookPath(os.Args[0])
    path, _ := filepath.Abs(file)
    index := strings.LastIndex(path, string(os.PathSeparator))

    return path[:index]
}

將其放到啓動代碼處查看路徑

log.Println(GetAppPath())

我們分別執行以下兩個命令，查看輸出結果

1. go run

$ go run main.go
2018/03/12 18:45:40 /tmp/go-build962610262/b001/exe

1. go build

$ ./main
2018/03/12 18:49:44 $GOPATH/src/gin-blog

剖析

我們聚焦在 go run 的輸出結果上，發現它是一個臨時文件的地址，這是爲什麼呢？

在go help run中，我們可以看到

Run compiles and runs the main package comprising the named Go source files.
A Go source file is defined to be a file ending in a literal ".go" suffix.

也就是 go run 執行時會將文件放到 /tmp/go-build... 目錄下，編譯並運行

因此go run main.go出現/tmp/go-build962610262/b001/exe結果也不奇怪了，因爲它已經跑到臨時目錄下去執行可執行文件了

---

這就已經很清楚了，那麼我們想想，會出現哪些問題呢

• 依賴相對路徑的文件，出現路徑出錯的問題
• go run 和 go build 不一樣，一個到臨時目錄下執行，一個可手動在編譯後的目錄下執行，路徑的處理方式會不同
• 不斷go run，不斷產生新的臨時文件

這其實就是根本原因了，因爲 go run 和 go build 的編譯文件執行路徑並不同，執行的層級也有可能不一樣，自然而然就出現各種讀取不到的奇怪問題了

解決方案

一、獲取編譯後的可執行文件路徑

1. 將配置文件的相對路徑與GetAppPath()的結果相拼接，可解決go build main.go的可執行文件跨目錄執行的問題（如：./src/gin-blog/main）

import (
    "path/filepath"
    "os"
    "os/exec"
    "string"
)

func GetAppPath() string {
    file, _ := exec.LookPath(os.Args[0])
    path, _ := filepath.Abs(file)
    index := strings.LastIndex(path, string(os.PathSeparator))

    return path[:index]
}

但是這種方式，對於go run依舊無效，這時候就需要2來補救

1. 通過傳遞參數指定路徑，可解決go run的問題

package main

import (
    "flag"
    "fmt"
)

func main() {
    var appPath string
    flag.StringVar(&appPath, "app-path", "app-path")
    flag.Parse()
    fmt.Printf("App path: %s", appPath)
}

運行

go run main.go --app-path "Your project address"

二、增加os.Getwd()進行多層判斷

參見 beego 讀取 app.conf 的代碼

該寫法可兼容 go build 和在項目根目錄執行 go run ，但是若跨目錄執行 go run 就不行

三、配置全局系統變量

我們可以通過os.Getenv來獲取系統全局變量，然後與相對路徑進行拼接

1. 設置項目工作區

簡單來說，就是設置項目（應用）的工作路徑，然後與配置文件、日誌文件等相對路徑進行拼接，達到相對的絕對路徑來保證路徑一致

參見 gogs 讀取GOGS_WORK_DIR進行拼接的代碼

1. 利用系統自帶變量

簡單來說就是通過系統自帶的全局變量，例如$HOME等，將配置文件存放在$HOME/conf或/etc/conf下

這樣子就能更加固定的存放配置文件，不需要額外去設置一個環境變量

（這點今早與一位SFer討論了一波，感謝）

拓展

go test 在一些場景下也會遇到路徑問題，因爲go test只能夠在當前目錄執行，所以在執行測試用例的時候，你的執行目錄已經是測試目錄了

就會產生類似的問題

小結

這三種解決方案，在目前可見的開源項目或介紹中都能找到這些的身影

優缺點也是顯而易見的，我認爲應在不同項目選定合適的解決方案即可