requirements.txt 与 .venv 同时存在，不代表环境一致：四个检查点

2026-09-12，我把另一模型生成的一份环境审计贴给助手评估。报告说，backend\.venv 缺少 27 个依赖，aiosqlite 的版本也不一致：requirements.txt 写 0.21.0，环境里是 0.22.1。报告还列出几个不在依赖文件里的包，包括 aiomysql、PyMySQL、requests 和 python-dotenv。

我把这份报告留作排错材料。需要先说清楚：以上都是粘贴报告里的结论。本轮写稿没有访问那个工程，也没有重跑 pip，所以不能据此宣布它现在仍然如此。下面写的是怎么自己复核，避免把一个目录名当成环境一致的证据。

第一件事：确认实际运行的是哪个解释器

.venv 目录存在，不等于启动服务时用的是它。先让 Python 自己报告身份：

python -c "import sys; print(sys.executable); print(sys.prefix); print(sys.base_prefix); print(sys.prefix != sys.base_prefix)"

最后一行是 True，说明当前解释器运行在虚拟环境里；是 False，说明它是基础解释器或没有激活环境。这不是经验判断，Python 官方文档写得很直接：

When a Python interpreter is running from a virtual environment, sys.prefix and sys.exec_prefix point to the directories of the virtual environment, whereas sys.base_prefix and sys.base_exec_prefix point to those of the base Python used to create the environment.

It is sufficient to check sys.prefix != sys.base_prefix to determine if the current interpreter is running from a virtual environment.

在 Windows 上还可以用 where.exe python 看命令解析到哪个路径；PowerShell 里 where 是 Where-Object 的别名，直接写 where python 不会得到预期结果，也可以用 Get-Command python。Linux/macOS 用 which -a python。再执行 python -m pip --version，输出的路径应该落在同一个环境里。如果 IDE 终端、系统终端和服务管理器各自启动，三者很可能不是同一个解释器。

第二件事：读 venv 自己的配置文件

虚拟环境根目录下有一个 pyvenv.cfg。官方文档说明，创建环境时会在目标目录放入这个文件，其中 home 键指向创建该环境的 Python 安装位置：

This creates the target directory (including parent directories as needed) and places a pyvenv.cfg file in it with a home key pointing to the Python installation from which the command was run.

可以直接查看：

cat .venv/pyvenv.cfg        # Git Bash / macOS / Linux
type .venv\pyvenv.cfg       # Windows cmd 或 PowerShell

重点看 home 指向的基础 Python 是否还存在、版本是否符合预期。基础解释器被卸载或升级后，环境可能仍能列出包，却无法正常导入扩展模块。这时先修解释器链路，不要急着重装依赖。

第三件事：比较“声明的依赖”和“已安装的包”

requirements.txt 是声明，pip freeze 是当前环境的快照。两者不是同一种东西。pip 官方文档对 freeze 的边界写得很清楚：

pip freeze reports what is installed; it does not compute a lockfile or a solver result.

先把快照落成文件，再做差异检查：

python -m pip freeze > installed.txt
python -m pip check

pip check 回答的是“已安装包之间的依赖是否满足”，它不回答 requirements.txt 是否完整。把两个文件逐行对比时，也要注意 extras、环境标记、可编辑安装和包名大小写，简单的字符串比较会制造假差异。

历史报告里同时出现“缺失”和“多出”，这比单纯缺包更值得追：多出的 MySQL 驱动和 requests 可能是另一个用途的环境留下的，也可能是有人手动装过。没有确认解释器之前，不能判断是环境坏了，还是服务根本用了另一个环境。

第四件事：把环境指纹写进记录

排错时最怕下次复现不了。至少留下五行：

python --version
python -c "import sys; print(sys.executable)"
python -c "import sys; print(sys.prefix)"
python -m pip freeze > freeze-<date>.txt
python -m pip check

再记操作系统和 CPU 架构。把 freeze 文件与当次提交号放在一起，下一次出现“我这里能跑”时，先比对这些记录，而不是先猜网络或代码。

如果项目要求可重复安装，光有 requirements.txt 不够；它可能只锁直接依赖，传递依赖仍会漂移。可以用约束文件或锁文件补齐，但要先确认团队使用的安装工具支持哪一种，别把 pip freeze 的输出直接当成锁文件。

一张排错顺序表

环境一致性不是“目录存在”或“文件名相同”，而是同一次运行里，解释器、包集合和依赖约束能够对上。先确认跑的是谁，再谈装了什么。

本文由 AI 助手依据本人历史素材起草；历史审计报告为粘贴材料，本轮未访问该工程、未执行 pip；官方文档引用已在文中标注。