SQLAlchemy 1.4为何将add操作置于try/except却不执行flush？

一、session.add()本身不会触发数据库交互（除非手动/自动flush） #

你观察到的情况完全正确——默认情况下session.add()只是将对象加入Session的本地缓存，不会立刻和数据库建立通信，因此不会抛出数据库相关的异常（比如字段约束违反、主键冲突这类问题）。只有当Session触发flush操作时，才会把缓存中的变更同步到数据库，这时候才可能抛出异常。

二、autoflush的作用边界 #

你查阅资料得到的结论准确：autoflush仅在执行查询操作时自动触发flush，比如调用session.query()、session.get()这类方法时，SQLAlchemy会先同步当前Session缓存的变更到数据库，确保查询能获取最新数据。单纯调用session.add()时，即便开启autoflush也不会触发flush，所以依然不会立刻抛出异常。

三、为什么有些示例把session.add()放进try块？ #

这种写法主要出于两种场景：

• 极少数情况下，add()可能抛出ORM层面的异常，比如对象状态非法（如已被标记为删除的对象再次被add）、或是自定义的验证逻辑在add阶段触发（比如用before_insert事件钩子做前置校验）。
• 部分示例为了代码结构统一，把所有Session操作都包裹在try块中，不管是否真的会抛出异常。

但绝大多数常规场景下，session.add()确实不需要放进try块，真正需要捕获数据库异常的是session.commit()——因为commit会自动触发flush（如果之前未触发过），所有数据库层面的错误都会在这个阶段暴露。

四、是否遗漏了配置？ #

没有遗漏核心配置。如果想要让add()阶段就触发异常，你可以手动在add()之后调用session.flush()，并将flush放进try块，但这并非必需操作，除非你需要在提交前提前校验数据。

内容的提问来源于stack exchange，提问作者Steffen