PostgreSQL在并发业务中报could not serialize access，常见SQLSTATE为40001。它表明数据库为避免不一致而中止其中一个事务，不能只重发报错那条SQL。
真正的恢复动作在应用层：回滚后重试整个事务，包括读取数据、计算值以及决定后续SQL的逻辑。
先确认错误码和隔离级别
记录SQLSTATE、事务隔离级别和触发请求，区分40001 serialization_failure与锁等待超时等其他错误。Serializable和Repeatable Read事务都可能遇到需要重新尝试的并发冲突。不要把所有数据库异常都纳入相同的自动重试。
为什么单独重跑UPDATE不够
一个事务先读取余额或库存，再根据读到的值决定写入；冲突时原事务的前提可能已经改变。只重发最后的UPDATE会沿用过期决策。PostgreSQL官方明确要求重试完整事务，包含决定发出哪些SQL及使用哪些值的逻辑。从BEGIN前的业务决策开始重新执行。
应用侧怎样设计重试边界
捕获SQLSTATE 40001后回滚，开启新事务，重新读取所需数据并重新计算，再尝试提交。设置有限次数、退避与日志，避免高冲突下无限循环。数据库不会自动替应用重试，因为它不了解外部副作用与业务决策。
外部副作用要单独处理
发送邮件、扣第三方款项、调用其他API不应在可重复运行的事务体内无保护执行。可使用幂等键或提交后事件机制，保证同一业务请求不会因重试产生重复副作用。事务可重试不等于整个请求的每个动作都可重复。
验收时看什么
用受控并发测试检查发生40001后业务是否重新读取和提交，确认最终状态、重复次数与告警指标。若冲突持续升高，审查热点行、事务时长和索引访问。验收重点是业务结果正确与重试受限，不是仅让错误日志消失。
云服务器上的变更建议
在云服务器上验证配置时，可以先用低流量环境复现。萤光云和LightNode可按实际地区与资源需求选择；变更前先保留快照或备份，比临时更换机器更稳妥。
FAQ
问：SQLSTATE 40001可以无条件一直重试吗？答：应重试完整事务，但需要次数上限和退避；其他错误码还要分别判断。
温馨提示
温馨提示：对账、支付和库存场景应先核对幂等设计，再启用自动重试。
