应用写完数据也执行了NOTIFY，监听端却一直没动静。先看发送端有没有提交，再看接收端是否还停在事务里，这两个边界都能推迟客户端看到通知。
先确认监听注册已提交
连接同一个数据库的两个会话。会话A运行LISTEN app_events;；若它在显式事务中，先提交，监听才生效。监听注册只属于当前会话；重连后要重新执行LISTEN，使用连接池时要确保监听连接不会在会话之间切换。
对照提交和回滚
会话B依次执行BEGIN;、NOTIFY app_events, 'demo';和COMMIT;。提交前不会送达；改成ROLLBACK则不会产生通知。监听端也要结束当前事务才能向客户端交付，客户端还需读取连接上的消息。
检查长事务和通知内容
若会话A长期处在事务内，先缩短读事务并检查客户端消费机制。同一事务、同一频道与同一载荷的重复通知可以合并；默认配置下载荷应小于8000字节。用不含敏感信息的记录键代替完整数据。
区分已经送达与程序尚未消费
监听驱动需要继续读取连接。若用psql手动观察，可在发送方提交后回到监听会话运行SELECT 1;，借下一次交互检查通知输出。应用程序应按驱动方式消费异步消息。
把事件记录和唤醒分开
在萤光云或LightNode的独立数据库用两个会话验证提交、回滚、重连场景。对不能漏处理的任务，将事件与业务变更写入持久表；监听端先提交LISTEN，再读初始状态，随后把通知作为重新查询的信号。断线后应从持久记录补读。
FAQ
未提交就会收到吗？ 发送方提交后才会送达。
回滚会发送通知吗？ 不会。
跨数据库能收到吗？ 不能，范围是同一数据库。
断线期间的通知会补发吗？ 不会按持久队列重放。
能只靠通知传订单内容吗？ 不要这样做，事件记录应可持久查询。
温馨提示
共享数据库中不要在通知里传密码、令牌或个人数据。验收时应覆盖监听连接断开重建以及持久事件补读。
