📚 课程目录第2章静态策略的局限性

2. 静态策略的局限性：硬编码策略的痛点、业务变化导致的策略僵化、静态策略的维护成本

上一章我们聊了权限策略的基础模型，看起来挺规整的。但说实话，那种「写死」的策略，在实际生产环境里就是个定时炸弹。我见过太多团队，一开始图省事把权限写死在代码里，半年后整个项目就寸步难行。

这一章，我们就来扒一扒静态策略的底裤。看看它到底有哪些坑，为什么说它是「前期爽、后期哭」的典型代表。

2.1 硬编码策略的痛点

什么叫硬编码策略？说白了，就是你把权限判断的逻辑直接写在业务代码里。比如下面这种：

// 伪代码：硬编码权限判断
if (user.role === 'admin') {
    // 允许删除
    deletePost(postId);
} else if (user.role === 'editor') {
    // 只能编辑自己的文章
    if (post.authorId === user.id) {
        editPost(postId, newContent);
    } else {
        throw new Error('无权限');
    }
} else {
    throw new Error('无权限');
}

这段代码有什么问题？问题大了去了。

核心痛点：权限逻辑与业务逻辑完全耦合。改一个角色权限，你得改代码、走发布流程、重新部署。这在微服务架构下简直是灾难。

我列几个最常见的硬编码痛点：

改权限 = 改代码：每次业务方说「编辑也能删除文章了」，你就得打开IDE，找到那个if-else，加上一个条件。然后提PR、走CI/CD、等发布。一个简单的权限变更，周期至少半天。
权限逻辑散落各处：你想想看，一个系统里可能有几十个类似上面的if-else。它们分散在不同的服务、不同的模块里。你想知道「编辑角色到底有哪些权限」？对不起，你得把整个代码库翻一遍。
缺乏全局视图：硬编码策略没有「策略清单」这个概念。你没法一眼看出某个角色能做什么、不能做什么。审计的时候，你拿什么给合规部门看？
容易遗漏：我曾经在一个项目中，因为改了一个角色的权限，漏掉了某个边缘接口的if-else判断，结果线上出现了越权漏洞。嗯，那次的P0事故，我到现在还记得。

我的建议：如果你现在还在用硬编码做权限判断，赶紧停下来。哪怕只是把角色和权限的映射关系抽到一个配置文件里，也比写在代码里强一百倍。

2.2 业务变化导致的策略僵化

静态策略最大的敌人，就是「变化」。业务不可能一成不变，而静态策略恰恰最怕变化。

我举个例子。你做了一个内容管理系统，初始策略很简单：

管理员：所有权限
编辑：增删改查文章
作者：只能操作自己的文章
读者：只能看

这个策略在系统上线前三个月跑得挺好。但三个月后，业务方开始提需求了：

「编辑不能删除文章了，这个权限收回到管理员手里。」
「作者可以编辑自己的文章，但需要审核后才能发布。」
「有些文章是付费内容，只有VIP读者才能看。」
「我们需要一个‘超级作者’角色，他可以编辑所有人的文章，但不能删除。」

你看看，这才几个需求，你的静态策略就已经扛不住了。为什么？

角色爆炸：为了满足这些需求，你不得不创建「编辑-无删除版」、「作者-需审核版」、「超级作者」等一堆新角色。角色数量从4个膨胀到十几个。
策略粒度太粗：静态策略通常只能做到「角色-资源」级别的控制。但业务需要的是「角色-资源-操作-条件」级别的精细控制。比如「作者在文章状态为‘草稿’时可以编辑，但文章状态为‘已发布’时只能申请修改」——这种条件判断，静态策略根本表达不了。
策略冲突：当角色多了，你可能会遇到「用户同时拥有‘作者’和‘超级作者’角色，到底该按哪个策略执行？」的问题。静态策略没有优先级或合并机制，全靠代码里写死逻辑，很容易出bug。

避坑指南：我曾经在一个电商项目中，因为业务方频繁调整运营人员的权限，导致我们每两周就要发一次版本。后来我们统计了一下，全年40%的发布都是因为权限策略变更。这不仅仅是开发成本的问题，频繁发布本身就在增加线上风险。

静态策略的僵化，本质上是它把「策略」和「实现」绑死了。策略应该是数据，而不是代码。数据可以随时改，代码不行。

2.3 静态策略的维护成本

前面说的都是技术层面的问题。但如果你跟老板汇报，他可能更关心「维护成本」——说白了，就是「要花多少钱、多少人、多少时间」。

我算过一笔账，大家可以看看：

维护项	静态策略（硬编码）	动态策略（策略引擎）
单次权限变更耗时	4-8小时（改代码+测试+发布）	5-10分钟（改配置+生效）
权限审计准备时间	2-3天（翻代码+整理文档）	10分钟（导出策略清单）
新人上手成本	高（需要熟悉所有if-else分支）	低（看策略配置即可）
策略冲突排查	靠人肉review，容易遗漏	引擎自动检测冲突
跨服务策略一致性	需要每个服务单独实现	统一策略中心下发

你看，静态策略的维护成本，在「变更频率」和「策略规模」两个维度上是指数级增长的。当你的系统有10个角色、20个资源、50个操作时，硬编码还能勉强维持。但当规模扩大到100个角色、500个资源、2000个操作时，静态策略就是一场噩梦。

我见过一个真实的案例。某公司的权限策略全部写在代码里，随着业务发展，代码里积累了上千个if-else判断。后来他们想做一个权限审计，结果花了两个星期才把所有策略梳理清楚。更可怕的是，梳理过程中发现了好几个历史遗留的越权漏洞——有些接口的权限判断逻辑，连写代码的人自己都忘了。

总结一下静态策略的三大成本：

人力成本：每次变更都需要开发介入，测试回归，运维发布。
时间成本：从需求提出到上线，周期长，响应慢。
风险成本：策略散落、逻辑混乱、容易遗漏，导致安全漏洞。

所以，静态策略不是不能用。如果你的系统只有两三个角色，权限几乎不变，那硬编码确实省事。但只要你稍微有点规模，或者业务变化频繁，静态策略就是一条死路。

嗯，说到这里，你应该已经明白为什么我们需要「动态策略」了。下一节，我们来看看动态策略是怎么解决这些问题的。不过在那之前，我建议你先审视一下自己的系统——你的权限策略，是不是也到了该「动」起来的时候了？