德摩根定律对比：权限案例
德摩根定律对比在真实案例中更容易看清价值。本文复盘一个后台权限规则改写过程，从原始需求、错误表达、正确变形到测试验证逐步还原，比较错误写法和等价写法的差异，说明为什么小小的连接词会影响整套访问控制。
步骤一：还原原始需求
某后台系统要限制数据导出：如果用户不是管理员，且没有通过二次验证，就不能导出敏感报表。产品口径是“禁止同时不具备管理员身份和二次验证的用户导出”。这里有两个条件：A 表示管理员，B 表示已二次验证。允许导出的逻辑，不应只看其中一个条件，而要和禁止条件做德摩根定律对比，确认边界是否一致。
步骤二：识别错误写法
开发初稿写成 !A && !B 时，表示“既不是管理员，也未验证”才禁止。这个判断看似符合文字，但如果系统的目标是允许“管理员或已验证用户”导出，那么禁止条件应是 !(A || B)，也就是 !A && !B。问题在于需求讨论时另一位同事把它改成 !A || !B，导致管理员但未二次验证、已验证但非管理员都会被拦截。对比可见，一个或字把限制范围扩大了。
步骤三：写出正确等价式
若允许条件是 A∨B，禁止条件就是 ¬(A∨B)，按德摩根定律变形为 ¬A∧¬B。若禁止条件原本定义为 ¬A∧¬B，反推允许条件就是 A∨B。这个案例的关键不是哪个写法更短，而是哪一个表达更贴近业务主语。权限系统建议保留“允许条件”作为主公式，再派生“禁止条件”，这样比直接堆否定更容易评审。
步骤四：用四组用户测试
复盘时团队列了四组用户：管理员且已验证、管理员未验证、非管理员已验证、非管理员未验证。按允许条件 A∨B，前三组应通过，最后一组应拦截。若使用错误的 !A || !B 作为禁止条件，则第二组和第三组也会被拦截，业务投诉会集中出现。德摩根定律对比的价值就在这里：它把抽象公式落到可验证样本上。
步骤五：沉淀规则模板
最终团队把权限表达拆成两层：先写正向允许条件，再用德摩根定律生成反向拒绝条件；任何修改都必须附带四象限测试。正面效果是逻辑透明，测试覆盖清晰；代价是需求文档要多写一步。但对涉及资金、隐私和报表导出的系统，这一步成本很低。案例结论是，德摩根定律对比不只是数学练习，而是控制规则误伤和漏放的实用方法。
常见问题
德摩根定律对比适合哪些业务场景？
适合权限校验、搜索过滤、风控拦截、优惠券适用条件等场景，尤其是存在多个条件和整体否定时。
权限规则里应该写正向条件还是反向条件？
通常建议先写正向允许条件，再派生反向拒绝条件。正向表达可读性更高，反向表达更适合拦截实现。
怎么用测试用例验证德摩根定律改写？
列出所有关键条件组合，比较原式和变形式的通过、拦截结果。两边每一组都一致，才说明等价。