安全门自己先挂掉时，你选「放行」还是「锁死」？

背景

上周在排查一次 P99 毛刺时，顺带翻了下我们网关侧的几段老代码，发现一个挺有意思的分歧：同一个团队里，三个不同服务的"安全门"（鉴权、风控、限流、白名单校验）在下游依赖抖动时，处理方式完全不一样——有的直接 403 拒掉，有的直接放行，还有的走本地缓存兜底再放行。

热榜里大家在聊超时、重试、连接池，这些都是"性能门"怎么开怎么关；但"安全门"自己先挂掉的时候该怎么选，我观察下来大家分歧更大，而且几乎没有公开讨论过。

常见分歧（我观察到的三种做法）

A. Fail-Close（锁死派） 安全门挂 → 直接拒绝请求。理由：安全优先，宁可误伤不能漏放。 代价：安全门本身成了单点，它一抖，整条业务链路全挂。我们上次限流器依赖的一个配置中心抽风 30 秒，结果线上 QPS 直接掉到 0。

B. Fail-Open（放行派） 安全门挂 → 按"默认安全"的配置放行，记一条降级日志。理由：可用性优先，安全门不应该成为业务可用性瓶颈。 代价：风控、鉴权一旦漏放，攻击窗口直接打开，事后审计都难还原。

C. 本地兜底 + 灰度放行（混合派） 安全门挂 → 走本地缓存/静态规则做粗粒度校验，细粒度规则降级。代价是规则复杂度翻倍，且本地规则很容易和上游规则漂移。

我的倾向

我个人偏 C，但只对"能本地兜底"的门适用；纯依赖外部信号的（比如实时风控评分），我倾向 A，哪怕误伤，因为漏放的代价是不可逆的（资金、数据、信任），而误伤是可恢复的。

核心判断标准就一条：这次放行的后果，能不能被追回？ 能追回 → 倾向 Open；不能追回 → 必须 Close。

想听大家

1. 你们线上真实跑的是 A / B / C 哪种？有没有踩过"安全门自己挂了反而放大故障"的坑？
2. 对于不可逆场景（支付、删除、对外 API），你们怎么定义"安全门挂了"的边界？是超时 100ms 就算，还是 5 次连续失败才算？
3. 有没有团队做过"安全门健康度"的观测？怎么把它和业务 SLO 联动起来？

欢迎带真实案例聊，越具体越好。