filepath.Abs不会panic，但会返回非nil error；常见于路径含非法字符、超长、Windows空字符串或不可访问驱动器等场景。
filepath.Abs 会 panic 吗？什么情况下返回 error
filepath.Abs 不会 panic，但会返回非 nil 的 error。常见触发条件包括：
- 路径含非法字符（如
\0、控制字符）或超出系统限制（WindowsMAX_PATH=260） - 在 Windows 上传入空字符串
""或仅驱动器号（如"C:"），而该驱动器不可访问 - 路径中存在无法解析的符号链接环（极少见，但可能触发底层系统调用失败）
它不检查目标是否存在——filepath.Abs("nonexist/foo.txt") 只要父目录结构合法，就返回绝对路径 + nil 错误。
为什么不能手动拼接 os.Getwd() 和相对路径
手动拼接 os.Getwd() 和相对路径看似简单，但容易漏掉关键路径规范化逻辑：
-
"./"、"../"、重复斜杠（"a//b"）不会被自动清理，导致结果和filepath.Abs不一致 - Windows 下大小写与盘符一致性易出错：当前工作目录是
"C:\Users\Alice"，但"..\bob\file.txt"需基于实际文件系统解析，硬拼可能忽略C:盘挂载状态 - 跨平台行为不统一：
filepath.Abs自动屏蔽/与\差异；自己拼接需额外调用filepath.Clean和filepath.FromSlash
更稳妥的做法始终是走 filepath.Abs(rel)，而不是 filepath.Join(wd, rel)。
os.Executable() 和 os.Getwd() 哪个更适合定位程序资源
取决于你要找的是“程序启动时所在目录”还是“程序二进制文件所在目录”：
-
os.Getwd()返回当前工作目录，受os.Chdir()影响，且每次调用都可能因环境变化而不同（Go 1.20+ 还有getwd缓存风险） -
os.Executable()返回当前可执行文件的绝对路径（已解析符号链接），稳定可靠；再用filepath.Dir()提取目录，就是程序根目录 - 读配置、加载模板、打开内置资源时，应优先用
filepath.Dir(os.Executable())，而非os.Getwd()
例如：configPath := filepath.Join(filepath.Dir(os.Executable()), "config.yaml") —— 这才是跨平台、可移植的写法。
符号链接环境下 filepath.Abs 怎么表现
filepath.Abs 返回的是「解析符号链接后的最终路径」，不是“从 cwd 到目标的逻辑路径”：
- 假设
/home/user/link → /tmp/real，当前工作目录是/home/user，那么filepath.Abs("link/sub")返回/tmp/real/sub - 如果你需要保留 symlink 层级（比如记录源路径引用关系），就得用
filepath.Join(filepath.Dir(os.Getwd()), rel)再filepath.Clean()，但这不等价于真实路径——os.Stat可能失败 - 配置类场景建议用
filepath.Abs；构建/调试类工具若需追踪原始路径层级，则应避免自动解链
真正容易被忽略的是：filepath.Abs 的行为依赖底层系统调用，它不保证“路径一定可访问”，只保证“路径字符串语义合法”。判断文件是否存在，必须单独调用 os.Stat 或 os.ReadFile。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
