聚合型 BFF 接口「超时≠失败」：前端只拿到 net::ERR_TIMED_OUT 时，怎么区分「BFF 还在跑」和「BFF 已失败」？幂等键之外有没有可复现的对账做法？

背景

我是前端，我们有一个典型的聚合型 BFF 接口 /api/home/feed：一次请求内部 fan-out 到 4 个下游（用户画像、内容推荐、活动位、AB 配置），单接口 SLO 是 1.2s。按 P99 口径给下游切的预算是 600/500/300/200ms，理论余量 200ms——但实际线上 P99 里下游偶发打到 900ms+，留给「合并 + 序列化 + 响应头」的余量经常掉到 50~80ms，也就是说BFF 侧的超时经常「贴着」1.2s 边界打。

前端侧 timeout 也配的 1.2s（和 BFF 同值，没做 +ε）。结果就是：有一小撮请求，BFF 内部其实跑完了（甚至部分下游已经写库成功），但响应没在前端 timeout 前送达，前端看到的是 net::ERR_TIMED_OUT。

现象

1. 前端监控里这个接口的「超时率」约 0.3%，但 BFF 侧 access log 里对应的「5xx + 超时」只有 0.1%——两边对不上，差了 2 倍多。多出来的那部分，BFF 侧日志显示请求最终是 200 成功返回的，只是比前端 timeout 晚了几十到几百 ms。
2. 更麻烦的一类：feed 里有一个「领取活动位奖励」的动作混在聚合请求里（历史原因没拆出去），前端超时后用户点重试，出现了重复领取——这就是 id=1592 那篇复盘里说的「重试不是救场，是容量放大器」在我们前端的翻版，只不过我们连「要不要重试」都判断不了。
3. 值班时经常收到「页面加载失败」工单，但查 BFF 日志全是 200，查网关也 200——用户侧的「失败」在服务端视角里根本不存在，这种 case 我只能建议用户刷新，没有数据支撑。

已尝试的排查与结果

• 给前端 timeout 加 ε（1.2s → 1.5s）：超时率降到 0.15%，但弱网用户体感变差，且 ε 加多大纯拍脑袋，没有依据。
• 前端超时后带 Idempotency-Key 重试：解决了重复领取，但 BFF 侧没有实现「幂等键 → 结果缓存」的通用层，只是业务侧各自 if 判断，覆盖不全。
• 让 BFF 返回一个 X-Request-Status 头 + 客户端轮询 /api/request-status/{id}：方案评审被否了——聚合接口是纯读的，「查状态」比「等结果」成本高，且前端要维护一个「在途请求表」，复杂度不值。
• 看 BFF 的 P99 分布来决定前端 timeout：拉了 30 天数据，P99=1.18s、P999=1.6s，P99 和 timeout 几乎重合，说明「按分位数配 timeout」在这个接口上天然失效——问题不在配多少，在于超时那一刻服务端状态不可知。

期望得到的答案形态

1. 你们有没有遇到「前端超时率 > 服务端 5xx 率」且无法用网关解释的 gap？你们的对账口径是怎么建的（哪些日志 join、哪些字段、多久对一次）？
2. 对于「BFF 还在跑」vs「BFF 已失败」这个二分类，除了幂等键重试，有没有服务端零改造或轻改造的做法？比如流式响应（SSE/分块）让前端在 1.2s 前先收到「还在处理中」的信号？
3. 如果接受「前端 timeout 必然有一部分落在服务端成功区间里」这个事实，你们是怎么量化这个 overlap 的，并据此决定 timeout 到底配多少的？有可复现的公式或数据吗？
4. 重复领取这类「超时 + 重试 = 副作用放大」的场景，你们是在前端做幂等、BFF 做幂等、还是业务层做幂等？各自的坑是什么？

欢迎贴具体的配置、日志样例、对账 SQL——细节越多越能对上。