测试环境全绿，上线四十分钟后接口超时，最后定位到两件事：那张表在测试库里有 3 万行、在生产有 2,400 万行，优化器选了完全不同的执行计划；另一个接口在测试里从没并发过，生产上十条线程同时走同一段逻辑，把唯一索引撞成了死锁。测试环境没有说谎，它只是取样取错了对象。
配置漂移是另一件事，已经有专文。这篇只谈一件更隐蔽的事：数据形状与负载形状。配置可以 diff，形状不能 diff——它没有文件形态，只能靠采样、造数和回放去逼近。验收要回答的也不是"环境一样吗"，而是**"这个环境能查出哪类问题、查不出哪类问题"**。答不出后半句，一致性验收就是一句口号。
1. 验收对象是四种形状，不是配置项
| 形状 | 具体内容 | 测试环境常见状态 | 会掩盖的问题 |
|---|---|---|---|
| 数据量级 | 行数、表数、单行大小、总字节 | 千行到万行 | 执行计划翻转、深分页、批处理超时 |
| 数据分布 | 空值率、枚举占比、热点集中度、极值 | 均匀、干净、无极端值 | 空值分支未测、热点键争用、边界溢出 |
| 索引与统计信息 | 索引集合、统计信息新鲜度、字段基数 | 索引更少、统计信息刚建 | 索引未被选中、缺失索引、基数估算偏差 |
| 并发形态 | 同时在跑多少、读写比例、事务长度 | 单人点几下 | 锁等待、死锁、连接池耗尽、幂等冲突 |
四种形状里，数据量级最容易验证也最常被跳过：它需要磁盘与造数时间，而"我们跑通了"已经能交差。但量级差两个数量级时，数据库的决策会整段改变：
// 同一句 SQL 在两个量级下的典型差异（按 MySQL 8.x 的 EXPLAIN 字段核对）
// 测试库 3 万行、无覆盖索引：type=ALL, rows≈30000, Using filesort
EXPLAIN SELECT * FROM orders WHERE user_id = ? ORDER BY created_at DESC LIMIT 20;
// 生产 2,400 万行同一句：type=range, rows≈12000, Using index condition + filesort
// 语句没变、索引没变，变的是代价模型的输入——"环境查不出"的典型形态
判据一句话：任何依赖数据量的决策（执行计划、批大小、分页、缓存命中率）在量级不足的环境里都未经验证，包括它"跑得很快"这个结论。
2. 三档一致性，成本和覆盖范围差一个量级
| 档位 | 做法 | 能查出 | 成本量级 | 不适用 |
|---|---|---|---|---|
| 形状一致 | 表结构、索引、字段基数区间对齐 | 缺索引、类型不匹配、空值分支 | 低，一次脚本 | 执行计划、并发问题 |
| 分布一致 | 按真实分布造数，保留长尾与空值 | 热点争用、边界值、空值路径 | 中，需抽样与生成器 | 极端量级下的性能 |
| 量级一致 | 行数与总字节逼近生产 | 执行计划翻转、批处理、深分页 | 高，需磁盘与时间 | 生产级并发 |
三档是加法关系：形状一致拦住 schema 类问题；分布一致才谈得上"空值与热点测过了"；量级一致才谈得上"这条 SQL 在生产也这么快"。多数团队停在形状一致，却按量级一致的语气写结论——这是缺陷逃逸最常见的来源。
形状一致可以脚本化，成本最低，也最容易被跳过：
// 形状核对：行数比、索引差集、字段基数三项，全部可与生产对照
psql -Atc "select relname, n_live_tup from pg_stat_user_tables order by 2 desc" > /tmp/env_rows.tsv // 行数分布
comm -23 <(prod_indexes) <(test_indexes) // 生产有、测试无的索引
// 字段基数差一个数量级时，选择率估算必然失真，这一项比行数更该看
造数的关键不是行数，是分布。按行数等比缩小会把长尾一起缩掉，而长尾正是 bug 的住处：
// 分层造数：保留分布形状，只缩小规模（示例为伪代码级写法）
// 错误做法：ORDER BY RAND() LIMIT 30000 —— 长尾被均匀稀释
// 正确做法：按业务分桶抽样，每桶保留至少 N 条，并强制注入极端值
buckets = {"normal": 0.94, "vip": 0.05, "edge_null": 0.005, "edge_max": 0.005}
for name, ratio in buckets.items():
gen(name, rows=max(MIN_PER_BUCKET, int(TARGET_ROWS * ratio)))
inject(kind="null", fields=["paid_at", "channel"], ratio=REAL_NULL_RATE)
inject(kind="max", fields=["amount"], value=COLUMN_MAX) // 单行极值必须存在
采样时可以接受"数据脏"，甚至应该主动制造脏：测试环境太干净，等于把生产里的空值、越界、重复投递全部延后到上线。要做的是可控的脏——每个脏样本有来源、有数量、有开关，能解释它为什么存在，而不是随手从生产拉一份就完事。
生产数据脱敏后进非生产，是另一条路径，代价是脱敏本身会改变分布：
| 脱敏手段 | 对分布的影响 | 会破坏的验证 |
|---|---|---|
| 全字段随机化 | 关联关系丢失，基数暴涨 | 关联查询、分组聚合、去重逻辑 |
| 掩码保留格式 | 分布基本不变，但唯一性可能被破坏 | 唯一索引冲突、幂等判定 |
| 哈希替换 | 可复现但长度与顺序改变 | 排序、范围查询、前缀匹配 |
| 部分字段保留 | 分布真实，但泄露风险上升 | 需要访问控制而非技术手段 |
结论：脱敏数据适合验证逻辑正确性，不适合验证性能与选择率。把脱敏数据当性能基线，等于用一个被改过的分布去预测真实代价。
3. 影子流量与回放：能证明什么，不能证明什么
影子流量（把生产请求复制一份打到新版本，不返回给用户）是量级与并发形状最接近真实的验证手段，但它有明确的能力边界：
| 手段 | 接近真实的部分 | 不覆盖 | 主要成本 |
|---|---|---|---|
| 影子流量 | 请求分布、并发形态、真实参数 | 写路径副作用、下游配额 | 双份资源与下游压力 |
| 请求回放 | 可复现的序列、可对比的输出 | 时变状态、外部依赖变化 | 录制存储与清洗 |
| 压测造流 | 可指定的并发与峰值 | 真实分布（除非按真实比例生成） | 造流脚本维护 |
回放的局限最容易被忽略：它重放的是请求，不是当时的世界。缓存已经预热、库存已经变了、下游限流阈值已经调过，回放一致不代表行为一致。所以回放的价值主要在"同一批输入下的输出可比对"，而不是"生产等价"。
"我们没有环境"这句话背后的真问题通常是成本，不是技术：量级一致需要磁盘和一台能承载它的机器，影子流量需要双份资源与下游许可。把这句话翻译成可决策的表述，验收才可能被批准：
// 环境形状清单：把"像不像生产"写成可核对的字段，而不是感觉
env: staging
shape:
tables: {orders: {rows: 2.4e7, bytes: 18GB}, users: {rows: 3.1e6}}
indexes: {orders: [idx_user_created, idx_status_created]} // 与生产同名同列
stats: {last_analyze: 2026-11-01, sampled_pages: 20} // 统计信息新鲜度
load:
peak_qps: 320 // 与生产同量级（按最近一次大促口径核对）
read_write_ratio: 9:1
concurrent_tx: 40
gaps:
- 未覆盖：跨机房延迟（staging 单机房）
- 未覆盖：生产热点键集中度（造数按分桶近似）
gaps 这一段是整份清单里唯一不能省的：它把"这个环境查不出什么"显式写下来，验收结论才有边界。
4. 验收结论要写成"查不出什么"，并配四个度量
结论句式的差别，决定了它有没有用：
无效结论：测试环境与生产一致，功能验证通过。
有效结论：在量级与分布上逼近生产（行数比 1:0.8），已验证执行计划、批处理、
深分页；未覆盖跨机房延迟与热点键集中度，因此查不出：跨机房超时、
热点行锁等待。
后者可以直接被引用，也可以被下一个人推翻——它给了推翻的入口。
| 指标 | 口径 | 异常信号 |
|---|---|---|
| 形状偏差 | 关键表行数比、索引差集、字段基数偏差 | 行数比低于 1:10 仍宣称一致 |
| 被环境掩盖的缺陷数 | 上线后归因为"环境差异"的缺陷条数 | 与验收档位无关地持续存在 |
| 造数覆盖率 | 已注入的分布桶 / 业务实际需要的桶 | 只有 normal 一桶 |
| 回放一致率 | 回放输出与录制输出的差异比例 | 一致率极高但线上仍出问题，说明回放没覆盖写路径 |
被环境掩盖的缺陷数是唯一能反向验证验收质量的指标：它不需要在验收时计算，只需要在每次上线后归因时打一个标签。
5. 排错：五种"环境骗了你"的现场
| 现象 | 真实原因 | 处理方向 |
|---|---|---|
| 测试秒回，生产超时 | 量级不足，执行计划不同 | 补量级或对该 SQL 单独做代价核对 |
| 并发下才出现的死锁 | 测试里没有并发形态 | 影子流量或按真实并发压测 |
| 空值分支从未被执行 | 造数太干净，空值率为零 | 主动注入空值与越界值 |
| 脱敏后性能差异巨大 | 脱敏改变了选择率与基数 | 性能验证改用形状一致的非脱敏子集 |
| 回放全绿但上线出错 | 只回放了读路径，写路径未覆盖 | 回放覆盖写路径或用影子库承接写入 |
6. 边界：什么时候形状验收可以降为一次抽查
| 情形 | 处理 | 理由 |
|---|---|---|
| 无状态服务、纯计算 | 逻辑单测 + 一次抽查 | 结果与数据规模无关 |
| 逻辑只依赖单行数据 | 形状一致即可 | 无跨行聚合与排序 |
| 上线影响面极小（内部工具、低频） | 抽查 + 回滚预案 | 验收成本高于风险 |
| 只改文案与样式 | 不做形状验收 | 与数据形状无关 |
| 已有灰度可承接真实流量 | 用灰度替代环境验收 | 真实形状比模拟可信 |
一句话收口：一致性验收的产物不是"环境一样"的证明，而是"哪些问题这个环境查不出来"的清单。写不出这份清单，说明验收只做到了结构一致，却按量级一致的语气结了案。
自测
- 为什么"测试环境与生产配置一致"不能推出"测试能代表生产"？
- 四种形状里，哪一种最容易验证、也最常被跳过，跳过的代价是什么？
- 按行数等比缩小造数，会首先丢掉什么，为什么它是问题的住处？
- 脱敏数据能验证什么、不能验证什么？
- 回放一致但上线出错，最可能漏掉哪类路径？
- 一致性验收的结论句里，哪一段不能被省略？