工具笔记
让 AI 写事务重试：失败后重做读取和判断
序列化失败后，重新执行整个业务事务。
资料核验2026.11.12 · PostgreSQL · 以部署版本文档为准
两个人同时预约最后一个时段。用较强隔离级别处理此类规则时，数据库可能拒绝其中一个事务，让应用重试。只重发最后一条写入，会沿用之前那次读取形成的判断。
给 AI 的上下文与边界
用两个测试连接争抢最后一个预约时段。要求助手把读取、校验、写入放进同一重试单元，只在符合约定的序列化失败时有限重试。提醒邮件与数据库事务的边界不同。
把读取、判断和写入放进重试单元
将一次预约事务封装成完整操作。识别 PostgreSQL 的序列化失败后，带有限次数重试整次事务。每次都重新读当前状态。如果时段已经被占用，就返回业务层的冲突。
邮件、通知等外部副作用安排到提交之后，或通过可靠的任务表处理。否则一次数据库重试可能对外发送两次。
用两个连接演练竞争，核对最终预约数和外部动作次数，别只看两个请求的返回码。
可以直接照着做的演练
两条事务读取最后一个预约位，在屏障后一起写。把每一轮读到的余量、提交结果和错误代码列出来。若有序列化失败，重试必须从重新读取开始。测试通知次数由独立记录核对。
检查生成结果
- 最终最多一条预约。
- 重试会重新读取余量。
- 达到重试上限有可追踪结果。
- 通知不会发送两次。
复查时追问一层
只重复执行最后一条 SQL 会沿用旧判断。让助手给出每轮事务的开始和结束证据。对已提交后的外部动作安排单独处理，失败时用可追踪的业务记录恢复。
让助手把序列化失败与业务冲突分开记录。前者符合重试策略，后者意味着资源已不可用，应返回业务结果。重试间隔可以由应用策略决定，但最终提交之后的外部动作必须能按自己的身份去重。
