Python pathlib 相对路径怎么稳定：cwd、__file__ 与测试目录边界

本地运行 Python 脚本时路径正常，换成 pytest、IDE 或定时任务就突然找不到配置文件，最常见的原因是把“进程从哪里启动”和“代码文件放在哪里”当成了同一个位置。pathlib 本身没有变，变化的是 Path.cwd() 的基准。需要跟随项目文件走，就从 __file__ 推导；需要读取调用方传入的工作目录，就明确使用 cwd，不要让两种语义藏在一个裸字符串里。

先把 cwd 和 __file__ 分成两条规则

下面这段代码逻辑看着没问题，实际运行时完全依赖你启动脚本的当前文件夹：

from pathlib import Path

config_path = Path("config/settings.json")
print(config_path.resolve())
print(config_path.exists())

从项目根目录执行时，config/settings.json 能找到；如果在别的目录运行 python /work/app/main.py，相对路径就会落到调用方的目录。Path.cwd() 可以把这个事实打印出来：

from pathlib import Path

print("cwd =", Path.cwd())

反过来，__file__ 是当前 Python 文件的位置。资源属于代码包时，可以这样写：

from pathlib import Path

BASE_DIR = Path(__file__).resolve().parent
config_path = BASE_DIR / "config" / "settings.json"

这里的关键不是某个 API 更“稳定”，而是先决定资源的所有权：属于启动命令的输入，就用 cwd；属于源码包的内置文件，就从 __file__ 推导。

旧写法为什么在 pytest 和 IDE 里暴露问题

测试工具运行时不会每次都从你手动执行命令的文件夹启动。IDE的运行配置、Makefile构建脚本、容器启动入口都可能悄悄改当前工作目录。这种情况下很容易把环境隐含假设硬写到业务逻辑里：

def load_settings():
    return Path("config/settings.json").read_text(encoding="utf-8")

修正方案是把基准文件夹作为可传入参数，连默认值都写清楚对应的语义：

from pathlib import Path

def load_settings(base_dir: Path) -> str:
    path = base_dir / "config" / "settings.json"
    if not path.is_file():
        raise FileNotFoundError(f"settings not found: {path.resolve()}")
    return path.read_text(encoding="utf-8")

生产代码里可以传入包自身的部署目录，命令行工具则优先传入用户指定的项目根目录。报错信息里直接输出完整绝对路径，排查问题的时候根本不用猜当前运行目录到底是哪个。

用 tmp_path 验收测试目录边界

pytest 的 tmp_path 适合验证“文件写到了哪里”，而不是把测试固定在开发机目录。测试先创建资源，再把它作为明确的基准目录传给读取函数：

def test_load_settings(tmp_path):
    config_dir = tmp_path / "config"
    config_dir.mkdir()
    (config_dir / "settings.json").write_text('{"mode": "test"}', encoding="utf-8")

    text = load_settings(tmp_path)

    assert '"mode": "test"' in text

如果函数内部仍然写死 Path("config/settings.json")，这个测试会在错误的 cwd 下失败；如果它依赖传入的 tmp_path，测试就不受 IDE 和命令行位置影响。

路径验收清单：先看解析结果，再看文件状态

调试路径相关问题的时候可以临时加这两行日志：

print("cwd:", Path.cwd())
print("config:", config_path.resolve(), "exists:", config_path.is_file())

返回的信息不会只告诉你「文件不存在」，而是能看到完整的路径拼接过程、目标是不是正常文件、计算路径时用的是哪一个基准目录，排查效率高很多。

常见问题

什么时候应该使用 Path.cwd()

当你定义的路径指向用户敲启动命令时所在的项目目录，或者是命令行明确传入的工作区位置，才可以用它。不要把 cwd 当成源码资源目录的基准路径。

__file__ 在打包后还可靠吗

普通本地开发跑脚本、大部分常规打包部署场景下可以作为源码相对资源的解析起点，但资源最终被打进特殊归档后要按打包工具的资源 API 处理，并用实际部署产物做验证。

为什么测试里不建议依赖真实 config 目录

真实目录会让测试受到机器状态、启动目录和残留文件影响。用 tmp_path 创建最小资源，测试边界更明确。

最后的采用建议

把路径基准写进函数签名或配置对象，代码里少出现裸的 Path("...")。固定资源从 __file__ 推导，用户输入从 cwd 或参数进入，测试用 tmp_path 构造。每次修复路径问题，都同时验收绝对路径和文件状态，这比单纯把当前目录改到“能跑”为止可靠得多。