resolve() 在中文路径下抛 FileNotFoundError 主因是底层系统调用（如 os.stat）无法访问路径，而非编码问题；常见于父目录不可遍历、符号链接失效、挂载未就绪或权限不足等场景。
resolve() 为什么会在中文路径下抛出 FileNotFoundError
resolve() 在遇到含中文或特殊字符的路径时失败，通常不是编码问题本身，而是底层系统调用（如 os.stat()）无法访问目标路径。Python 3.6+ 的 pathlib 默认使用系统 locale 编码解析路径字符串，但真正卡住的是：路径存在、但父目录不可遍历，或符号链接指向了不存在/无权限访问的位置。Windows 上常见于 OneDrive 或 WSL 挂载路径；macOS/Linux 则多因挂载点未就绪或 NFS 权限限制。
- 先用
Path.exists()和Path.is_dir()分别检查路径本身和各级父目录是否可访问 - 避免直接对用户输入的原始字符串调用
resolve()，先用Path.cwd() / user_input构造相对路径再判断 - 在 Windows 上若路径含
~或环境变量（如%USERPROFILE%），需先用os.path.expandvars()展开，pathlib不自动处理这些
resolve(strict=False) 并不能绕过编码或权限问题
strict=False 只影响“路径是否存在”的语义：它会让 resolve() 在最终目标不存在时仍尝试向上解析已存在的部分，返回一个“逻辑上最接近”的绝对路径。但它**不会跳过权限拒绝、设备未就绪、或字节序列非法导致的解码失败**。例如：Path(b'/home/你').resolve(strict=False)（传入错误 UTF-8 字节）会直接抛 UnicodeDecodeError，根本到不了 strict 判断逻辑。
- 确保输入是
str而非bytes——pathlib对 bytes 路径支持极弱，且各平台行为不一致 - 若必须处理未知编码的路径（如旧系统遗留文件名），改用
os.fsencode()/os.fsdecode()手动转换，再传给os.path系列函数 -
resolve(strict=False)适合构建“尽力而为”的路径补全，不适合容错读取
替代方案：用 absolute() + exists() 组合规避 resolve 的副作用
当只需要规范化路径格式（转绝对、去 ./..），又不想触发文件系统访问，absolute() 是更轻量的选择。它只做字符串运算，不调用 stat() 或 readlink()，因此不会因权限或编码失败。但要注意：它不解析符号链接，也不验证路径真实性。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 安全场景优先用：
Path(user_input).expanduser().absolute()—— 覆盖~、相对路径、空路径等常见情况 - 若后续操作确实需要真实存在性校验，把
exists()单独拆出来，在absolute()之后显式调用 - Linux/macOS 下符号链接需保留原始语义时，用
Path.resolve(strict=False)+ 手动os.readlink()补充处理，比强依赖resolve()更可控
Windows 上的长路径和保留字陷阱
Windows 对路径长度和保留名（如 AUX、CON、NUL）有硬性限制。resolve() 在遇到这类路径时可能静默截断、返回错误结果，或抛出看似无关的 FileNotFoundError。这不是编码问题，但常被误判。
立即学习“Python免费学习笔记（深入）”；
- 启用长路径支持：确保 Windows 组策略中「启用 Win32 长路径」已开启，并在 Python 启动前设置环境变量
SET PYTHONIOENCODING=utf-8 - 避免使用保留字作文件名：用
Path.name提取最后一级后，检查是否在{"CON", "PRN", "AUX", "NUL", "COM1", "LPT1"}中 - 调试时打印
str(path)和path.as_posix()对比，确认反斜杠是否被意外转义（如"C:\test\中文"在日志里显示为C: est中文导致误读）
resolve() 的“规范化”价值常被高估。多数时候你要的只是可靠拼接和格式统一，而不是一次高风险的文件系统穿透。真正难处理的永远是那些没写进文档的系统边界条件——比如挂载延迟、容器内 procfs 不可见、或者某个 NFS 服务器悄悄禁用了 stat()。 
