pathlib.Path() 能自动适配 Windows 和 macOS/Linux，因为它在实例化时根据操作系统自动选择 WindowsPath 或 PosixPath 子类，路径拼接（如 / 运算符）、标准化、解析等操作均按当前系统语义执行，无需手动判断平台或硬编码分隔符。
pathlib.Path() 为什么能自动适配 Windows 和 macOS/Linux？
因为 pathlib.Path 在实例化时会根据当前运行的操作系统，自动选择对应的子类：WindowsPath 或 PosixPath。你不用判断平台，写一次代码就能跨系统运行。
常见错误是手动拼接路径字符串，比如用 "folder/file.txt" 或 r"C:\data\config.json" —— 这在跨平台时必然出错。而 Path("folder") / "file.txt" 会在 Windows 上生成 folder\file.txt，在 macOS 上生成 folder/file.txt，斜杠/反斜杠完全由底层自动处理。
- 所有路径操作（
/、joinpath()、resolve()、exists()）都基于当前系统语义，无需条件分支 - 构造时传入的字符串可以混用正斜杠（
"a/b/c"），pathlib会自动标准化为当前系统的分隔符 - 如果硬编码
os.sep或os.path.join()，就失去了pathlib的核心价值
如何安全读取配置文件而不被路径大小写或符号链接坑到？
macOS 默认不区分路径大小写，Linux 区分，Windows 文件系统通常也不区分——但 Python 的 pathlib 行为严格遵循底层文件系统规则。这意味着 Path("CONFIG.JSON").exists() 在 Linux 上可能返回 False，即使文件实际叫 config.json。
更隐蔽的问题是符号链接：调用 .resolve() 会跟随链接并返回真实路径，但若目标不存在或权限不足，会抛 FileNotFoundError；而 .absolute() 只做相对路径补全，不检查文件是否存在。
立即学习“Python免费学习笔记（深入）”；
- 读取前先用
path.resolve().exists()确认真实路径存在，避免误判软链断开 - 敏感场景（如加载用户配置）建议用
path.expanduser()处理~，再.resolve()，防止~/config指向空目录 - 不要依赖
str(path)做路径比较，应统一用path.resolve()归一化后再比对
为什么 Path.cwd() 和 Path.home() 有时返回意外路径？
Path.cwd() 返回的是进程当前工作目录，不是脚本所在目录；Path.home() 读取的是 HOME（Unix）或 USERPROFILE（Windows）环境变量——这两者都可能被外部修改或未设置。
典型陷阱：把脚本放在 /opt/app，双击运行（GUI 环境下工作目录可能是 / 或用户桌面），导致 Path("data/db.sqlite") 实际尝试写入根目录，权限失败。
- 获取脚本所在目录请用
Path(__file__).parent，它稳定且与执行方式无关 - 跨平台项目中，配置文件优先放
Path(__file__).parent / "config.yaml"，而非Path.cwd() / "config.yaml" - 若必须用
Path.home()，加一层存在性检查：home = Path.home(); assert home.exists(), "HOME not set"
glob() 和 rglob() 在不同系统上行为一致吗？
基本一致，但要注意通配符语义和隐藏文件处理差异。Linux/macOS 的 * 默认不匹配以 . 开头的文件（如 .env），而 Windows 没有“隐藏文件”概念，glob("*.py") 会照常匹配 .gitignore 以外的所有文件——但 pathlib 本身不控制这个，它依赖底层 glob 模块和 OS 文件系统 API。
更关键的是递归深度：大目录下 rglob("**/*.log") 可能因文件数量过多触发 RecursionError 或性能骤降，这在 NTFS 和 ext4 上表现不同。
- 明确限定层级用
glob("*/logs/*.log")替代rglob()，避免意外遍历深层嵌套 - 过滤隐藏文件需显式写：
[p for p in path.rglob("*") if not p.name.startswith(".")] - 生产环境慎用
**，尤其当路径含网络挂载点（如 SMB/NFS），可能卡死或超时
