requests 已安装却报 partially initialized：检查项目里的 http.py

pip 提示 Requests 已安装，运行脚本却出现 AttributeError: partially initialized module 'requests' has no attribute 'post'。换到另一个目录进入 Python，import requests 又正常时，先检查完整 traceback 中的文件路径。项目里的 http.py、requests.py 等文件可能抢先被导入，随后形成循环导入。

错误中的“most likely due to a circular import”是提示，不足以单独证明同名文件冲突。本文针对 traceback 已出现本地模块、而正常环境能导入的场景；确实存在两个业务模块互相导入时，还需要处理它们的依赖关系。

traceback 为什么会回到自己的 http.py

以普通 python script.py 启动时，脚本目录通常位于模块搜索路径前面。本地 http.py 会遮蔽标准库中的 http 包。Requests 导入 urllib3，urllib3 再导入 HTTP 相关模块时，可能重新进入自己的脚本。

如果这个脚本此时又访问 requests.post，Requests 的初始化尚未完成，就可能出现 partially initialized。import requests as r 只改变当前代码里的变量名，不能改变模块搜索路径或解除循环。

Traceback 中出现项目下的 http.py，尤其是从 urllib3 的导入链返回它，应优先核对这个文件。只有报错字符串，没有这条路径证据时，不要把所有错误都按重命名处理。

先改冲突名称，再重启真正失败的进程

将自己的脚本改为符合用途且不冲突的名称，例如 send_request.py。如果项目其他模块导入过它，也要同步修改对应导入和启动配置。不要修改 Python 标准库或 site-packages 中的 Requests 文件。

还要检查同目录是否留有旧的 http.py、requests.py，以及同名包目录；只另存一份新脚本而保留旧文件，旧文件仍可能被搜索到。

保存修改后重启原来的 Python 进程、IDE 控制台或 Notebook 内核。模块对象会保存在进程的导入缓存中，磁盘改名不会自动清除已经加载的对象。删除所有虚拟环境或重新安装 Requests 通常不能解决项目目录抢先匹配的问题。

若排查残留的编译文件，先确认它确实属于刚重命名的本地模块。不要清空整个解释器或其他项目缓存；普通 __pycache__ 中的缓存并不意味着源文件移走后必定仍会被导入，传统直接位于搜索目录的 .pyc 则需要单独核对。

在原入口中确认加载位置

以下代码是定位示例，应在已处理重名文件后、通过原解释器和原启动入口查看。它只导入模块、输出路径，不发送请求：

import sys
import http
import requests

print(sys.executable)
print(http.__file__)
print(requests.__file__)
print(callable(requests.post))

http.__file__ 应对应所用解释器的标准库包；requests.__file__ 应对应预期安装位置，或项目明确采用的合法开发安装位置。示例不固定磁盘路径，不应为了符合某个输出把文件搬进系统目录。

如果导入仍在路径输出前失败，继续读 traceback 中最先进入的本地冲突模块。若路径正确却仍有循环，则检查业务模块导入顺序；若变成 ModuleNotFoundError，再核对原入口使用的解释器和依赖安装环境。

验收时先确认原启动方式能够完成 Requests 初始化，post 属性存在；然后才执行原有、已授权的业务请求，并单独检查 HTTP 响应。不要为了验证导入就向生产接口重复提交可能产生副作用的数据。重命名影响其他导入时，可以恢复原文件和启动配置，再采用经过核对的新名称统一调整。