os.Executable()返回当前可执行文件的绝对路径，自动解析符号链接；需配合filepath.Dir()提取目录，再用filepath.Join()拼接资源路径以确保跨平台兼容性。
用 os.Executable 获取可执行文件路径，但要注意符号链接
go 程序启动时，os.executable() 返回的是当前二进制文件的绝对路径（不是源码路径），这是最常用也最可靠的方式。但它默认会解析符号链接——如果你用 ln -s /path/to/app /usr/local/bin/app 启动程序，它返回的是目标文件路径，不是 /usr/local/bin/app。
如果需要保留原始调用路径（比如调试时想确认用户从哪启动的），得自己读取 /proc/self/exe（Linux）或用 os.Readlink("/proc/self/exe") 配合错误处理；macOS 要用 syscall.Syscall(syscall.SYS_IOCTL, uintptr(fd), uintptr(0x4004667A), uintptr(unsafe.Pointer(&buf[0])))（不推荐手动写），所以多数场景直接信任 os.Executable() 更稳妥。
示例：
exePath, err := os.Executable()
if err != nil {
log.Fatal(err)
}
fmt.Println(exePath) // 如：/home/user/myapp
用 filepath.Dir 提取目录，别直接拼接字符串
拿到 os.Executable() 返回的完整路径后，若要获取程序所在目录（常用于读配置、找资源文件），必须用 filepath.Dir()，而不是用 strings.Split() 或正则去截断。Windows 和 Linux 路径分隔符不同，filepath.Dir() 会自动适配。
常见错误是写成 strings.TrimSuffix(exePath, filepath.Base(exePath))，这在末尾带斜杠或路径含重复分隔符时出错；还有人用 path.Dir()（注意是 path 不是 filepath），它不处理 Windows 反斜杠，会导致路径失效。
-
filepath.Dir("/a/b/c")→"/a/b" -
filepath.Dir(`C:\app\main.exe`)→`C:\app` -
filepath.Dir("/a/b/")→"/a/b"（自动清理尾部斜杠）
运行时路径可能和构建路径不一致，别硬编码相对路径
Go 程序打包后常被移动到任意位置运行（比如 cp myapp /usr/local/bin），此时 os.Executable() 指向新位置，而源码中写的 "./config.yaml" 会从当前工作目录（os.Getwd()）开始找，不是从二进制所在目录找。两者极易混淆。
正确做法是：先用 os.Executable() + filepath.Dir() 得到程序根目录，再用 filepath.Join() 拼接资源路径：
exePath, _ := os.Executable() exeDir := filepath.Dir(exePath) configPath := filepath.Join(exeDir, "config.yaml") data, _ := os.ReadFile(configPath)
如果程序允许用户指定配置路径（如命令行参数 -config），优先用参数值，fallback 到上述逻辑。
交叉编译时 os.Executable 在非 Unix 系统上可能失败
在 Windows 上交叉编译 Linux 程序（或反之），os.Executable() 本身仍可用，但某些环境（如容器内无 /proc、或被 seccomp 限制）会返回 exec: not started 或其他 syscall 错误。这不是 Go bug，而是底层系统能力缺失。
应对策略是加 fallback：先试 os.Executable()，失败后尝试读取 os.Args[0] 并转为绝对路径（用 filepath.Abs()），虽然 os.Args[0] 可能是相对路径或空，但比 panic 好：
exePath, err := os.Executable()
if err != nil {
if len(os.Args) > 0 {
exePath, _ = filepath.Abs(os.Args[0])
}
}
真正难处理的是那些连 os.Args[0] 都不可靠的嵌入式或沙箱环境——这时候得靠构建时注入路径（如 -ldflags "-X main.builtDir=/opt/myapp"），但这就超出运行时获取的范畴了。
