在项目目录运行脚本一切正常，交给定时任务后却报 FileNotFoundError。把配置文件再复制一份，错误消失了，程序却读到了旧配置。这两种现象往往来自同一个问题：程序把启动时的工作目录当成了配置文件所在目录。

本文用一个普通 Python 脚本演示取证、修复和回归测试。示例只读取本地文件，不依赖网络，不要求安装第三方库。适用于以源码文件部署的命令行工具；打包资源、容器挂载和权限策略需要另外验证。

一、先明确三个不同的位置

假设部署结构如下：

project/
├── appconfig.py
├── test_appconfig.py
└── config/
    └── settings.json

这里有三个位置：Python 解释器的位置、appconfig.py 的位置、进程的工作目录。用绝对路径指定解释器和脚本，并不会自动把工作目录切换到脚本目录。

故障代码通常只有一行：

from pathlib import Path

text = Path("config/settings.json").read_text(encoding="utf-8")

在 project 内启动时，它读取的是 project/config/settings.json；从别处启动时，同一个相对路径会指向另一处文件。相对的 Path 对象也不会在创建时自动记住脚本目录。Python 对当前目录和路径解析的定义见 pathlib 官方文档。

更危险的是目标位置恰好存在同名配置。此时不一定报错，而是静默读错环境。因此不能只用“启动不报异常”作为验收条件。

二、排查时记录路径，不打印配置内容

在发生读取操作的地方，临时记录以下信息：

import json
from pathlib import Path

candidate = Path("config/settings.json")
print(json.dumps({
    "message": "检查配置定位",
    "cwd": str(Path.cwd()),
    "script_file": str(Path(__file__).resolve()),
    "config_file": str(candidate.resolve()),
}, ensure_ascii=False))

这段代码应放进有真实文件的脚本里运行，不能直接粘贴到不提供 __file__ 的交互环境。路径本身如果包含内部目录或用户信息，也应按日志规范脱敏；不要输出配置正文、口令或令牌。

对比手动与定时启动的三个字段：

  1. script_file 相同而 cwd 不同，说明启动环境发生了变化。
  2. config_file 随 cwd 改变，说明相对路径缺少明确基准。
  3. config_file 正确但读取仍失败，再排查权限、挂载、编码和文件内容。

修改定时任务的工作目录可以应急，但应用中仍需明确配置定位规则。否则更换启动方式时问题会再次出现。

三、修复方案：默认路径跟脚本，显式路径跟调用者

本文采用以下约定：

  • 没传 --config：读取脚本真实目录下的 config/settings.json。
  • 传绝对路径：直接使用该路径。
  • 传相对路径：相对调用者启动时的工作目录解释。
  • 显式指定的文件有问题：立即失败，不回退默认文件。

最后一条很关键。显式生产配置缺失时悄悄使用默认配置，可能把路径错误变成更难发现的业务错误。

将下面内容保存为 appconfig.py，使用 UTF-8 无 BOM 编码：

"""明确默认配置和显式配置的路径基准。"""

import argparse
import json
import sys
from pathlib import Path


def resolve_config_path(
    raw_path: str | None, *, script_file: Path, start_dir: Path
) -> Path:
    """默认配置跟随脚本，显式相对路径跟随调用者。"""
    if not script_file.is_absolute() or not start_dir.is_absolute():
        raise ValueError("路径基准必须为绝对路径")
    if raw_path is None:
        return script_file.resolve().parent / "config" / "settings.json"
    if not raw_path.strip():
        raise ValueError("显式配置路径不能为空")
    candidate = Path(raw_path)
    if not candidate.is_absolute():
        candidate = start_dir / candidate
    return candidate.resolve()


def read_config(path: Path) -> dict[str, object]:
    """读取配置对象，不自动创建缺失文件或忽略解析错误。"""
    with path.open(encoding="utf-8") as stream:
        value: object = json.load(stream)
    if not isinstance(value, dict):
        raise ValueError("配置顶层必须为对象")
    return value


def main() -> int:
    """先验证配置，再允许后续业务初始化。"""
    parser = argparse.ArgumentParser(description="检查配置定位与读取")
    parser.add_argument("--config", help="配置文件路径；相对路径以启动目录为准")
    args = parser.parse_args()
    start_dir = Path.cwd()
    try:
        path = resolve_config_path(
            args.config, script_file=Path(__file__).resolve(), start_dir=start_dir
        )
        read_config(path)
    except (OSError, UnicodeError, ValueError) as exc:
        print(json.dumps({
            "message": "配置加载失败，业务未启动",
            "error_type": type(exc).__name__,
        }, ensure_ascii=False), file=sys.stderr)
        return 2
    print(json.dumps({
        "message": "配置加载成功",
        "config_file": str(path),
    }, ensure_ascii=False))
    return 0


if __name__ == "__main__":
    raise SystemExit(main())

script_file 和 start_dir 是可注入的基准，便于单独测试路径规则。入口只捕获文件、解码和配置值相关错误；底层函数保持原异常，命令行边界输出异常类型与失败退出码，不打印可能含敏感内容的原始异常文本。JSON 语法错误属于 ValueError 的子类。

这里仅校验 JSON 顶层是对象。真实应用还应在创建连接、启动线程和写入数据之前校验业务字段的类型、长度及取值；读取成功不代表配置业务上有效。

不要在公共库里用 os.chdir() 修复路径。它改变的是进程工作目录，可能影响同进程其他代码的相对文件访问；其定义见 os.chdir 官方文档。

四、用不同工作目录启动，验证真正的故障边界

只在项目目录执行一次不能证明修复有效。下面的测试会在临时目录复制脚本，并通过子进程分别从应用目录、其他目录启动。测试不修改测试进程的工作目录，也不读取真实业务配置。

保存为同目录的 test_appconfig.py：

"""通过真实子进程验证配置路径与失败退出行为。"""

import json
import os
import shutil
import subprocess
import sys
import tempfile
import unittest
from pathlib import Path


class ConfigPathTests(unittest.TestCase):
    """每个用例隔离配置文件和启动目录。"""

    def setUp(self) -> None:
        self.temporary = tempfile.TemporaryDirectory(dir=Path.cwd())
        self.addCleanup(self.temporary.cleanup)
        self.root = Path(self.temporary.name).resolve()
        self.app_dir = self.root / "应用 目录"
        self.other_dir = self.root / "其他目录"
        self.app_dir.mkdir()
        self.other_dir.mkdir()
        self.script = self.app_dir / "appconfig.py"
        shutil.copyfile(Path(__file__).with_name("appconfig.py"), self.script)
        self.default = self.app_dir / "config" / "settings.json"
        self.default.parent.mkdir()
        self.default.write_text('{"source": "default"}', encoding="utf-8")

    def run_app(self, cwd: Path, *args: str) -> subprocess.CompletedProcess[bytes]:
        """对子进程约定 UTF-8 输出，并限制执行时间。"""
        child_env = os.environ.copy()
        child_env["PYTHONIOENCODING"] = "utf-8"
        return subprocess.run(
            [sys.executable, str(self.script), *args],
            cwd=cwd,
            env=child_env,
            capture_output=True,
            timeout=10,
            check=False,
        )

    def assert_success(
        self, result: subprocess.CompletedProcess[bytes], expected: Path
    ) -> None:
        """确认实际选中的文件，避免只验证没有异常。"""
        self.assertEqual(result.returncode, 0, result.stderr.decode("utf-8"))
        payload = json.loads(result.stdout.decode("utf-8"))
        self.assertEqual(Path(payload["config_file"]), expected.resolve())
        self.assertEqual(result.stderr, b"")

    def assert_failure(
        self, result: subprocess.CompletedProcess[bytes], error_type: str
    ) -> None:
        """失败必须有退出码且不输出成功消息。"""
        self.assertEqual(result.returncode, 2)
        self.assertEqual(result.stdout, b"")
        payload = json.loads(result.stderr.decode("utf-8"))
        self.assertEqual(payload["error_type"], error_type)

    def test_default_from_app_dir(self) -> None:
        self.assert_success(self.run_app(self.app_dir), self.default)

    def test_default_from_other_dir_ignores_decoy(self) -> None:
        decoy = self.other_dir / "config" / "settings.json"
        decoy.parent.mkdir()
        decoy.write_text('{"source": "wrong"}', encoding="utf-8")
        self.assert_success(self.run_app(self.other_dir), self.default)

    def test_explicit_relative_path_uses_start_dir(self) -> None:
        custom = self.other_dir / "自定义 配置.json"
        custom.write_text("{}", encoding="utf-8")
        self.assert_success(
            self.run_app(self.other_dir, "--config", custom.name), custom
        )

    def test_explicit_absolute_path(self) -> None:
        self.assert_success(
            self.run_app(self.other_dir, "--config", str(self.default)), self.default
        )

    def test_missing_explicit_file_does_not_fallback(self) -> None:
        self.assert_failure(
            self.run_app(self.other_dir, "--config", "missing.json"),
            "FileNotFoundError",
        )

    def test_invalid_json_does_not_fallback(self) -> None:
        custom = self.other_dir / "broken.json"
        custom.write_text("{", encoding="utf-8")
        self.assert_failure(
            self.run_app(self.other_dir, "--config", custom.name), "JSONDecodeError"
        )

    def test_empty_explicit_path(self) -> None:
        self.assert_failure(
            self.run_app(self.other_dir, "--config", ""), "ValueError"
        )

    def test_invalid_encoding_and_non_object(self) -> None:
        for content, error_type in [(b"\xff", "UnicodeDecodeError"), (b"[]", "ValueError")]:
            with self.subTest(error_type=error_type):
                custom = self.other_dir / "invalid.json"
                custom.write_bytes(content)
                self.assert_failure(
                    self.run_app(self.other_dir, "--config", custom.name), error_type
                )


if __name__ == "__main__":
    unittest.main()

在上述两个文件所在目录执行：

python -m unittest -v test_appconfig.py

check=False 用于测试预期失败的退出码，每个返回值都由断言检查，并非忽略命令错误。输出先按字节接收，再用与子进程约定的 UTF-8 解码。timeout=10 防止错误实现让测试无限挂住；这些参数的语义见 subprocess.run 官方文档。

第二项测试刻意制造了一个合法的同名配置。错误实现即使退出码为 0，也会因为选中了诱饵路径而失败，这比只测试缺失文件更接近生产风险。

本次在 Windows、Python 3.14.6 下运行以上八项测试，全部通过；将默认路径恢复成依赖工作目录的写法后，诱饵路径用例失败。没有执行真实调度器、Linux、符号链接、权限拒绝或打包部署测试。测试是本地文件与子进程验证，不代表生产启动链路已经验证。

五、上线与回滚要检查什么

先确认现有部署是否故意从启动目录提供默认配置。如果是，直接改变默认定位会改变行为，迁移时应先给启动参数加上配置文件绝对路径，再部署新代码。

部署前至少核对：

  1. 正式配置文件是否随部署提供，编码是否为 UTF-8，运行账号是否可读。
  2. 从项目目录和另一个目录启动，默认配置是否一致。
  3. 显式指定错误文件时，是否退出且未启动业务。
  4. 真正的定时任务是否记录了成功退出码及预期配置路径。

若改动后出问题，优先显式传入确认过的绝对路径恢复任务；需要回滚代码时，保留这项参数，避免旧代码再次依赖不稳定的启动目录。不要通过到处复制同名文件来掩盖故障。

还有几个边界需要写进部署约定：resolve() 会解析符号链接，本例默认跟随脚本真实位置；路径解析不是权限校验，也不是防目录穿越的安全沙箱；~ 不会由 Path 自动展开；Windows 的盘符相对路径应避免用于启动参数；Notebook、冻结程序和包内资源不能照搬此处的 __file__ 方案。

总结

这类故障应先确认“程序实际读了哪个文件”。把默认配置与脚本绑定，把显式相对路径与调用者绑定，再用不同工作目录和同名诱饵配置验证，才能同时防住找不到文件与静默读错文件。配置失败就明确退出，通常比悄悄换一份配置更容易定位和恢复。