标准答案
- 先确认实例能连接、数据库版本和扩展正确，再核对 pg_is_in_recovery、当前角色、时间线、读写权限和主库地址，避免把副本误当成主库。
- 验证关键表的行数、约束、索引、序列、权限和抽样数据；对订单、支付、库存等业务使用可重复的对账或不变量检查，而不是只执行 SELECT 1。
- 检查 WAL 归档、复制状态和延迟、连接池、锁等待、错误日志、磁盘空间与后台任务，确认恢复后的维护链路没有断裂。
- 在隔离或小流量下执行只读请求和受控写入，验证事务提交、回滚、幂等、消息发布和缓存更新，确认应用与数据库的角色理解一致。
- 恢复后重新建立备份和归档监控，逐步放量并观察错误率、P95/P99、复制、WAL 和业务对账；将未验证的边界明确记录，不能用“端口可连”代替恢复验收。
题目解析
故障恢复可能只恢复了进程，也可能恢复到旧时间点、旧时间线或只读角色。服务启动只能证明 PostgreSQL 能运行，不能证明数据完整、角色正确或应用可以安全写入。
验证需要分层进行：数据库层看角色、时间线、权限和约束，复制层看 WAL 与延迟，应用层看连接池和事务，业务层看关键不变量和外部副作用。任一层未恢复，整体都不能算完成。
受控写入是重要但需要谨慎的一步。应使用明确的 canary 或测试对象，确认提交、回滚、幂等和审计都正常，再逐步恢复真实流量；否则一次验证动作也可能制造重复订单或错误库存。
常见误区
- 误区：端口可连接、SELECT 1 成功就恢复全部流量。改正：先核对角色、时间线、权限、数据对账、复制和归档，再用小流量验证业务闭环。
- 误区：只查数据库日志，不查应用、连接池和复制。改正：恢复验收必须覆盖数据库、复制、应用和业务四层证据。
- 误区：用真实业务写入做无保护的恢复测试。改正：先设计隔离的 canary 和幂等校验，明确回滚与清理路径，避免验证本身污染业务数据。