别人说"我的技术解读是准确的"，你只能选择信或不信。 所以我们把每一处判断拆成你可以自己跑一遍的动作 —— 按你愿意花的时间，从 30 秒到 15 分钟。
这份文档不解释作品，它只做一件事：把验证的权力交给你。 最后还写清了这套方法核验不了什么 —— 补掉一个短板，不等于没有短板。
打开 核验实录 → ，随便点一个数字，会弹出取证卡：
官方原文（不是我们的转述）· 适用版本（哪条规则从哪个版本起生效）· 官方文档链接（可直接点开对照）。
如果任何一个数字点不开、或点开后找不到对应原文 —— 那就是我们的问题，请直接说。
# 在本作品根目录下，逐条执行 node dev/check-all.js node dev/guard-selfcheck.js node dev/frames-selfcheck.js node dev/verify-check.js node dev/spec-check.js node dev/test-logic.js node dev/test-logic-03.js node dev/test-cockpit.js node dev/field-notes-check.js node dev/pathology-check.js node dev/live-check.js python dev/browser-check.py # 需要 Python；用真实 Chrome 复跑
全部退出码为 0 才算通过。每一项在替你质疑什么：
| 脚本 | 项数 | 它在替你质疑什么 |
|---|---|---|
| check-all.js | 28 个文件 | JS 语法 / 重复 ID / DOM 引用悬空 / 内部链接 / 内容守卫 / 数字漂移 / 广告法合规 / 引用完整性 |
| guard-selfcheck.js | 22 | 守卫本身会不会失灵？既要不漏报，也不能把页面里 CSS 布局的百分比数值误判成宣传语 |
| frames-selfcheck.js | 540 帧 | 视频每一帧都渲染得出来吗？有没有 NaN / undefined？ |
| verify-check.js | 30 | 页面声明的数字 = 脚本实际算出的数字（连"我声明了多少项断言"也被脚本核对，且要跟另外四个脚本的真实执行数对上） |
| field-notes-check.js | 91 | 实测笔记页上的每个实测值，能不能在原始采集日志里逐字找到（含反向断言：那一页不得出现任何性能数字） |
| pathology-check.js | 62 | 病理页上的 46 条关键读数，能不能在原始采集日志里逐字找到（含等级纪律：实测 / 实验设置 / 推导 / 官方未列明四档不许混写；以及反向断言：那一页不得出现任何性能数字） |
| spec-check.js | 69 键 | 取证卡的锚点有没有指向不存在的编号 |
| test-logic.js / -03.js | 25 / 56 | 状态机每一步是否真的按官方流程走 |
| test-cockpit.js | 34 | 驾驶舱四个视角渲染，且分项之和 = 汇总值 |
| browser-check.py | 162 | 用真实 Chrome 打开十八个页面，确认不白屏、关键内容渲染 |
| live-check.js | 18 项 | 现场直连页的反向断言：这一页是「仪器」不是「证据」—— 它不得写死任何实测值，连一个日期都不行；另守「服务器释放后仍可操作」：离线快照须与原始输出逐字对账 |
为什么把 guard-selfcheck 单列出来：守卫的主要风险不是漏报，而是"每次都 0 命中、其实正则写错了"这种假绿。
所以守卫必须被自己测试 —— 22 项用例里，10 项在证明"该拦的拦得住"，12 项在证明"不该拦的没被拦"。
各脚本的条数以 核验实录
的守卫清单为唯一来源，该表由 verify-check.js 与各脚本的实际输出机器比对，不允许手写漂移 ——
包括"守卫自检多少项""浏览器渲染多少项""实测笔记证据链多少项""病理证据链多少项"这四个数字，也是反查脚本输出得来的。
这里有一个反复被咬的地方，值得单独说：同一个数字会被写三遍（正文 / 视频帧 / 表格）， 而三遍的写法各不相同，于是"数字漂移守卫"被逼着补了五次才把这五种写法覆盖全 ——
| 写法 | 藏在哪 | 结果 |
|---|---|---|
| 紧邻的「482 项断言」 | 正文 | 已覆盖 |
| 分开写的「数字 + 单位」 T(…,'482') 与 T(…,'项自动化断言') 之间隔着坐标/字号/颜色 | 视频帧 frames.html | 215 一路躲过守卫，直到全站同步才被人眼发现 |
| 脚本名 + 项数表格行里的裸数字 <td class="num">66</td>，既没有"项"也没有"断言" | 本页 selfcheck.html | 65 同样没被看见 |
| 副产物计数：N 个自查发现的问题／N 处自我纠错／N 条主动删除 | 核验实录页自己 verify.html 第五节的副标题 | 副标题的数字写「3 个」，而它下面明明摆着 4 张 SELF 卡 —— 脚本一直在数卡片，从没看过那句数字；而这个「3」还被抄进了首页、否决权页与视频帧。它不是"总数没同步"，是同一页里两句话互相打脸 |
| 独立计数：N 种形式／N 台演示台 | 首页 chip、录屏脚本 index.html | 形式从四种扩到五种后，首页 chip 仍写着旧的形式数，另有 4 处写着旧的演示台数 —— 共 5 处，全部靠人眼找出。它跟断言数毫无关系，前四种正则天生管不到；而且守卫分不清"引用旧值"与"使用旧值"，所以本页与核验实录在陈述这件事时，一律不写具体数字 |
五种写法合起来才守得住。每一次的症状都一样：改了总数，守卫不响 —— 它不报错，只是不响。 其中第 ④ 类最难看：它不是"总数没同步"，而是同一页里两句话互相打脸。
第六次漏报（2026-09-20）：盲区不在写法，在「文件」。 第二轮实测把实测条数又扩了一条之后，视频帧收尾场景与几份配套文档里的「N 条实测」没跟上 —— 旧规则里没有任何一条守过「实测条数」，几份配套文档也从来不在扫描范围内，两个盲区叠在一起。 补法仍是"真值当场算"：真值 = 实测笔记页里实测卡的数量； 凡在页面、视频帧或指定配套文档里写「N 条实测」的，N 必须等于它。 补上规则后的第一次运行，当场抓出两处旧值（视频帧与交接文档），修复后才重新全绿。
第七次漏报（2026-09-20）：盲区在「引用」 —— 没有任何规则守过「字典本身有多大」。
04 号演示台落地时，口径字典扩进一组新口径，全站的「N 项口径 / N 条取证卡」类引用都要跟着换 ——
但「核验条数」这个数字此前没被任何一类守卫覆盖：它不是断言数、文件数、形式数、演示台数或实测条数，前面六类全都看不见它。
补法仍然是"真值当场算"：真值 = spec.js 字典的键数；
凡写「N 项 / N 条 / N 键 + 核验 / 口径 / 取证卡 / 字典」的，N 必须等于它。
写出规则后的第一次运行，当场在配套文档抓到 9 处旧值（交接文档 6 处 / 开发全记录 3 处），修复后才重新全绿。
与第六次共享同一个教训：没有被守卫覆盖的维度，就是下一次漏报的藏身处 —— 而它的症状从来不是报错，是不响。 命名上再补一条：同一个数字可能在页面里以「项 / 条 / 键」三种称呼出现， 命中的动作名（核验 / 口径 / 取证卡 / 字典）也可能有四种 —— 称呼列不全，就等于没守。
另外如实说明一处差别：广告法守卫有 22 项自检用例，数字漂移守卫没有 —— 它每一次的有效性靠"补上规则后立刻抓出旧值"证明，而不是靠单元测试； 唯一一次主动自测是补完第 ⑤ 类之后（故意写错、确认报错、再改回），也就仅此一次。 这两者不是同一等级的保障，写在这里，免得读者误以为它们一样可靠。
不用看我们的任何页面。打开官方文档，按下面搜，自己比对 —— 每条给出「去哪搜 → 搜什么词 → 你会看到什么 → 如果你看到别的值，说明什么」。
region-split-size256MiB（估算值）；v8.4.0 之前默认值为 96MiBraft-election-timeout-ticks、raft-base-tick-intervalDisconnect、max-store-down-timeDisconnect；超过 max-store-down-time（默认 30 分钟）→ Down，并开始在存活 store 上补足副本Offline → Tombstone 的完整状态机，以及"若不存在满足搬迁条件的目标 Store，该 Store 将一直处于 Offline 状态"—— 这正是"缩容下限保护"演示的官方依据absent、write reorgabsent -> delete only -> write only -> write reorg -> public；且"新建的索引在 public 状态前都不可用"HNSW、VEC_COSINE_DISTANCE| # | 我们没写的东西 | 去哪搜 |
|---|---|---|
| 1 | store 负载打分的具体公式 | TiDB 数据库的调度 |
| 2 | PD 各调度器的逐项默认启用状态 | PD 配置文件描述 |
| 3 | HNSW 的 M / efConstruction / efSearch | 向量搜索索引 |
| 4 | tidb_enable_async_commit / tidb_enable_1pc 的默认值 | TiDB 事务概览 |
| 5 | TiFlash 副本的默认数量 | TiFlash 简介 |
| 6 | Leader 故障到新 Leader 就绪的端到端时长 | TiKV 配置文件描述 |
| 7 | Percolator 的 Lock / Write / Data 列族级布局 | TiDB 乐观事务模型 |
文字是矢量排版的，不是生成模型画的 —— 意味着你改一个字、重跑一次，产物就变。 这一步让你确认：图上每个字符都可控。
python dev/shoot-posters.py # 全部 4 张，1x + 2x python dev/shoot-posters.py poster-01 # 只出某一张
自己验：脚本会回读 PNG 的 IHDR 宽高并与期望值比对（1x = 1080×1440，2x = 2160×2880）。
你可以随手改 posters/poster-01.html 里一个数字，重跑，打开图 —— 改的就是显示的那个，不会多也不会少。
python dev/make-video.py --only 0 60 # 只渲染前 60 帧，快速看版面 python dev/make-video.py # 渲染 540 帧 → 合成 36 秒 mp4 python dev/make-video.py --compose # 只重新合成
自己验：video/frames.html 里帧画面完全由帧号决定
（无 CSS 动画、无随机、无时间源）。所以你可以只重跑某一帧、或把任意一帧单独截出来，画面永远一致 ——
这就是"非录屏"的意思：
| 录屏 | 逐帧渲染（本作品） | |
|---|---|---|
| 画面从哪来 | 屏幕上的实时过程 | 帧号 → 静态函数 |
| 能不能重跑出同一帧 | 不能 | 能，逐像素 |
| 卡顿会不会丢帧 | 会 | 不会（机器慢只是跑得久） |
| 错一个字怎么改 | 重录整条 | 改源码，重出受影响的帧 |
L0–L3 验的都是"页面内部自洽"与"出处是否真实"。但它们有一个共同的盲区： 文档可以错，推导可以与实现不符。 所以 2026-09-19 我们在三台真机上装了一套 v8.5.7 集群，把作品讲的机制逐条跑了一遍 —— 当天做了两轮采集，下表以第二轮为准（与实测笔记页一致）。
原始采集输出全部留在 dev/probe/，未经改写。
这一条路径有两种走法，任选其一：
① 你手上有集群（或愿意起一个）—— 照下面列出的步骤自己在真机上重跑一遍，
和我们采到的行为对比。只要你复现不出来，那就是我们错了。（云端那批为一次性快照、不可复跑，只可对着证据读 —— 见实测笔记 10–14。）
② 你没有集群 —— 直接打开 dev/probe/ 里的日志读原文，
再回头核对 实测笔记 有没有把原文改写漂亮。
改写过的实测值，就是编的。
| # | 实测项 | 原始日志 |
|---|---|---|
| 1 | 三副本真的分布在三台机器上（region 1277 的 PEERS = 1278, 1279, 1280；每 store 副本数 = Region 总数 = 142） | probe/r2-round2.txt |
| 2 | Region 分裂真的发生（总数 74 → 142），且分裂后仍是 3 副本 | probe/r2-round2.txt |
| 3 | 停掉一台 TiKV（.114），Leader 自动迁走（42 → 0；另两台 70 / 72） | probe/r2-round2.txt |
| 4 | 降级期间写入仍然成功（2/3 多数派） | probe/r2-round2.txt |
| 5 | 「恢复后回到均衡」是一个过程（51 / 50 / 41，与停机前一个都没对齐） | probe/r2-round2.txt |
| 6 | 拓扑里写的容量参数真的落到了进程（120GiB / 4GiB / 256MiB，进程自报） | probe/r2-round2.txt |
| 7 | nodelalloc 是从内核回读确认的，不是照抄配置 | probe/verify-mounts.txt |
| 8 | 写写冲突：乐观报错 9007 / 悲观等锁 3.006s / 重试不丢更新 | probe/r2-txn.txt |
实测笔记页上还有一节 「三处工具撒谎」 —— 同一个动作，官方检查工具给出的结论与实机状态三次不一致， 而三次里对的都是实机。那三条比上面这些重跑步骤更值得看，因为它们说明的是观察工具本身也会骗人。
去看实测笔记（含三处工具纠偏）→dev/probe/ 与 dev/cloud-evidence/
（见 实测笔记）。
但它们不能代表生产环境在数据量、并发量、跨机房拓扑下的表现，
而且没有出具任何性能结论 —— 本次没有做压测，写了就是误导。
SELECT … FOR UPDATE 的锁范围（实测 12 / 13）；下线这一块，09-20 补上了缩容下限保护（实测 09），
09-25 扩到 5 TiKV 后把 Offline → Tombstone 完整状态机也走通了（实测 11，两条路）；
最后一条 TSO 分配开销，09-25 也在同一批云集群上用「本底扣除法」三段实验补齐（实测 14）。
病理页「未覆盖清单（P-C）」四条（B1–B4）已全部带 done 兑现标记与日期落款，由 pathology-check.js 核对这组声明本身。
但必须说清楚：TSO 一条兑现的是机制（批合并真的发生、两次时间戳都走 PD），不是性能 ——
这一页与本作品仍然不出任何性能结论，最后一条的边界同样没有含糊过去。
这套东西的可信度，不来自我们说自己多准确，
而来自你可以不同意我们 —— 并且能立刻指出是哪里不对。