PostgreSQL返回prepared statement already exists，表示当前数据库会话中已经存在同名预处理语句。它不是全库范围冲突，也不是删表或重启数据库才能处理的问题。
重点是找出谁重复创建了同名语句，以及连接池为何复用了带状态的会话。
先确认冲突属于哪个会话
预处理语句只存在于当前会话。可在复现连接中查询pg_prepared_statements，查看name、statement和prepare_time。其他连接看不到该会话私有状态时，应结合应用连接日志定位。
为什么名称必须在会话内唯一
官方PREPARE文档要求名称在单个会话中唯一，后续EXECUTE和DEALLOCATE都依赖它。应用重复初始化、连接池复用旧连接，或部署后代码版本不一致，都可能再次注册同名语句。
临时恢复应该怎么做
确定旧语句不再使用后，可执行DEALLOCATE 语句名；需要清理当前会话全部SQL级预处理语句时可用DEALLOCATE ALL。清理会话状态前要确认没有并发代码仍依赖旧语句。
连接池场景该怎样修正
检查驱动的server-side prepare阈值、语句命名和连接池模式。会话池会长期保留后端连接状态，事务池则可能限制命名预处理语句的使用方式。不要只靠定时重启连接池，应让初始化逻辑幂等并匹配池化模式。
如何验收修复结果
复用同一连接多次执行准备、调用和释放流程，确认不再重名；再观察连接池扩缩容与应用滚动发布。验收标准是旧连接与新连接都能稳定运行，而不是一次请求成功。
云服务器上的变更建议
测试连接池配置时，可在萤光云或LightNode部署隔离副本；先保留连接池配置与慢查询日志，再调整预处理策略。
FAQ
问：重启PostgreSQL能解决吗？答：会话结束后预处理语句会消失，但重启只能暂时清空状态，重复创建逻辑不改还会再次出现。
温馨提示
温馨提示：不要把来自不同驱动的预处理机制混为一谈。先确认错误由SQL PREPARE还是驱动扩展协议产生，再选择清理方法。
