触发器不能实现完整状态机，仅能做单次、幂等、轻量的副作用响应（如写日志、校验约束）；状态转移规则必须由应用层或存储过程集中控制，避免循环调用、死锁与逻辑分散。
触发器里不能直接实现完整状态机
SQL触发器不是状态机引擎，它没有内置的状态存储、转移规则定义或事件驱动调度能力。你只能用它做「状态变更的副作用响应」，比如从 pending 变成 approved 后自动更新 updated_at 或插入审计日志。真要靠触发器“驱动流转”，容易陷入循环调用、事务死锁、逻辑分散难以维护的坑。
常见错误现象：UPDATE orders SET status = 'shipped' WHERE id = 123 触发器又去 UPDATE orders SET status = 'delivered'，结果触发自身再次执行，最终报 ERROR: infinite recursion detected in trigger function。
- 触发器适合做「单次、幂等、轻量」的动作，比如写日志、校验约束、填充默认字段
- 状态转移规则（如“只有
paid才能转shipped”）必须在应用层或存储过程里集中控制，不能靠多个触发器拼凑 - PostgreSQL 的
AFTER触发器无法修改当前行数据；MySQL 的BEFORE触发器可以改NEW.status，但仅限本条语句，不解决跨步骤流转
用触发器配合状态表 + 应用层调度更可靠
真正可落地的做法是：把状态机逻辑收口到应用代码或数据库函数中，触发器只承担“通知”和“补全”角色。例如建一张 workflow_events 表记录每次状态变更，再由后台任务轮询该表，按预设规则发起下一步操作。
实操建议：
- 在状态变更的主表上定义
AFTER UPDATE触发器，往workflow_events插入一行，含order_id、from_status、to_status、event_time - 避免在触发器里调用外部 HTTP 接口或复杂计算——超时或异常会导致整个事务回滚
- 给
workflow_events加复合索引：(to_status, event_time)，方便下游任务高效拉取待处理事件 - 若用 PostgreSQL，可用
LISTEN/NOTIFY替代轮询，让触发器执行NOTIFY workflow_event，应用监听后立即响应
MySQL 和 PostgreSQL 触发器对状态流转的关键差异
MySQL 允许在 BEFORE UPDATE 触发器中修改 NEW.status，看似能“自动推进”，但实际非常危险：
- 它只影响当前 SQL 语句所修改的那几行，无法感知业务上下文（比如是否满足发货条件、库存是否充足）
- 如果应用层已经设置了
status = 'shipped'，触发器又改成'delivered'，等于绕过业务校验
PostgreSQL 更严格：AFTER 触发器不能改数据，BEFORE 触发器虽可改 NEW，但无法读取其他行（除非显式 SELECT，可能引发快照不一致）。所以 PG 场景下，触发器基本只能做“记录+通知”，别无选择。
性能影响也得留意：每行更新都触发一次逻辑，若状态变更频繁（如订单每秒更新多次），触发器开销会线性放大，尤其涉及 INSERT 日志或跨表 JOIN 校验时。
真正需要状态自动流转时，优先考虑数据库函数或应用层状态机库
比如 PostgreSQL 中写一个 advance_order_status(order_id INT, next_state TEXT) 函数，里面用 CASE 明确定义所有合法转移路径，并在事务内完成状态更新 + 日志写入 + 消息投递。这样逻辑集中、可测试、可加锁防并发冲突。
应用层则推荐用成熟状态机库（如 Python 的 transitions、Java 的 spring-statemachine），它们支持条件判断、动作钩子、持久化状态、可视化流程图——这些是 SQL 触发器根本没法提供的。
最容易被忽略的一点：状态机的“自动”不等于“无条件”。真实业务里，90% 的流转依赖外部信号（支付回调、物流推送、人工审核点击），而不是数据库某列变了就立刻动。把触发器当成自动化的起点，反而会让系统变得脆弱且不可追溯。
