os.Getwd 返回进程启动时所在目录的绝对路径，非源码或可执行文件目录，常导致配置文件加载失败；应优先用 os.Executable 结合 filepath.EvalSymlinks 获取二进制所在目录。
os.Getwd 返回的是什么路径
os.Getwd 返回的是进程启动时所在目录的绝对路径，不是源码文件所在位置，也不是可执行文件所在目录。这点常被误认为是“项目根目录”，结果在 systemd 服务、Docker 容器或 IDE 调试中跑出来路径完全不对。
常见错误现象：open config.yaml: no such file or directory，但文件明明放在 main.go 同级；本质是程序从 /root 或 / 启动，os.Getwd() 就返回那个路径。
- 使用场景：适合读取“当前 shell 执行位置”的配置，比如命令行工具接受相对路径参数时做拼接
- 不适用场景：加载内嵌资源、查找项目固定配置文件、构建时确定源码位置
- 注意：该调用可能失败（如工作目录被删除），必须检查 error，不能忽略
想定位 main.go 所在目录该用 runtime.Executable + filepath.EvalSymlinks
Go 没有直接获取源码路径的 API，但多数情况下你真正想要的是“编译后二进制文件所在的目录”——这比 os.Getwd() 更稳定，尤其在服务化部署中。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用
os.Executable()获取二进制路径，再用filepath.Dir()和filepath.EvalSymlinks()处理软链 - 别只用
filepath.Dir(os.Args[0])：它在 symlinks 下失效，且不处理空参（如go run场景） - Windows 下注意路径分隔符，统一用
filepath.Join()拼接，别硬写"\"或"/"
示例：
exePath, err := os.Executable()
if err != nil {
log.Fatal(err)
}
exeDir, err := filepath.EvalSymlinks(filepath.Dir(exePath))
if err != nil {
log.Fatal(err)
}
configPath := filepath.Join(exeDir, "config.yaml")
go run 时 os.Getwd 和 Executable 行为差异很大
go run main.go 是个特例：它先编译到临时目录再执行，所以 os.Executable() 返回的是类似 /tmp/go-buildxxx/b001/exe/main 的路径，而 os.Getwd() 才是你敲命令时所在的目录。
这意味着：
- 本地开发调试时，靠
os.Getwd()加载同级配置最简单，但上线前必须切换逻辑 - 无法靠单一方式兼容
go run和正式部署，得加判断：检查os.Args[0]是否含"go-build"或临时路径特征（不推荐），更稳妥的是用构建 tag 或环境变量区分模式 - 如果真要支持
go run并保持路径一致，可提前用os.Chdir(filepath.Dir(os.Args[0]))切过去，但仅限开发阶段，上线会干扰服务工作目录
路径拼接必须用 filepath.Join，别用字符串 +
手动拼接路径是 Go 新手高频翻车点，尤其跨平台时："./" + "config/" + "db.yaml" 在 Windows 上变成 .configdb.yaml，但某些旧版 Windows API 或容器挂载逻辑对反斜杠敏感；更糟的是，若变量含开头 "/"，整个路径就变绝对路径，前面的 "./" 直接失效。
- 永远用
filepath.Join(dir, "config", "db.yaml")，它自动处理分隔符和冗余斜杠 -
filepath.Clean()可用于标准化路径（如把"a/../b"变成"b"），但注意它不处理不存在的路径 - 需要检查路径是否存在？用
os.Stat(path)，别依赖strings.HasPrefix或正则去“猜”
容易被忽略的地方：即使你用了 filepath.Join，如果输入参数本身是绝对路径（比如用户传了 -config /etc/app.conf），Join 会直接返回那个绝对路径——这是正确行为，但得在文档或 flag 解析层明确约定是否允许绝对路径。
