goland运行测试时os.getwd()返回测试文件所在目录；正确获取项目根路径应使用runtime.caller(0)定位测试文件再向上跳转，而非依赖os.args或os.getwd()。
GoLand 运行测试时 os.Getwd() 返回的是哪里
GoLand 点击 ▶️ 运行单个 test 函数时，默认工作目录（os.Getwd()）是测试文件所在的目录，不是项目根目录，也不是 main.go 所在目录。比如你在 tests/config_test.go 里调用 os.ReadFile("./config.yaml")，GoLand 实际会去 tests/config.yaml 查找——哪怕你本意是读项目根下的配置。
这和终端里执行 go test ./tests 的行为一致，但和 go run main.go（通常在项目根运行）不一致，路径错位就必然发生。
- 不要依赖 “当前目录” 是项目根，它完全由 GoLand 启动测试时的工作目录决定
- 可以通过在 test 函数开头加
fmt.Println(os.Getwd())确认实际路径 - GoLand 的 Run Configuration → Working directory 默认设为
$ProjectFileDir$，但 test runner 会覆盖它；无法靠 IDE 设置“统一工作目录”来修复
用 filepath.Dir(filepath.Join(os.Args[0], "..")) 不可靠
这个写法常见于网上教程，但它在单元测试里基本失效：os.Args[0] 在 go test 场景下通常是 go 命令本身或临时构建的二进制路径（如 /tmp/go-buildxxx/b001/exe/test），和你的源码位置毫无关系。
更糟的是，GoLand 测试运行器可能根本不启动可执行文件，而是直接注入代码到 go test 进程，此时 os.Args[0] 可能是空、是 go、甚至是 gopls 相关路径，完全不可信。
-
exec.LookPath(os.Args[0])同样无效：测试不是通过可执行文件启动的 -
filepath.Abs("./")得到的是当前工作目录的绝对路径，不是源码所在目录 - 任何基于
os.Args或os.Getwd()的路径推导，在 test 场景下都只是碰运气
正确方案：用 runtime.Caller + filepath.Dir 定位测试文件所在目录
最稳定的方式是获取当前测试函数的源码路径，再向上跳转到资源所在位置。核心是 runtime.Caller(0) —— 它返回调用栈中当前函数的文件名和行号，不受工作目录影响。
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
例如，你的测试文件是 tests/db_test.go，配置文件在项目根 config.yaml，可以这样写：
func TestDBConnect(t *testing.T) {
_, filename, _, _ := runtime.Caller(0)
rootDir := filepath.Dir(filepath.Dir(filename)) // 跳两次：db_test.go → tests/ → 项目根
cfgPath := filepath.Join(rootDir, "config.yaml")
data, err := os.ReadFile(cfgPath)
if err != nil {
t.Fatal(err)
}
// ...
}
-
runtime.Caller(0)返回的是tests/db_test.go的完整路径，真实可靠 - 用
filepath.Dir嵌套调用比硬编码"../.."更安全，避免因目录结构调整导致路径断裂 - 如果配置文件在
configs/子目录，就写filepath.Join(rootDir, "configs", "config.yaml") - 这个逻辑在
go test、GoLand 点击运行、CI 中跑测试都一致生效
更健壮的做法：把资源路径提取成包级变量或 init 函数
重复写 runtime.Caller 很啰嗦，也容易出错。建议在测试文件顶部统一计算一次根路径：
var projectRoot string
func init() {
_, filename, _, _ := runtime.Caller(0)
projectRoot = filepath.Dir(filepath.Dir(filename))
}
func TestLoadConfig(t *testing.T) {
cfgPath := filepath.Join(projectRoot, "config.yaml")
// ...
}
注意：不能在包级用 var projectRoot = ... 直接赋值，因为 runtime.Caller 必须在函数内调用才准确；init() 是唯一安全的包级执行时机。
如果多个测试文件都要读同一组资源，可以把 projectRoot 提到一个独立的 testutil 包里，避免重复逻辑。但别试图在 main 包里复用这套逻辑——runtime.Caller 在非测试上下文里指向的位置可能完全不同。
真正麻烦的从来不是“怎么拼路径”，而是默认假设路径有固定起点。Go 不提供“相对于当前 .go 文件”的路径语法，就得自己用 runtime.Caller 把这个起点找回来——漏掉这一层，所有相对路径在测试里都是纸糊的。
