Linux下FileNotFoundError而Windows正常，根本原因是路径解析逻辑差异：Linux大小写敏感、不自动处理软链接，Windows则容错性强；os.getcwd()返回启动目录而非脚本目录，相对路径易错；应统一用pathlib.Path(__file__).parent.resolve()构造路径。
FileNotFoundError 在 Linux 下出现、Windows 下却正常，根本不是 Python 版本或语法的问题，而是路径解析逻辑和运行时环境的差异被直接暴露了。
Linux 严格按字面匹配路径，大小写敏感，不自动处理软链接跳转，也不容忍拼写容错；Windows 则会帮你“猜”——接受 \ 和 / 混用、忽略大小写、甚至补全空格。同一行代码，在两个系统上走的是完全不同的路径查找路径。
为什么 os.getcwd() 不可靠？
它返回的是你「启动脚本时所在的终端目录」，不是脚本文件所在目录。
比如你在 /home/user 目录下执行：python /home/user/project/main.py
那么 os.getcwd() 就是 /home/user，不是 /home/user/project。
立即学习“Python免费学习笔记（深入）”；
- 相对路径如
"data/config.json"会被拼到/home/user/data/config.json，而不是你期望的/home/user/project/data/config.json - VS Code 在 Windows 上点「运行」默认把 CWD 切到脚本目录，但 Linux 终端不会——这是 IDE 行为差异，不是 Python 问题
- 用
os.chdir()强制切换工作目录容易引发副作用（比如后续open()调用依赖原始 CWD）
为什么直接拼 __file__ 路径会出错？
__file__ 是脚本的路径字符串，但它可能带符号链接、相对路径段（如 ../），也可能没展开成绝对路径。
错误写法：os.path.dirname(__file__) + "/../data/file.txt"
这个字符串拼接在 Linux 下不会自动规范化，.. 不会被解析，最终路径可能是无效的。
-
os.path.dirname(__file__)返回的是原始路径，可能含./或符号链接目标路径，不是你脚本实际所在位置 - 必须配合
os.path.abspath()或pathlib.Path(__file__).parent才能得到真实父目录 - 推荐统一用
pathlib.Path(__file__).parent / "data" / "config.json"，/运算符自动处理分隔符和层级跳转
硬编码 Windows 路径在 Linux 上必然崩溃
像 "C:\Users\me\input.csv" 这种写法复制到 Linux 后：
-
C:驱动器根本不存在 -
\U被解释为 Unicode 转义序列，导致字符串提前截断或解析失败 - 即使改成
"C:/Users/me/input.csv"，Linux 依然找不到C: - 中文、空格、括号（如
"(2024) report.xlsx"）在 shell 参数传递时可能被分割或编码错乱，报的仍是FileNotFoundError，但真实原因是路径被截断
怎么验证路径到底对不对？
别靠“看起来像对”，要用操作系统级命令确认。
- 先查当前工作目录：
import os; print(os.getcwd()) - 再查脚本真实位置：
from pathlib import Path; print(Path(__file__).resolve().parent) - 最后用
Path("your_path").exists()或os.path.exists("your_path")实际检查路径是否存在 - 如果路径含中文或特殊字符，临时改用纯英文命名测试，排除编码/Shell 解析干扰
真正麻烦的从来不是“文件在哪”，而是“Python 认为你该去哪找”。跨平台脚本里，所有路径构造都得基于 <strong>file</strong> 动态生成，且必须 resolve 到真实路径——这点在 Linux 上无法妥协。
