chore: add launch readiness smoke and tuning evidence

docs/refactor/postgresql-4c16g-tuning.md

@@ -46,6 +46,25 @@
 | `statement_timeout` | `30s` | `30s` | API 请求不应长期占用数据库；导入脚本用会话级覆盖 |
 | `lock_timeout` | `5s` | `5s` | 防止普通请求长时间等锁 |
 
+## 证据采集脚本
+
+仓库已补上线前证据采集脚本：
+
+```bash
+npm run perf:postgres:evidence
+```
+
+脚本会输出 JSON/Markdown 到已忽略的 `docs/refactor/launch-artifacts/`，包含：
+
+- `pg_settings` 中关键调参项、来源和 `pending_restart`。
+- `pg_stat_activity` 连接状态、锁等待和 I/O 等待聚合。
+- `pg_stat_database` 事务、回滚和缓存命中率。
+- `pg_stat_bgwriter` checkpoint 计数和耗时。
+- public schema 大表估算行数、总大小和索引大小。
+- 如已启用 `pg_stat_statements`，输出按总执行耗时排序的 Top SQL。
+
+上云后建议顺序是：先采集一次默认值，应用本文件 shared-host 参数并重启需要重启的项，再采集一次，然后跑 API 阶梯压测。调参证据和压测报告一起进入本地 `production-launch-evidence.json`，不要提交真实证据文件。
+
 ## 应用连接池边界
 
 4 核机器的关键不是把 `max_connections` 拉大，而是控制同时活跃 SQL 的数量。
@@ -173,6 +192,23 @@ limit 20;
 - 没有 OOM、没有频繁连接耗尽、没有长时间 idle in transaction。
 - 慢 SQL 日志能对应到具体接口、worker 或迁移脚本。
 
+## pg_stat_statements
+
+上线压测和灰度期间建议启用 `pg_stat_statements`。如果自托管 Supabase/PostgreSQL 允许修改 `shared_preload_libraries`，推荐：
+
+```sql
+alter system set shared_preload_libraries = 'pg_stat_statements';
+```
+
+该参数需要重启 PostgreSQL。重启后执行：
+
+```sql
+create extension if not exists pg_stat_statements;
+select pg_stat_statements_reset();
+```
+
+每轮压测后看总耗时、平均耗时和调用量最高的 SQL，再决定是否新增索引、改 SQL、加预聚合或调整 API 缓存。不要把慢 SQL 明细直接提交到 Git，因为其中可能包含业务表名、常量和内部路径。
+
 ## 压测闭环
 
 调参后必须跑 API 压测，不要只凭参数表判断容量。当前仓库提供本地压测脚本：