filepath.Abs 不会 panic，但会返回非 nil 的 error；常见于路径含非法字符、超长、Windows 空字符串或不可访问驱动器等场景。
filepath.Abs 会 panic 吗？什么情况下出错
filepath.Abs 不会 panic，但会返回非 nil 的 error。常见触发条件是路径里含非法字符、超出系统限制，或在 Windows 上传入空字符串、仅含驱动器号（如 "C:"）而没跟路径分隔符。
- Linux/macOS 下传入
""或"./"通常没问题；Windows 下"C:"会被认为是“当前目录在 C 盘”，但若 C 盘不可访问（比如未挂载），就会报"The system cannot find the path specified." - 路径中含
"\0"、控制字符、或长度超 OS 限制（如 Windows MAX_PATH=260），filepath.Abs直接返回错误，不会静默截断 - 它不检查目标是否存在——
filepath.Abs("nonexist/foo.txt")只要父目录结构合法，照样返回绝对路径 +nil错误
相对路径转绝对路径，为什么不能直接拼接 cwd
手动拼 os.Getwd() 和相对路径看似简单，但容易漏掉路径规范化逻辑，导致结果和预期不符。
-
filepath.Abs会自动处理"../"、"./"、重复分隔符（如"a//b"→"a/b"），而path.Join(os.Getwd(), rel)不会——path.Join("a", "b/../c")得到"a/b/../c"，不是"a/c" - Windows 下大小写敏感性不同：当前工作目录可能是
"C:\Users\Alice"，但传入"..\bob\file.txt"，filepath.Abs会基于实际文件系统解析，而硬拼可能忽略盘符一致性 - 跨平台行为统一：用
filepath.Abs能屏蔽/vs\差异；自己拼接需额外调用filepath.Clean和filepath.FromSlash补救
filepath.Abs 在 symlink 环境下怎么表现
filepath.Abs 返回的是「解析符号链接后的最终路径」，不是“从 cwd 到目标的逻辑路径”。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 假设
/home/user/link → /tmp/real，且当前工作目录是/home/user，那么filepath.Abs("link/sub")返回/tmp/real/sub，不是/home/user/link/sub - 如果只想做纯字符串转换（保留 symlink 层级），得用
filepath.Join(filepath.Dir(os.Getwd()), rel)再filepath.Clean，但注意这不等价于真实路径——os.Stat可能失败 - 需要区分场景：配置文件路径解析建议用
filepath.Abs（用户关心的是最终读哪个文件）；构建工具中记录“源路径引用关系”则应避免自动解链
Go 1.20+ 中 filepath.Abs 的隐含依赖
filepath.Abs 内部调用 os.Getwd()，而后者在 Go 1.20+ 默认启用 getwd 系统调用缓存。这意味着：如果程序运行中工作目录被外部修改（比如被 os.Chdir 或其他进程改写），缓存可能过期，导致 filepath.Abs 返回旧路径。
立即学习“go语言免费学习笔记（深入）”；
- 典型坑：命令行工具启动后先
os.Chdir("/tmp")，再多次调用filepath.Abs("config.yaml")，第一次对，后续可能错——除非显式清缓存：os.Unsetenv("PWD"); os.Getwd() - 更稳的做法：在关键路径计算前主动调用一次
os.Getwd()并缓存结果，再传给filepath.Abs（注意filepath.Abs第二个参数不是 cwd，它只认当前进程 cwd） - 无权访问 cwd 的环境（如某些容器、chroot）下，
filepath.Abs会失败，此时必须传入已知基准路径并用filepath.Join+filepath.Clean
