os.path.join跨平台但不校验路径合法性，易因手动拼接或含分隔符输入引发问题；推荐用pathlib.path替代，注意构造方式与路径解析时机。
os.path.join 在 Windows 和 Linux 上行为一致，但拼接逻辑容易误用
它确实跨平台，但很多人以为 os.path.join 能“自动修复”路径写法，其实它只是按当前系统的分隔符拼接字符串，不校验合法性。比如 os.path.join("a/", "b") 在 Linux 得到 a//b（双斜杠不算错，但可能触发后续 bug）；在 Windows 则是 a/（反斜杠混用，部分库会解析失败）。
- 永远不要手动拼接
"a/" + b或"a\" + b—— 这是跨平台崩塌的起点 - 如果输入参数本身含分隔符（如用户传入
"data/subdir/"），先用os.path.normpath清理再 join - 注意
os.path.join("", "b")返回"b"，但os.path.join("/", "b")在 Linux 是"/b"，在 Windows 可能被解释为绝对路径并忽略前一个盘符
pathlib.Path 是更安全的替代方案，但要注意 Python 版本和构造方式
pathlib.Path 从 Python 3.4 引入，语义清晰、链式调用自然，且默认处理好分隔符和相对/绝对路径逻辑。但它不是“万能胶”：构造时若传入含 Windows 风格反斜杠的字符串（如 r"ac"），在 Linux 上仍会保留反斜杠，导致 exists() 返回 False。
- 优先用正斜杠或原始字符串加正斜杠：
Path("a/b/c")或Path(r"a/b/c")，避免Path(r"ac") - 读取外部路径（如配置文件、命令行参数）后，立刻转成
Path对象，别留着字符串做拼接 - Python 3.6+ 支持
Path.cwd() / "sub" / "file.txt"这种运算符重载，简洁但注意左边必须是Path实例，"." / "sub"会报错
open() 里直接写字符串路径，不会因系统不同而失败，但路径内容可能无效
open() 底层由 OS 提供支持，所以 open("a/b/c.txt") 在 Windows 和 Linux 都能跑通——前提是路径实际存在且权限正确。真正出问题的，往往是路径生成环节：比如用 __file__ 拼配置文件时，没考虑 __file__ 在 pyz 打包或 symlink 场景下返回的是绝对路径还是相对路径。
- 获取当前脚本所在目录，别用
os.path.dirname(__file__) + "/config.json"，改用Path(__file__).parent / "config.json" - 如果路径来自用户输入或环境变量，务必用
Path(path_str).resolve()获取真实绝对路径，再检查.exists()和.is_file() - Windows 下长路径（>260 字符）默认被截断，需在程序开头加
import os; os.environ["PYTHONIOENCODING"] = "utf-8"并确保系统启用长路径支持（Windows 10 1607+）
OSError: [Errno 2] No such file or directory 的真实来源常被误判
这个错误看起来简单，但背后可能是路径大小写（Linux/macOS 敏感）、空格编码（shell 传参未引号包裹）、符号链接断裂、甚至 NFS 挂载延迟未就绪。尤其在 CI 环境中，os.getcwd() 可能是临时构建目录，而代码却硬编码了相对于项目根的路径。
立即学习“Python免费学习笔记（深入）”；
- 打印出完整路径再调试：
print("Trying:", str(Path("data/input.csv").resolve()))，别只 print 原始字符串 - 检查父目录是否存在：
Path("data/input.csv").parent.exists()，比直接exists()更早暴露问题 - 在 Docker 或 GitHub Actions 中，挂载路径和容器内工作目录不一致很常见，用
Path.cwd()打印出来确认，别假设它等于项目根
最麻烦的从来不是分隔符本身，而是路径对象在流转过程中被反复转成字符串又拼接——一旦中间某步用了 str(path) 再加 +，就等于主动退出了 pathlib 的安全区。
