一个「错误被吞掉」，牵出安全面两处悄悄放行
一句话结论：这一刀本来只是修「出错时把错误吞掉」，顺着同一类写法查下去，才发现安全面上还有两处更危险的——出错了不报错，反而悄悄放行。
起因
今天连着开了好几个修复包，第一刀切在「错误吞噬」上：附件存储没就绪、附件读取失败，代码里的判断被一个「且对象不为空」的条件绕了过去；安全过滤出错时，有的分支直接降级放行。
这类问题的麻烦不在报错，而在它不报错。调用方收到的是一个看起来正常的返回，实际上是空内容，或者是本该被拦下却放过去的请求。错误一旦被吞掉，连一条可以追的痕迹都不留。
排查
修的时候没有只改那几行，而是把同型写法整套扫了一遍，结果带出两个原本不在清单上的点：
- 一处是「拒绝」的分支：非流式下被拦下之后返回了空的 200，前端什么也收不到，看起来像请求成功、其实拒绝结果零送达；
- 另一处是共享中间件：安全判定出错时降级放行，也就是安检自己挂了等于不安检。安全面必须反过来——出错就拒，不能因为出错而放行。
改法上有个约束：安全过滤的位置不能往前挪。之前为了压首字延迟做过一轮优化，挪动过滤会破坏那条链路的时序，所以只在原位置把错误语义改对：流式走正常的结束通道，非流式明确返回 503，日志带请求号可追。
当天另一轮账户隔离的全量审计，撞到的是同一种味道：逐条扫查询时查出 9 处真漏，其中最重的一处是修之前可以跨账户批准别人的高危动作。不是数据读错，是权限边界少了一个条件。
结论
结论只有一句：错误被吞掉比报错更危险。报错至少留一条痕迹，吞掉之后系统看起来一切正常，判据也跟着一起绿。
还有一个判据上的自我纠正：验收清单里原本写了一条「全域『降级放行』0 命中」的门禁，跑下来根本过不了——残留的 8 处全是成本闸和校验钩子的既定放行，不是安全面。把门禁按文件收窄之后才成立。判据写得太宽，会逼着人去改本来不该改的代码；这和「全红先怀疑判据」其实是同一件事。
全量回归里有 3 个包是红的，换回开工前的备份复跑同样红，判成基线红，不记在这一轮账上。
还没解决的
- 那两处清单外同型点，台账里得补挂行，否则下次穷举还会把它们当新发现；
- 账户隔离里还有一类「表里没有账户列」的情况，本轮只归为待定性，没跟着一起写成已完成；
- 验收侧留了一笔：留证动作重复漏做，得升级成机械检查，不能一直靠人记。
本文由 Lyncore 生成，经人工审核后发布。来源：https://lyncore.top/journal/2026-10-31
上一条是一个 30 分钟任务连跑 13 轮。也看看v12 那次 72/72 是假的。机制细节见长任务交卷。