Python 导入 json 却没有 dumps：用模块来源与 -P 排查同名遮蔽

明明 import json，下一行却报“模块没有 dumps”；换机器正常，放进项目目录就失败。先别急着重装 Python：可能导入了你自己的 json.py。本文用来源探针和隔离实验，区分同名遮蔽、模块缓存与路径配置，再说明 -P、-I 能解决什么，不能解决什么。

一、报错对象可能根本不是标准库

import 按模块名查找，不按“你心里想要的包”查找。对于尚未缓存、通过路径查找的 json，脚本目录里的同名文件可能先于标准库被找到。于是 import 成功，调用 dumps 才失败；文件内反过来导入 json，还可能出现 partially initialized module，让人误以为只是循环依赖。

logging.py、email.py 或同名包目录也可能冲突。但内置、冻结模块和自定义导入器另有机制；本文只研究普通路径查找中的 json，不泛化为全部导入规则。

二、先读来源，再决定是否装包

把下面保存为 probe.py，放在故障入口附近，用实际运行服务的解释器启动。它不依赖第三方包；候选来源、实际来源与 sys.executable 分别确认模块和环境。

import sys, importlib.util
print("解释器:", sys.executable)
print("搜索路径:", sys.path)
规格 = importlib.util.find_spec("json")
print("候选来源:", getattr(规格, "origin", None))
import json
print("实际来源:", getattr(json, "__file__", None))
print("缓存一致:", sys.modules.get("json") is json)

若实际来源指向项目里的 json.py，先处理同名遮蔽。若指向预期标准库，则继续检查调用对象、赋值覆盖和实际异常。真正的第三方包未找到，才转向解释器与安装环境排查；json 属于标准库，不需要通过 pip 安装。

find_spec 查询点号子模块可能导入父包，缓存也会影响结果。这里只查顶层 json；未知代码优先在受控副本排查，别直接导入生产进程。

三、用临时目录制造一次同名遮蔽

下面脚本需要 Python 3.11+，因为 -P 从该版本提供。它只建立临时 json.py，不改真实项目；默认启动打印“本地同名模块”，加 -P 后打印“标准库”。两次都可能退出 0，因此成功退出不等于导入对象正确。

import os, sys, subprocess
from pathlib import Path
from tempfile import TemporaryDirectory
with TemporaryDirectory() as 目录:
    根 = Path(目录)
    (根 / "json.py").write_text("标记 = '本地同名模块'\n", encoding="utf-8")
    探针 = 根 / "probe.py"
    探针.write_text(
        "import json\nprint(getattr(json, '标记', '标准库'))\n",
        encoding="utf-8",
    )
    环境 = os.environ.copy()
    for 键 in ("PYTHONPATH", "PYTHONHOME", "PYTHONSAFEPATH"):
        环境.pop(键, None)
    for 选项 in ([], ["-P"]):
        结果 = subprocess.run(
            [sys.executable, *选项, str(探针)], cwd=根,
            env=环境, capture_output=True, text=True, check=True,
        )
        print(选项, 结果.stdout.strip())

本文实际使用 CPython 3.14.3 做隔离检查；清除相关路径环境变量后验证默认与 -P 对照，另覆盖显式 PYTHONPATH、-I、脚本旁依赖及重命名恢复。没有修改线上服务，也没有冒称完成所有项目的升级验收。

四、修复首选：重命名，而不是拼路径

确认遮蔽后，把自写 json.py 改成不会碰撞的名称，例如 report_json_helpers.py，同步修改明确引用它的导入，然后在新进程里复测。包目录同名也要处理，别只搜单个文件。

重命名磁盘文件不会自动替换运行进程的 sys.modules。长驻服务、交互会话或测试进程已拿到旧对象时，应按既有发布流程重启相应进程，再读取来源。删除字节码缓存不能替代重命名，也不能替代进程验收；尤其不要为一个 import 问题清空整台机器的缓存。

临时 sys.path.insert(0, ...) 可能换来另一个优先级坑。应明确包布局、安装环境与启动入口；保存旧参数，避免弄丢业务依赖。

五、-P 与 -I：诊断工具，不是万能补丁

默认执行脚本时，Python 会把脚本所在目录放到搜索路径前部；-c 和交互入口会前置代表当前工作目录的空字符串，-m 前置当前工作目录。-P 不添加这类潜在不安全路径，但不禁用 PYTHONPATH，也不清除既有模块缓存。

# Python 3.11+；probe.py 是上一节的来源诊断脚本
python3 -P probe.py
# 更严格的诊断对照，不是无条件的生产启动方案
python3 -I probe.py

-I 是隔离模式，从 Python 3.4 提供；在本文使用的 3.14 中包含 -E、-P、-s 的效果，忽略 PYTHON* 环境变量并排除用户 site-packages。它不是安全沙箱，不会让任意未知代码变安全。

两种选项都可能使仅靠脚本旁目录找到的业务 helper.py 消失。项目尚未安装时，python -P -m 项目入口也可能找不到入口包。对照成功后，要检查依赖是否按约定安装，不能把全部服务启动命令一键加 -I。

六、为什么加了 -P 仍导入错文件

如果 PYTHONPATH 显式包含项目目录，-P 仍会接受这条路径；环境变量中的空路径项也可能引入当前目录。脚本运行时自行修改 sys.path、site 的扩展配置或自定义导入器，同样不由 -P 一次包办。

隔离实验中，让 PYTHONPATH 指向测试目录后，-P 再次导入本地 json.py；同条件下 -I 导入标准库。而单独 -E 只忽略环境变量，默认脚本目录仍能遮蔽。这是三个不同控制面，不能互相替代。现实修复应追踪路径来自启动器、服务环境还是代码，而非盲删全局变量。

七、按症状分流，别一上来重装

八、修复通过，要看到这些结果

• 故障入口实际解释器、启动目录、参数和环境已确认。
• 新进程实际来源符合预期，不只看 import 或退出码。
• 业务依赖仍能导入，代表性功能与失败分支均通过。
• 部署和定时入口结果一致，没有把 -P 或 -I 当安全保证。

参考资料：Python 模块搜索路径；命令行 -P、-I 与环境变量；sys.path、sys.modules 与解释器信息。