PostgreSQL约束触发顺序由系统按阶段和类型自动决定：语句前检查NOT NULL（早于CHECK），语句中检查UNIQUE/PRIMARY KEY/FOREIGN KEY，语句结束时检查DEFERRABLE约束；同阶段内除NOT NULL优先外无确定顺序，延迟约束仅推迟检查时机，不改变语义；触发器在约束前运行，可用于预处理数据。
PostgreSQL 中约束的触发顺序不是由用户显式指定的，而是由系统根据约束类型、定义方式和执行阶段自动决定的。理解这个顺序的关键，在于区分“约束检查时机”（timing）和“约束检查顺序”（ordering）——前者由 DEFERRABLE 和 INITIALLY 属性控制，后者在同阶段内通常无严格保证（除个别例外）。
约束按执行阶段分层，而非全局排序
PostgreSQL 把约束检查嵌入到 DML 执行的固定生命周期中，大致分为三个阶段：
-
语句开始前：仅检查
NOT NULL和CHECK（如果定义为NOT DEFERRABLE）在行插入/更新时的即时值，但实际发生在“行修改前”，属于最前置校验； -
语句执行过程中：唯一键（
UNIQUE）、主键（PRIMARY KEY）、外键（FOREIGN KEY）的“非延迟”检查默认在此阶段进行，即每行修改后立即验证（例如插入一行就查一次索引是否冲突）； -
语句结束时（或事务提交时）：仅适用于显式声明为
DEFERRABLE且INITIALLY DEFERRED的约束，它们被推迟到COMMIT前统一检查。
同阶段内，多数约束无确定顺序
对于同一语句中多个 NOT DEFERRABLE 约束（如多个 CHECK 或一个 UNIQUE 加一个 FOREIGN KEY），PostgreSQL 不保证它们的检查先后。例如：
CREATE TABLE t (a INT CHECK (a > 0), b INT UNIQUE);
插入 (−1, 1) 时，可能先报 CHECK 错误，也可能先报 UNIQUE 冲突（取决于内部实现细节和索引扫描路径），不应依赖特定顺序。
但有一个明确例外：NOT NULL 总是早于 CHECK 执行。因为 NOT NULL 是存储层硬性要求，而 CHECK 是逻辑层表达式，后者依赖前者已通过的非空值。
延迟约束（DEFERRABLE）可跨语句重排检查时机
延迟约束不改变“类型优先级”，而是把检查从语句级推迟到事务级，从而允许临时违反约束（只要最终满足）。例如：
- 两个互为外键的表，需先插入一方再插入另一方——若外键设为
DEFERRABLE INITIALLY DEFERRED，就能在单个事务中完成两步插入，最后COMMIT时统一校验； - 使用
SET CONSTRAINTS ... DEFERRED可在运行时动态切换，让原本INITIALLY IMMEDIATE的约束临时延迟； - 注意：延迟约束只影响“检查时间点”，不改变约束本身语义；它也不能绕过
NOT NULL或即时唯一性（如序列冲突）等底层限制。
触发器与约束的协作关系
约束本身不触发触发器，但触发器（BEFORE ROW）会在约束检查之前运行。这意味着：
- 你可以在
BEFORE INSERT触发器中修改新行（NEW），从而影响后续约束检查结果（例如自动补全NOT NULL字段）； - 反之，若触发器抛出异常，约束根本不会执行；
- 因此，若需强顺序控制，应优先用触发器预处理数据，再交由约束做终审——这是比依赖约束顺序更可靠的做法。
基本上就这些。PostgreSQL 的约束模型本质是“分阶段 + 类型驱动”，不是靠用户排序，而是靠合理选择 DEFERRABLE、配合触发器、并理解各约束的底层机制来达成预期行为。
