不能，触发器无法单独拦住并发重复支付，因其运行在事务内无法跨事务感知未提交操作；必须配合UNIQUE约束（如order_id唯一索引）作为第一道防线，触发器仅作辅助校验。
触发器能拦住并发重复支付吗
不能直接靠 BEFORE INSERT 触发器安全拦截。原因很简单：两个并发事务几乎同时插入同一笔订单的支付记录，触发器在各自事务隔离级别下查不到对方未提交的数据（比如默认 READ COMMITTED），于是都通过校验、都插入成功。这不是触发器写得不对，而是它运行在事务内部，无法跨事务感知“正在发生但还没提交”的操作。
真正能起作用的是数据库层面的并发控制机制，触发器只能作为辅助校验层，必须配合唯一约束或显式锁。
唯一约束才是第一道防线
最简单也最可靠的方式，是在支付表上对订单号加唯一索引（或唯一约束），强制数据库在物理层面拒绝重复插入：
ALTER TABLE payment_records ADD CONSTRAINT uk_order_id UNIQUE (order_id);
当两个并发请求尝试插入相同 order_id 时，其中一个会立即报错：ERROR: duplicate key value violates unique constraint "uk_order_id"。应用层捕获这个错误，就能明确知道是重复支付被拒。
- 必须是
UNIQUE约束，不是普通索引——只有约束才能触发插入时的冲突检测 - 如果业务允许“同一订单多笔支付”（如分次付款），那就不能用
order_id单独建唯一约束，得换成(order_id, payment_type)或引入幂等字段payment_id做唯一键 - MySQL 中若用
INSERT IGNORE或ON DUPLICATE KEY UPDATE，需注意它们会吞掉错误，可能掩盖问题
触发器适合做业务逻辑补充校验
如果你需要在插入前检查订单状态（比如“订单已支付”“订单已关闭”），再拒绝插入，可以用 BEFORE INSERT 触发器，但必须搭配 SELECT ... FOR UPDATE 显式加行锁，否则仍有并发漏洞：
CREATE OR REPLACE FUNCTION check_order_status() RETURNS TRIGGER AS $$
BEGIN
PERFORM 1 FROM orders WHERE id = NEW.order_id FOR UPDATE;
IF (SELECT status FROM orders WHERE id = NEW.order_id) != 'unpaid' THEN
RAISE EXCEPTION 'Order % is not in unpaid state', NEW.order_id;
END IF;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER tg_prevent_double_pay
BEFORE INSERT ON payment_records
FOR EACH ROW EXECUTE FUNCTION check_order_status();
关键点：
-
FOR UPDATE是必须的——它让触发器里的SELECT锁住对应订单行，阻塞其他并发事务读取/修改该订单，直到当前事务结束 - 只适用于 PostgreSQL；MySQL 的触发器里不支持
SELECT ... FOR UPDATE，所以这种写法在 MySQL 上不可行 - 锁粒度是订单行级，不会锁整张表，但要注意避免长事务导致锁等待堆积
应用层幂等设计比纯数据库方案更可控 数据库层的防护总有边界：比如用户刷新页面重发请求、前端重复点击、消息队列重复投递……这些场景下，仅靠数据库约束或触发器容易把问题抛给用户（显示“插入失败”而不是“支付已处理”）。
推荐做法是让每次支付请求带一个服务端生成的幂等键（idempotency_key），存在支付表中并设为唯一键：
ALTER TABLE payment_records ADD COLUMN idempotency_key VARCHAR(64) UNIQUE;
应用收到请求后：
- 先按
idempotency_key查询是否已有记录；有则直接返回原结果（含支付状态、流水号等） - 没有则尝试插入，靠唯一约束保证原子性
- 幂等键建议用客户端时间戳+随机数+订单号哈希，确保重试时一致、不同请求时不重
这一步绕不开应用逻辑，数据库只是执行者。漏掉幂等设计，再严密的触发器也防不住“用户以为没付成，点了两次”这种真实场景。
