分两类：① 客户走到具体动作会失败（买了打不开、点了 404、页面 500）；② 打得开但要等（15~35 秒，客户早关了）。第二类此前从来没进过门禁，所以一直是"看着正常"。
| 问题 | 现象 | 根因 | 修法 / 验证 |
|---|---|---|---|
| /deal-desk/free/eu-tender 挂死 | 点开免费试读页 30 秒无响应，直连 8629 也一样（不是网络问题） | eu_tenders.db 已达 2.05 GB / 269,222 行，但 tender 表没有 pub_date 索引；页面 `ORDER BY pub_date DESC LIMIT 12` → 全表扫 + 临时 B 树排序 = 34.5s | 建 ix_tender_pub(pub_date DESC)（21.4s 建完）→ 查询 0.003s，页面 30s 超时 → 0.043s |
| /world/gr 增长中枢 18.4s | 3KB 的小页面要等 18 秒；重启后第一个访客最惨 | 页面渲染时调 advise() 现场跑本地 1.5B 模型，实测 15.2s；结果只存在进程内存里，重启/过期即归零 | 建议结果落盘 static/datastore/growth_advice.json（600 权限），页面只读快照；cron R260-GRWARM 每 30 分钟后台刷新 → 0.16s（重启后首次 0.71s） |
| /world/match 撮合中心 1.19s | 页面能开，但每次都重算全表聚合；机器人多刷几遍就占满线程 | wm_stats 0.74s + facet_lanes 0.31s，全部是对 wm_pair 197,574 行 / 212MB 的 COUNT/SUM 全表聚合；而这些数一天只变一次 | 加 15 分钟 TTL 缓存（60s→900s）→ 0.128s；/world/api/match/stats 0.56s→0.013s，逐项数值完全一致 |
| LLM 预热反过来抢 CPU | 修完上面两处后，爬虫仍测到 /world/match 22.5s | 不是代码问题：warm 用 1.5B 模型跑 16s，在这台 2 核 / 3.7GB / 无 GPU 的机器上把 CPU 吃满，同期所有 web 请求被拖慢 10~100 倍 | cron 改 nice -n 19 ionice -c3 + 间隔 15→30 分钟；6 并发实测 0.48s |
| 54 个端口绑 0.0.0.0 | 内部服务全部对外可达，等于把内网摊在公网上 | 上轮只查了自己过滤的 10 个端口，实际有 54 个 | 51 个文件改绑定 + 50 个服务重启复验 → 最终只剩 22/80/443/111（固化为 G81） |
| 防火墙重启即失效 | 机器重启后所有 iptables 规则消失，加固等于没做 | /etc/iptables/rules.v4 在，但 netfilter-persistent 没装、rc.local 只跑腾讯云脚本 | 新建 ilume-fw-restore.service（Before=network-pre.target）并 enable；补 8716/8717 两个漏网端口（固化为 G83） |
| 直播页 12 个购买链接全 404 | 直播页面上的商品卡点进去全是 404，等于把成交口堵死 | nginx 把 /buy/ 映射到静态目录，而 /buy/<sku> 是服务端路由（服务端本来就 200） | try_files 兜底改成命名 location 反代 8629 → 12 个链接全 200（固化为 G82） |
| /deal-desk/gleif 整页 500 | 国别总览页打开就是服务器错误 | 派生表 gt_cc / gt_link 被清空，页面查不到数据直接抛异常 | 按原 SQL 重建 55,585 + 225 行 → 500 变 200 / 0.14s |
| /api-market 500 + 密钥泄露 | 页面报错；更严重的是原本公开展示 8 个 api_key 的前 16 位 | keys 表 8 行 api_key 全为 NULL，模板拼接崩溃；脱敏逻辑缺失 | 过滤空值 + 只留末 4 位（****abcd）→ 500 变 200 / 5,305B / 2.5ms |
| /world/rg 每次访问实跑 80 条门禁 | 每打开一次门禁页就跑 8~19 秒，还占一个 waitress 线程 | 页面直接调 run()，每次都真跑一遍 | 改成默认读最近一次快照，?run=1 才实跑 → 毫秒级 |
| 2.8MB CSV 裸传 | 下载数据包要接近 1 分钟 | gzip_types 白名单里没有 text/csv | 补 text/csv application/csv text/tab-separated-values → 56.8s → 1.19s |
这一节只放实测数字，不写形容词。同一台机器、同一时刻、直连端口（不经 nginx、不经跨境网络）。
| 页面 | 修前 | 修后 | 倍数 | 关键证据 |
|---|---|---|---|---|
/deal-desk/free/eu-tender | 30.0s 超时 | 0.043s | ≈700x | 底层查询 34.5s → 0.003s；执行计划 SCAN TABLE tender USING INDEX ix_tender_pub |
/world/gr | 18.4s（冷）/ 1.70s（热） | 0.16s（热）/ 0.71s（重启后首次） | ≈115x | advise() 15.2s 移出请求路径；快照 6 条、src=llm、权限 600 |
/world/api/match/stats | 0.56s | 0.013s | ≈43x | stats JSON 逐字段比对一致（amount_cny / commission_cny / 各档计数） |
/world/match | 1.19s | 0.128s | ≈9x | 6 并发实测 6 个请求 0.48~0.54s，无塌陷 |
/world/download/wm-pairs.csv（2.8MB） | 56.8s（裸传） | 1.19s（gzip） | ≈48x | gzip_types 补 text/csv |
/deal-desk/（910KB） | 30.8s（curl 不带 Accept-Encoding） | 2.4s（gzip 112KB） | ≈13x | 虚警：浏览器本来就会带 Accept-Encoding，压缩后只 112KB |
buyer_country / cpv / deadline / buyer_email / notice_type——看上去"索引很齐全"，唯独页面真正用来排序的 pub_date 没有。单表 26.9 万行、2GB 的库，少一个索引就是 34 秒。这和 R251 修 GLEIF API 那次是同一类病：索引不是"有几个就行"，是"排序列必须在前导位置"。"安全固定"四件事全部落地，并且每件都有门禁盯着：
| 项 | 做法 | 持久化位置 | 门禁 |
|---|---|---|---|
| 监听收敛 | 51 个文件的 0.0.0.0 改 127.0.0.1；ilume_main.py 读环境变量，同步改 unit 里的 SERVER_HOST；50 个服务逐个重启复验（43/47 首轮 OK，余下由变量式绑定补齐） | 源码 + systemd unit | G81 |
| 防火墙持久化 | 新建 oneshot 服务，Before=network-pre.target；ExecStart=-/sbin/ip6tables-restore 用 - 前缀容忍无 IPv6 规则；rules.v4 里 8716/8717 的 DROP 插在 RETURN 之前第 15 位 | /etc/systemd/system/ilume-fw-restore.service + /etc/iptables/rules.v4 | G83 |
| 购买链路 | nginx /buy/ 静态 alias 兜底改命名 location 反代 8629；静态页仍走静态，/buy/<sku> 走服务端（服务端本就 200） | /etc/nginx/nginx.conf | G82 |
| 建议快照 | LLM 结果落盘 + cron 定时刷新；文件 600、目录被 nginx 403 拦截，不外泄 | static/datastore/growth_advice.json | G85 |
IPAddressDeny=any 来收敛监听。实测策略确实生效（外部访问被拒），但它对进程的所有网络访问生效——会把 ISRIC / NASA / GLEIF 这些对外采集一并切断。systemctl revert 撤销。结论：收敛只能改绑定地址，不能用 IPAddressDeny。种子 10 个入口，广度优先递归 3 层，全部在服务器本地回环跑（跨境抓 375 个 URL 要 20 分钟，回环 60 秒跑完 900 个）。
唯一的 404 是 /world/lead，它是留资表单端点，只收 POST，GET 返回 404 是设计——爬虫从首页把它当成链接抓到了。296 个 429 不是故障，是自测自己在打自家限流（3 线程 + 0.12s 间隔仍会撞 limit_req zone=ilume_limit burst=50）。这反过来证明 R251 加的 BOT 拦截与限流是活的。
慢页从 12 个（最慢 7.82s）降到 3 个（最慢 1.70s）：
| 页面 | 耗时 | 体积 | 说明 |
|---|---|---|---|
/deal-desk/service/DS-DP-trade-opps | 1.70s | 17.3KB | 商品详情页，渲染真实数据，可接受 |
/deal-desk/buy/DS-VAULT-TENDERINTEL | 1.43s | 20.7KB | 下单页，渲染真实数据，可接受 |
/world/gr/ch | 1.18s | 6.7KB | 渠道聚合首次计算（之后 900s 内命中缓存） |
最大的是 /world/download/wm-pairs.csv 2.81MB，本身就是下载件，走 gzip 后浏览器端实际收 300KB 左右。/deal-desk/ 910KB 压缩后 112KB / 2.4s——这是本轮唯一一处"看起来是卡点、实际不是"的虚警，记下来免得下次又去改。
每修一个问题就固化成一条门禁，是这套系统不退化唯一的原因。本轮新增 5 条：
| 编号 | 门禁 | 当前实测 |
|---|---|---|
| G81 | 监听收敛：内部服务零绑 0.0.0.0 | 除 22/80/443/111 外零端口绑 0.0.0.0，内部服务全部 127.0.0.1 |
| G82 | 购买链路：live 页每个 /buy/ 可达 | 12 个购买链接全部可取下单页（含 /buy/ 反代兜底） |
| G83 | 防火墙持久化：规则在册且开机恢复 | rules.v4 在册含 R220_FW · 开机恢复 enabled · 8716/8717 已覆盖 |
| G84 | 响应时间：关键页单页 <3.0s | 13 个关键页全部 <3.0s（最慢 0.25s）；每页取两次最快，抓"持续慢"不抓偶发争抢 |
| G85 | 建议快照：落盘在且新鲜，LLM 不占请求路径 | 快照 0.0 小时前刷新 · 6 条 · src=llm |
/world/match 被判超时 FAIL——原因是门禁自己在跑 G12/G13/G16/G59（扫 468 件标的、数 500 万行），把 2 核 CPU 占满了，一个 0.12s 的页面被测成 12s。改成每页测两次取最快之后 85/85。性能门禁必须区分"持续慢"和"被自己挤慢"，否则它只会逼着人调松阈值。全量跑一次的代价约 162 秒（run_id=103），所以 /world/rg 页面默认读快照、?run=1 才实跑，不让人在浏览器里等 3 分钟。
| 门禁 | 内容 | 实测 |
|---|---|---|
| G12 | 在售标的交付引用全量可达 | 468 件文件类标的交付引用全部可解析 |
| G13 | 交付物真实：可达且有实质内容 | 449 件文件类标的全部可达且有实质内容 |
| G14 | 交付形态完整：kind 全有分支 | 1,641 件标的 kind 全部有交付分支 |
| G15 | 数据资产禁售：内部库零泄漏 | 可售 126 库，无内部运营/客户/财务库泄漏 |
| G16 | 交付全量：全量包齐备且不落后 | 126 库全量包齐备且与源库一致 |
| G17 | 数据龄期：不卖僵尸数据 | 126 可售库全部在 SLA 内 |
| G18 | 全库交付：多表库必交 tar.gz 含附表 | 121 个多表库均有全库包（含附表） |
| G19 | 接口可用：API 标的逐件能取数 | 46 件接口逐件可取数（vault + 母库双通道） |
| G59 | 数据包真实性：行数/国别/交付件 | 9 个数据包共 5,136,279 行，全部对得上 |
| G80 | 交付包成员：AST 级确认 08-11 真被赋值 | _pack_files 实赋值 14 个成员，08-11 四件齐备 |
FAIL G16 · 1 库全量包落后源库：carbon-desk(+230)。2716fdce…）、全库 7 表 / 121,884 行（5.11MB，md5 5500af97…）。延续前几轮的口径，以下四类不是"还没做"，是"做不到就不该写"：
| 项 | 为什么不做 |
|---|---|
| 地块级实测样地数据 | 需要现场布点取土、实验室化验，远程不可能产生；现有遥感核验已注明"估算值 + 不确定性区间"，没有冒充实测 |
| 第三方核证资质 | 须市场监管总局批准的机构出具，平台不是核查机构，只能做"核证询价对接" |
| 碳市场过户通道 | 须成为交易所会员，没有会员资格就没有过户资格；页面写的是"4 条路径 + 对接方式"，不是"我们能过户" |
| 备案成功案例清单 | 官方动态发布，抄录必过期；只做"6 阶段 × 6 类型"对照表 |
dh_ask（询盘）仍为 0，G52 的"报价单 0 条"就是这个原因——不是报价功能坏了，是还没有人问价；im_dispatch 只生成直链，必须人工点发。全部补丁脚本均带 DRY → apply 两段、py_compile 失败自动回滚、并留 .rXXX_pre 备份。生产改动一律先核 md5 再就地打补丁。
| 文件 | 作用 |
|---|---|
_audit_r260_link.py / _audit_r260_link2.py | 死链爬虫（外网版 / 回环版）；回环版带计时与慢页排行，900 URL 60 秒跑完 |
_p_r260a~c.py | 监听地址收敛（51 文件）+ 重启复验 + 变量式绑定补齐 |
_p_r260d~j.py | /world/rg 快照、api-market 脱敏、/buy/ 反代兜底、G81-G83、gzip 补 CSV |
_r260_gleif_repair.py | 重建 gt_link 55,585 行 / gt_cc 225 行 |
_p_r260k.py | 大库 ORDER BY 无索引静态体检（150 处候选，多为列名撞车误报，未据此改动） |
_p_r260l~o.py | 卡点拆解探针（eu-tender / match / gr 各组件逐一计时） |
_p_r260p.py | growth_hub 建议落盘 + warm CLI |
_p_r260q.py | GRWARM 装进 root crontab（显式 sudo + 行数核对） |
_p_r260r~t.py | G84 / G85 新门禁；G84 改两次取最快；聚合 TTL 60→900 + cron 降优先级 |
world_lib.py.r260n_pre world_lib.py.r260s_pre growth_hub.py.r260p_pre regress_hub.py.r260r_pre regress_hub.py.r260t_pre rules.v4.r260bak crontab.r260.bak
本报告全部数字来自生产机实测：门禁 run_id=103（2026-10-20 19:40）· 爬虫 900 URL（服务器本地回环）· 耗时均为直连端口三次采样。未做任何估算或推断填充。