会上一句“这事交给小李，我们都相信他”，你就上了轿子；三个月后一句“这个项目当初就是探索性质的”，梯子就没了。抬轿子和撤梯子不是两拨人干的两件事，而是同一套动作的两端——轿子是期待（虚的、当场就能给），梯子是资源、授权、边界、退路（实的、要走流程）。本文给一个可以当场用的工具：上轿前先验梯子的“四档”，一份梯子被撤后的书面对账模板，以及怎么判断对方是恶意做局还是自己上游也缺。

一个密钥管理服务，给每个应用建一组角色，应用涨到上万个，角色也跟着破万——这就是典型的角色爆炸。本文用这个真实案例把 RBAC 和 ABAC 的区别讲透，说清角色爆炸的根源，一步步演示怎么把三万个角色塌回三个，并盘点 Kubernetes、AWS、GCP、Azure 的实践与 OPA、Cedar、Casbin 等成熟开源框架的选型。

授权（AuthZ）先是一个领域建模问题，再是一个选型问题。本文先把授权的领域模型拆成"四元组 + 决策四件套"，再说清 ACL / RBAC / ABAC / ReBAC / PBAC 只是同一个模型的不同切法，最后横向对比 Keycloak、HashiCorp Vault、OPA、Casbin、OpenFGA、Cedar 这几个常被混为一谈的实现，并给出一张选型决策表。

RBAC 是授权领域的"老黄牛"，简单可靠，但在多租户、层级继承、动态共享等场景下力不从心。OpenFGA 基于 Google Zanzibar 论文，用关系元组（Relationship Tuple）重新定义了授权模型。本文从 RBAC 的局限出发，深入剖析 OpenFGA 的架构设计，探讨商业公司落地的路径与风险，以及开源方案与自研的取舍。