SQLAlchemyasync中「报错但成功」的根源，对象过期与隐式IO的陷阱

上周三下午，一则典型又棘手的线上告警引发排查：前端页面顶部弹出红色「服务器内部错误」提示，但用户刚提交的入库单列表清晰可见，数量准确无误。同事补充一句：「点了没反应，但数据进去了。」这种「报错但成功」的现象在分布式系统中并不罕见，通常指向网络重试或前端重复提交。然而本次调用链路确认仅执行一次，后端返回明确的 HTTP 500 状态码，排除了上述常见诱因。

日志中反复出现的关键堆栈信息为：MissingGreenlet: greenlet_spawn has not been called; can't call await_only() here，异常位置指向一个从未被显式读取的字段——updated_at。这揭示了一个更隐蔽的问题：并非事务未提交导致数据丢失，而是提交后对象状态管理引发的后续访问异常。

仓储层实现仅调用 flush()，未显式 commit()。表面看确实存在提交遗漏风险。但核查数据库确认新数据已持久化，说明上层某处确有 commit() 调用——问题本质不是数据丢失，而是提交后对象状态变更引发的访问冲突。

进一步分析指向 SQLAlchemy 的默认行为：事务提交后，会话默认将所有实例属性标记为「过期」（expire_on_commit=True）。所谓过期，并非数据失效，而是表示「该值可能已被其他事务修改，下次访问时需重新查询」。在同步驱动下，这一机制完全透明：当访问如 obj.updated_at 时，SQLAlchemy 自动发起一条 SELECT 查询并返回最新值；但在异步环境中，属性访问本身是同步操作，无法插入 await 关键字，导致隐式 IO 请求在 greenlet 上下文外触发，从而抛出 MissingGreenlet 异常。

因此，堆栈中指向的 updated_at 并非因代码显式读取而报错，而是因对象过期后首次访问该字段时触发了隐式查询。

问题的临时解法看似简单：关闭自动过期机制——session_factory = async_sessionmaker(engine, expire_on_commit=False)。修改后测试通过，系统稳定运行一周。然而第二模块复现相同错误，此次异常发生在访问关系属性 order.items 时。

关键认知在此更新：expire_on_commit 仅控制标量字段（如字符串、时间戳），不作用于关系属性（relationship）。默认 lazy 加载策略为 select，首次访问关系属性即触发隐式 SELECT 查询，同样因缺乏 await 上下文而失败。这意味着，即使关闭过期机制，关系属性仍会因懒加载引发相同异常。

此外，网上流传的另一说法——「设了 expire_on_commit=False 也无效，因 server_default 列从未加载」——经验证并非绝对错误，而是依赖数据库能力。在 PostgreSQL 中，因其支持 INSERT RETURNING，带 server_default 的列会在 flush() 阶段一并返回值，对象属性即时填充，不存在「未加载」状态；而在不支持 RETURNING 的数据库（如 SQLite 或部分 MySQL 配置）中，该列确实不会在 flush 时回填，后续访问即触发隐式查询，进而报错。这解释了为何同一段代码在不同项目中表现不一：差异源于底层数据库方言支持能力。

要快速定位自身场景属于哪一类，可借助 SQLAlchemy 的 inspect 工具：

若 unloaded 中包含关系名（如 'items'），则问题根源在于关系属性的懒加载，而非标量字段过期；若仅含标量字段名，则属 expire_on_commit 影响范围。

针对不同成因，解决方案亦有区分：

标量字段过期问题：可全局禁用 expire_on_commit=False，或在关键对象上手动调用 await session.refresh(obj) 主动刷新；

关系属性懒加载问题：应显式预加载关系，例如使用 selectinload 或 joinedload，避免运行时触发隐式查询；

server_default 字段未回填问题：优先选用支持 RETURNING 的数据库（如 PostgreSQL），或在模型定义中显式设置 eager_defaults=False 并配合 refresh 行为。

值得注意的是，SQLAlchemy 2.0 对异步会话的语义做了更严格的隔离设计，其核心理念是「异步上下文必须显式控制 IO」。任何隐式数据库交互（包括属性访问触发的查询）在 greenlet 外均被禁止，这是对异步编程模型的正交强化，但也提高了开发者对对象生命周期的认知门槛。

在微服务架构普及、异步框架（如 FastAPI、Starlette）广泛使用的当下，此类问题愈发常见。它并非库的缺陷，而是同步思维向异步范式迁移过程中必然遭遇的「语义鸿沟」。开发者需意识到：异步 ORM 不仅是加个 async/await，更要求对对象状态、加载时机与事务边界有更精细的掌控。

实践中，推荐在项目初始化阶段统一配置会话工厂，并辅以单元测试覆盖典型路径——尤其是涉及关系属性访问与事务提交后的对象使用场景。同时，将 inspect(obj).unloaded 作为调试常规手段，可快速区分问题类型，避免陷入「改了配置却仍报错」的循环。

最终，这次「报错但成功」的故障，暴露的不是数据一致性问题，而是异步环境下对象状态管理的隐性成本。当数据库写入完成、HTTP 响应尚未发出时，对象仍处于「半活跃」状态，其后续访问必须严格置于异步上下文中——这是 SQLAlchemy async 模式不可绕过的契约。