PEP 668 拦截运行时装包：SQLAlchemy 隐式刷新死锁复盘

一个用来复现 SQLAlchemy autoflush 死锁的 PoC 脚本，还没碰到数据库就崩溃了。原因不是 ORM 逻辑写错，而是脚本在入口处尝试用 pip install 动态补装缺包，被 Debian 系统的 PEP 668 保护机制直接拒绝。这次失败本身比原定的并发实验更有价值——它同时暴露了依赖管理的边界问题和隐式刷新的锁序陷阱。

失败现场：还没跑起来就退出

脚本的执行路径很清晰：先检查 orjson 是否存在，缺失则调用 sys.executable -m pip install，再导入 pydantic 和 sqlalchemy，最后启动双线程模拟转账死锁。实际运行时，第一轮依赖检查就触发了 externally-managed-environment 错误，subprocess.CalledProcessError 让进程以非零状态退出。

说个细节，报错发生在已经激活的虚拟环境里。按常理，venv 内的 pip 不应受系统级保护约束，但 pip 判断环境归属时依赖 sys.prefix 与 EXT-MARKER 文件的位置。如果 venv 创建不完整、PYTHONPATH 被外部继承，或 site-packages 软链接异常，pip 就可能把根安装识别为「外部管理」，从而拒绝写入。这类边缘条件在开发机上不常见，在容器和沙箱里却很容易复现。

PEP 668 到底在保护什么

PEP 668 引入 externally-managed-environment 标记，允许操作系统通过 EXT-MARKER 文件声明：这个 Python 环境由系统包管理器（如 apt）负责，pip 不得随意改写。它的目标是阻止 apt 与 pip 同时往同一个 site-packages 写入，避免升级冲突和不可回滚的依赖污染。

对应用开发者来说，这条规则的含义很直接：Python 解释器所在的文件系统位置，决定了谁能往里装东西。发行版维护的 Python 属于操作系统，属于 apt；项目自己的依赖应放在项目自己的 venv 或容器镜像里。把安装动作塞进运行时，等于让业务代码去碰基础设施的权限边界。

EXT-MARKER 的完整文件名是 EXTERNALLY-MANAGED，是一个放在 Python 环境 stdlib 目录下的纯文本文件（对 CPython 而言即 lib/python3.x/EXTERNALLY-MANAGED），遵循 INI 格式。文件通常含一个 [externally-managed] 段和 Error= 字段，pip 命中该文件时会把 Error 内容作为提示打印出来。Debian/Ubuntu 自 23.04 起默认在系统解释器中放置此文件，Fedora、Arch 等发行版也陆续采纳。需要澄清的是，PEP 668 只是让 pip 在写入前做检测并默认拒绝，它本身不改变文件系统权限，因此 --break-system-packages 或直接调用 setup.py 仍可绕过——保护依赖的是约定与默认行为，而非强制隔离。

反模式：应用内动态依赖解析

原始脚本里的 ensure_dependency 函数是典型的「自愈式」设计——缺什么装什么，看起来让脚本更自包含。但它在多个维度上站不住脚。

• 容器环境必然失败：只读根文件系统、非特权用户、无外网 VPC 都是生产常态，运行时安装没有任何成功空间。
• 状态不确定：多线程或多进程同时触发 bootstrap，可能产生半安装状态，导入行为随之变得随机。
• 权限与审计违规：运行时代码不应持有网络访问和写系统目录的能力，这在合规审计中通常是硬性红线。

依赖供给属于编排层——requirements.txt、pyproject.toml、uv、Poetry、Dockerfile。运行时只负责消费已经就位的环境。缺失依赖时正确做法是立即失败，并给出明确的安装指引，而不是尝试自我修复。

被中断的实验：隐式刷新如何制造死锁

脚本原本要验证的问题本身很有价值。SQLAlchemy 的 sessionmaker 默认 autoflush=True，任何 Query 或 select() 执行前，会话会把待提交的脏数据先刷到数据库，以保证查询结果与内存状态一致。

问题出在锁的获取时机。两个线程分别按相反顺序修改账户：Thread-1 先改账户 1 再查账户 2，Thread-2 先改账户 2 再查账户 1。屏障同步后，两侧几乎同时发出第二条查询，此时 autoflush 触发，把各自早先的 UPDATE 提前落库并持有行锁，随后互相等待对方持有的资源，形成经典的锁序反转死锁。

SessionLocal = sessionmaker(autocommit=False, autoflush=True, bind=engine)

`autoflush` 与 `autocommit` 是两个独立开关，容易混淆。`autocommit`（SQLAlchemy 1.4/2.0 中已由 `autobegin` 语义取代）决定语句是否自动提交事务边界；`autoflush` 只决定在 Query/`select()` 发出前是否先把 Session 的 `dirty`、`new` 对象以 INSERT/UPDATE 形式 flush 到数据库。flush 只是把 SQL 发出去，事务仍处于打开状态，行锁在事务提交或回滚前不会被释放，这正是锁能被另一线程观测并等待的原因。此外，行锁的具体粒度由数据库与隔离级别决定：MySQL InnoDB 在默认 REPEATABLE READ 下对非索引条件可能升级为间隙锁，PostgreSQL 默认 READ COMMITTED 只锁命中行，因此同样的反向加锁顺序在不同后端上的死锁表现和复现概率并不一致。
# acc1.balance -= 100 之后
acc2 = session.query(Account).filter_by(id=secondary_id).first()
# 这行 SELECT 前的隐式 flush 会提前锁定 acc1 所在行

换句话说，隐式刷新把一次本应无害的读查询，变成了提前持锁的写事务。在单线程里这是便利，在并发下就是死锁的催化剂。

给工程实践的三条边界

第一，尊重环境边界。PEP 668 不是障碍，而是对确定性的保护。任何绕过它的 --break-system-packages 都只应出现在一次性调试场景，绝不能进入代码库。

第二，失败要快。依赖缺失是部署问题，不是运行时问题。让进程带着清晰错误退出，比让它带着不确定状态继续跑要安全得多。

第三，隔离验证环境。要测 ORM 的锁竞争和事务隔离，就把依赖预置好，让测量结果反映数据库行为，而不是被环境异常污染。至于 autoflush，在并发写入路径上显式设为 False，或强制统一的加锁顺序，都是比事后排查死锁更便宜的选择。