R259 · 全面自测核查与体系化加固
门禁 80 条实跑（run_id=99，80/80）｜全站 99 个入口遍历｜端到端交付链验证｜安全五项扫描｜120 并发压测 · 生成于 2026-10-20 18:23:00
这一轮不是"再看看有没有问题"，而是把每一个环节真的跑一遍、用真实数据判断。结果：门禁 80/80 全绿、120 并发零 5xx、交付包 12 件真能下载。同时也抓到 6 个门禁此前查不出来的真问题（其中一个让所有 POST 表单直接 500），全部已修并固化为门禁或路由级校验，不是"这次修完下次还犯"。
80门禁条数（全绿）
99入口遍历（全 200）
12交付包件数（实测）
120并发请求（零 5xx）
0孤儿/探针残留
一、本轮抓到并修掉的 6 个真问题
共同特征：门禁此前全绿、页面看着正常，但客户走到具体动作会失败。这也是为什么要"自测"而不是只看门禁数字。
| # | 问题 | 根因 | 修法 | 防复发 |
|---|
| 1 | 所有 POST 表单提交 500 | _read_form() 读 env['wsgi.input']，而自研 handler 塞的键是 wsgi_input（下划线）→ KeyError。评估提交、批量核验全部崩。 | 改为两种键名都兼容，空 body 直接返回空字典。顺带修同函数上方 404 分支的嵌套元组（4 元组写成 3 元组）。 | 端到端实测：POST 评估 → 302 → 报告页 → 下载包 |
| 2 | 交付包缺 4 件（8 件不是 12 件） | R258 把 08–11 接进生成端，但 static/nx_pack/*.zip 是构建时缓存的旧包，路由只判断"文件存在"不判断"件数够不够"。 | /nx/pack/<code> 命中缓存时先数 zip 成员，低于该板块应有件数（碳汇 12，其他 8）就强制重建。 | 新增 G80（AST 级）+ PACK_MIN_BY_SECTOR 双保险 |
| 3 | 一张"无成交的发票"（假账） | dh_invoice 有 ¥9.9 探针发票，订单与台账都已清、发票漏清。根因是历史上十几个临时 e2e 脚本各自手写 DELETE，删的表不一致。 | 新增 deal_hub.purge_order() 统一级联清账（默认 DRY，留痕 purge_log.jsonl）；已按此清掉孤儿，发票与台账恢复一一对应。 | 新增 G79 十环孤儿门禁（五类孤儿必须为 0） |
| 4 | carbon-desk 全量包落后 220 行 | 库内新增数据后未重建交付包（G16 抓到）。 | full_export.py build carbon-desk --force + all carbon-desk --force，重建后 61,056 行与库一致。 | G16 常驻，补采后必须重建 |
| 5 | 两个假数据源未进精确屏蔽集 | carbon_market.db（假行情）与 parked.db（含访问 IP）只在 SKIP_BASE 子串集里，未进 R236_BLOCK_DB 精确集。实测 skus() 未泄漏，但少一层保险。 | 两个库名加入 R236_BLOCK_DB（90→92），双保险。 | 可售清单实测仍 252 个 SKU，未含两者 |
| 6 | 页面上给客户的接口地址是死的（虚警已排除） | 初查发现 /sink/api/parcel 404，怀疑页面写错地址。 | 核实：页面实际写的是完整路径 /nx/sink/api/parcel，实测 200。是我 grep 正则把前缀截掉了，不是缺陷。 | 记录教训：核查必须结构化解析，不能按字节 head 截断 |
两个"虚警"也记下来：① /nx/api/auto/stat 里的 Â 乱码，是我用 head -c 600 按字节截断把 UTF-8 中文字符切断了，用 JSON 解析器验证完全合法；② 同上，接口地址截断也造成了误判。结论：核查工具本身要按字符/结构解析，否则会误报。
二、端到端交付链实测（客户能不能真拿到东西）
不猜、不读代码，直接走一遍客户路径：提交评估 → 生成报告 → 下载 zip → 解开数件。
| 环节 | 结果 | 说明 |
|---|
| POST 评估（碳汇板块） | 302 → 报告页 | 修复前是 500（问题 1）；修复后正常跳转 /nx/report/NX… |
| 评估报告页 | 200 / 13,751 B | 含评分、12 指标、缺失项、19 条标准对照 |
| 下载交付包 | 200 / 27,527 B | /nx/pack/<code>.zip，application/zip |
| 包内件数 | 12 件齐全 | 01–07 + 08 遥感核验 + 09 核证询价 + 10 通道测算 + 11 备案对照 + manifest |
| 清理探针数据 | 0 残留 | 评估记录与 zip 均已删除并备份；nx_assess 回到 0 行 |
12 件逐件字节数（实测）
| 序 | 文件 | 字节 | 内容性质 |
|---|
| 01 | 合规自评报告.html | 15,396 | A4 可打印，含签章栏与边界声明 |
| 02 | 指标台账.csv | 4,189 | 16 列，含基准性质与常见退回原因 |
| 03 | 标准与法规清单.csv | 4,851 | 标准号逐条可溯源 |
| 04 | 佐证材料清单.csv | 3,704 | 按指标拆到"要交什么" |
| 05 | 填报说明.md | 2,264 | 含边界声明章节 |
| 06 | 地块台账.csv | 1,109 | 碳汇专属：地块级基础信息 |
| 07 | 确权要件与监测计划.md | 4,210 | 碳汇专属：确权材料 + 监测方案 |
| 08 | 地块遥感核验报告.html | 6,410 | 真实栅格取数，130 行，含"是什么/不是什么" |
| 09 | 第三方核证询价包.md | 5,645 | 六组材料 + 十问 + 五步验资质 |
| 10 | 交易通道与履约测算.md | 4,242 | 四通道对照 + 开户要件 + 抵销 5% 上限 |
| 11 | 备案要件对照表.csv | 2,899 | 六阶段 × 六类项目 |
| — | manifest.json | 557 | 件数/评分/缺口/口径声明 |
三、全站入口遍历（有没有 500 / 404 / 空页）
| 范围 | 入口数 | 结果 |
|---|
| 成交总台 + 世界引擎页 | 21 | 全 200，页面 4.2–910 KB |
| 产业枢纽 /nx + 碳基座 /cd | 18 | 全 200 |
| 20 板块 × 页面/评估/API 三层 | 60 | 全 200，页面 15–20 KB |
| API 抽查（stat / auto / sink / calc） | 23 | 200，JSON 结构合法 |
| 合计 | 99 | 0 个 5xx、0 个死链 |
并发稳定性
6 个关键页面 × 20 轮 = 120 请求、20 并发：状态码 200 占 120/120，慢请求（>8 秒）0 个，总耗时 29.8 秒（平均 1.5 秒/请求，含公网往返）。
四、安全与真实性扫描（五项）
| 项 | 结果 | 证据 |
|---|
| PII 文件权限 | PASS | 表头命中联系方式的 CSV 共 87 个，全部 600/root；其余 433 个非 PII 文件 644 无害 |
| 数据目录不可公开 | PASS | /static/datastore/ 403；/datastore/ 是交付门户页，不可列目录（0 个 csv 直链）、直取文件 404 |
| 探针/自测残留 | PASS | deal_hub 各表 0 条；nexus 评估 0 行、包 0 个 |
| 假数据源下架 | PASS | 可售清单 252 个 SKU 不含 carbon_market / parked；两者已进精确屏蔽集 |
| 敏感文件公网可达 | PASS | /.env /deal_hub.db /.git/config /pii_guard.py /purge_log.jsonl 全 404 |
端口暴露面：8717（申报）绑 0.0.0.0，其余服务均绑 127.0.0.1。外网实测该端口不可达（云安全组已拦），风险可控；建议后续统一改为内网绑定（纵深防御，本轮未动以免影响申报链路）。
五、门禁演进（78 → 80）
| 门禁 | 管什么 | 为什么加 |
|---|
| G79 | 十环孤儿：发票/台账/合约/已付/报价 | 本轮抓到"发票 2 张、成交 1 笔"。人工发现太晚，必须门禁常驻 |
| G80 | 交付包成员：AST 级确认 08–11 真被赋值 | G78 只查源码里出现过文件名字样，注释写一句"12 件"就能骗过；G80 解析赋值语句，实测 14 个成员 |
最新一次全量：run_id=99，total=80，ok=80，fail=0，warn=0，耗时 154.5 秒。（查询：regress.db 的 rg_run / rg_item，主键是 id 不是 run_id）
六、仍然存在的问题（不粉饰）
成交总台首页 910 KB / 13–17 秒：首页把 1,025 项商品连同完整描述一次性渲染。功能正常、不崩溃，但移动端首屏体验差。修法明确（分页或截断描述 + "查看全部"），但涉及主站渲染逻辑，本轮不动，建议单开一轮做。
申报服务绑 0.0.0.0：靠安全组兜底，建议改 127.0.0.1 + nginx 代理。
业务卡点未变：日均来访 20–50 IP、`dh_ask` 仍 0、IM 无官方 API、RTMP 密钥未交付。这些是市场与外部依赖问题，不是本轮技术核查能解决的。
七、体系化：这次修的是"机制"不是"这一次"
| 机制 | 作用 |
|---|
deal_hub.purge_order() | 清账唯一入口，级联五表 + 留痕；以后自测脚本不许再手写 DELETE |
deal_hub.orphan_report() | 五类孤儿一次说清，门禁与运维共用同一口径 |
_read_form() 双键兼容 | 自研 handler 与 WSGI 都能取到 body，POST 不再 500 |
PACK_MIN_BY_SECTOR | 缓存包件数不足自动重建，旧包不可能再发给客户 |
| G79 / G80 | 把"这次发现的问题"变成"以后每次都会检查" |
一句话结论：平台现在处于"门禁 80 条全绿 + 客户主路径实测可走通 + 安全五项无泄漏 + 120 并发零 5xx"的状态。但要说清：绿不等于有生意——技术上的确定性已经做到，剩下的是流量与成交，那一环不是靠自测能变出来的。