ACL有多招人恨？老运维最清楚。两千条规则堆在配置文件里，一个员工调部门，就得改十张表。我看过更夸张的，某银行核心系统的ACL规则超过五千条，权限变更的工单排到两周后。这不是技术问题，是管理灾难。
话说回来，大家都在吹ABAC。按属性算权限？听起来很优雅。但真上线时，策略引擎的性能直接把业务方骂到自闭。一万条策略下，一次决策请求的平均延迟超过18ms，高峰期还连环超时。你说你不上缓存？不敢上，怕缓存失效出安全事故。
ACL为什么在分布式时代散架
ACL的本质是“你就是那张表”。表上写着谁对哪个资源有什么权限。就像单元门的钥匙配给单，每家一把钥匙。但公司五千人，门有两百道，配钥匙的师傅直接辞职。
更麻烦的是，ACL是硬编码在应用里的。权限变更要重启服务，或者同步到几十个节点。我见过一个事故，运维改漏了一个节点，结果离职员工还能访问内部系统，血泪教训。
另一个致命伤是ACL无法表达动态条件。比如“仅在上班时间允许访问财务系统”，ACL直接投降。你要么造很多临时账号，要么就只能睁一只眼闭一只眼。
ACL的静态映射在单体应用里还能凑合。一旦微服务化、多云混合，ACL就是另一场“运维马拉松”。
ABAC策略引擎的内核拆解
ABAC换了个思路：不列名单，算属性。请求方、资源、环境、操作都有属性。比如“角色=经理”且“部门=财务”且“时间=工作时间”就可以审批。决策引擎拿到这些属性后，跑一遍策略集。
但性能瓶颈在哪？线性扫描每条策略，用正则匹配属性，这不慢才怪。
我们团队一开始也是线性实现，一万条策略，P95延迟直接爆表。后来我们把策略编译成决策树。属性空间切成多级索引，命中率飙升。具体做法：为每个策略生成二进制掩码，用分支阈值剪枝。本质是空间换时间。
给你看组对比数据：同为10000条策略，线性扫描P95为18.3ms，决策树版本P95只有1.2ms，吞吐量从200 QPS提升到3200 QPS。代价是内存开销增加了约45%（要缓存节点索引），但在大规模访问控制场景，这买卖划算。
决策树的核心是“剪枝”。策略中很多属性是冗余的，比如所有策略都要求“状态=正常”，你就可以把这个条件提到根节点，一下子过滤掉80%的无效请求。另一个技巧是哈希索引，把枚举型属性映射到整数，比较起来是O(1)而不是字符串正则。
但别高兴太早。决策树也不是银弹。当属性维度太多时，树会变得很“胖”，内存爆炸。我们试过60个属性，树节点超过百万，GC频繁，卡成PPT。后来用了一种叫“有序多叉树”的变体，把边缘阈值排序存储，查询时二分查找。这才压住了。
还有，属性上下文的获取往往是隐藏的成本。我们做过统计，PDP实际计算只花0.3ms，但属性准备花了2ms。老慢。后来把用户属性缓存到PDP本地，用版本号失效，才降到0.5ms。
落地时踩过的三个坑（必看）
坑1：策略爆炸。ABAC容易把业务规则全塞进策略里，结果你发现策略比ACL规则还多。我们就有过这样，搞了五千条策略，维护成本直线飙升。解决方案：用策略分组 + 命名空间。父策略定义基础授权，子策略做细节扩展。建议每组不超过500条，用树状组织，应用层按命名空间隔离，互不影响。
坑2：缓存失效。因为你缓存了决策结果，当用户属性或策略变更时，你没法及时失效。我们有次部署新策略，PDP缓存没刷新，导致新策略半天没生效。注意，这不是性能问题，是安全漏洞。解决：给策略集增加版本号，每次变更自增。缓存key带版本号，旧版本直接丢弃。另外用Redis发布订阅通知所有PDP节点失效。千万别说“等缓存自己过期”，那真的会出事。
坑3：审计追踪。ABAC决策是黑盒子，你很难说为什么拒绝。但合规审计需要记录每个请求的属性和命中策略。我们曾经被审计点名，因为无法解释某个拒绝原因。解决方案：异步写日志，但注意别影响主链路。我们用了Kafka管道，批量写入，高峰期决策性能无损。但必须保证失败重试，否则审计缺失。
说到底，访问控制不是功能，是工程。ACL简单但僵硬，ABAC灵活但烧脑。无脑吹ABAC的，多半没被策略爆炸坑过。但掌握了决策树编译和缓存失效技巧，ABAC依然是最合适的选择。别指望一把锁管一辈子。
