最推荐用Path("xxx").resolve()处理相对路径，它自动解析..、.和符号链接，返回规范化的绝对物理路径，不依赖当前工作目录，比os.path.abspath()更可靠。
用 pathlib.Path.resolve() 处理相对路径最可靠
直接调用 Path("xxx").resolve() 是当前最推荐的方式，它自动处理 ..、.、符号链接（默认展开），并返回规范化的绝对物理路径。相比旧的 os.path.abspath()，它不依赖当前工作目录的“偶然正确”，也不受 os.chdir() 干扰（只要路径本身可访问）。
常见错误是传入空字符串或仅含空白的字符串，会触发 FileNotFoundError；还有人误以为 .resolve() 总是成功——其实当路径中某一级不存在时，它会报错，不是静默补全。
- 确保目标路径在文件系统中真实存在（至少父目录存在），否则抛
FileNotFoundError - 若需容忍缺失路径，先用
.exists()或try/except包裹 - 想保留符号链接不展开？加参数
strict=False, follow_symlinks=False（但此时不保证是“物理路径”）
为什么不用 os.path.abspath()？
os.path.abspath() 只做字符串拼接 + 规范化，不检查文件是否存在，也不解析符号链接。它把相对路径“硬贴”到 os.getcwd() 后面，一旦工作目录被改过（比如测试中 os.chdir()），结果就不可靠。更隐蔽的问题是：它对 ../nonexistent/xxx 这类路径也返回一个看似合法的“绝对路径”，但实际根本打不开。
典型误用场景：写配置加载器时用 abspath("config.yaml")，结果部署时因启动路径不同而读错文件。
立即学习“Python免费学习笔记（深入）”；
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 它不校验路径真实性，容易掩盖环境差异问题
- 无法区分软链和真实路径，调试时可能绕晕自己
- Python 3.4+ 应该优先迁移到
pathlib
处理配置文件路径的实用模式
项目里最常遇到的是“从代码位置反推配置路径”，比如 myapp/main.py 想读同级的 config.yaml，或上层的 etc/config.yaml。这时不能依赖 os.getcwd()，而要用 __file__ 定位源码位置再构造。
from pathlib import Path # 获取当前脚本所在目录 here = Path(__file__).parent config_path = (here / "config.yaml").resolve() # 或向上两级找 etc/ etc_config = (here.parent.parent / "etc" / "config.yaml").resolve()
-
__file__是运行时的真实路径，比sys.argv[0]更稳定（尤其被打包成 exe 或用-m运行时） - 用
/操作符拼接路径，比字符串+或os.path.join()更安全、可读 - 如果配置路径可能不存在，建议在
.resolve()前先.exists()判断，避免异常中断流程
Windows 下盘符和 UNC 路径要注意什么
在 Windows 上，.resolve() 会补全盘符（如 "foo.txt" → "C:\...\foo.txt"），但遇到 UNC 路径（\\server\share）时行为略有不同：它不会强制转成本地盘符，而是保持 UNC 格式并规范化路径分隔符。这点和 abspath() 不一致（后者可能错误地塞进当前盘符）。
容易被忽略的是：某些老旧工具或网络存储不支持 UNC 路径中的 ..，这时 .resolve() 展开后仍可能失败。如果必须适配这类环境，得手动用 .as_posix() 或正则替换掉 \，但本质是环境限制，不是 Python 的问题。
- UNC 路径下
.resolve()返回的仍是Path对象，str(p)得到的是带双反斜杠的字符串 - 跨平台代码中，避免硬编码
"\"或"/"，始终用Path对象操作 - CI/CD 流水线跑在 Linux 但目标部署是 Windows？务必在对应系统上验证路径解析逻辑
路径解析看着简单，但一旦混入符号链接、打包工具（PyInstaller）、容器挂载或 Windows UNC，就很容易在某个环境里突然失效。关键是别假设“当前目录就是项目根”，老实用 <strong>file</strong> 锚定，再靠 .resolve() 做终态校验。
