__file__ 是唯一可靠起点，因它始终指向当前脚本文件路径；直接拼接会因平台差异和打包失效而出错，正确做法是用 pathlib.Path(__file__).parent 获取脚本目录再安全拼接，或通过 sys._MEIPASS 兼容打包环境。

为什么 __file__ 是起点，但直接用它会出错

Python 脚本里写 open("data.txt") 失败，往往不是文件不存在，而是当前工作目录（os.getcwd()）和脚本所在目录不一致。比如你在项目根目录执行 python scripts/main.py，脚本实际在 scripts/ 下，但工作目录是根目录，相对路径就全乱了。

所以得从脚本自身位置出发找路，而 __file__ 就是唯一可靠入口——它始终是当前 .py 文件的路径（可能是相对路径，也可能是绝对路径，取决于你怎么运行它）。

常见错误：直接拼接 __file__ + "/../data.txt"，这在 Windows 下反斜杠处理出问题，路径拼接逻辑也不跨平台。

正确做法是统一转成绝对路径再操作：

• 用 os.path.abspath(__file__) 或 pathlib.Path(__file__).resolve() 拿到脚本的绝对路径
• 再用 os.path.dirname() 或 .parent 提取所在目录
• 最后用 os.path.join() 或 / 拼接目标文件

pathlib.Path 是最推荐的方式（Python 3.4+）

相比 os.path，pathlib 更直观、可读性强，且自动处理平台差异（比如斜杠方向、盘符）。它也是官方明确推荐的现代路径操作方式。

示例：读取与当前脚本同级的 config.json

from pathlib import Path
script_dir = Path(__file__).parent
config_path = script_dir / "config.json"
with open(config_path) as f:
    data = json.load(f)

注意：Path(__file__).parent 稳定返回脚本所在目录；/ 运算符重载后等价于 joinpath()，比字符串拼接安全得多。

如果目标文件在子目录，比如 data/input.csv：

data_path = script_dir / "data" / "input.csv"

不用写双引号嵌套或反复调用 joinpath()，链式自然。

Python 3.14.3

微软官方的 Python 扩展，是 VS Code 安装量最高的扩展（209M+）。集成 IntelliSense（通过 Pylance）、调试（通过 Python Debugger）、代码检查、格式化、重构和单元测试等功能。支持 Jupyter Notebook、虚拟环境管理和多 Python 版本切换。

遇到打包工具（PyInstaller / cx_Freeze）时 __file__ 失效怎么办

打包后，__file__ 指向的是临时解压路径（如 /tmp/_MEIxxx/xxx.py），甚至可能根本不存在（PyInstaller 的 --onefile 模式下，.py 源码根本不落地）。这时靠 __file__ 找资源会失败。

必须改用打包工具提供的运行时路径变量：

• PyInstaller：用 sys._MEIPASS（仅在打包后有效）
• cx_Freeze：用 os.path.dirname(os.path.abspath(sys.executable))

通用写法（兼容开发与打包）：

import sys
from pathlib import Path
def get_resource_path(relative_path):
if getattr(sys, 'frozen', False):
打包后
    base_path = Path(sys._MEIPASS)
else:
    # 开发时
    base_path = Path(__file__).parent
return base_path / relative_path
config_path = get_resource_path("config.json")

关键点：getattr(sys, 'frozen', False) 是判断是否被 PyInstaller 打包的最轻量方式；sys._MEIPASS 是 PyInstaller 解压资源的根目录，不是可执行文件所在目录。
为什么不能依赖 os.getcwd() 或 os.chdir() 来“修正”路径
有人试图在脚本开头 os.chdir(os.path.dirname(__file__))，让工作目录和脚本对齐。这看似简单，但隐患很大：

多线程环境下，os.chdir() 是进程级操作，会影响其他线程
如果脚本被其他模块导入（而非直接运行），__file__ 是被导入模块的路径，chdir 会意外改变主程序的工作目录
某些环境（如 Jupyter、IDE 运行器）会拦截或重定向 chdir，行为不可控

更糟的是，一旦你改了工作目录，后续所有没显式指定路径的 open()、subprocess.run() 都会受牵连——这不是修复，是埋雷。
真正干净的做法，是彻底放弃对工作目录的依赖，所有路径都基于脚本位置或资源根目录构造。这点在写库、CLI 工具或部署脚本时尤其关键。
路径问题的复杂点从来不在“怎么写”，而在“谁在调用、在哪调用、会不会被封装”。盯住 __file__ 和打包态判断，比任何临时 chdir 都可靠。