独立产品接入统一权限平台，表面上是换登录和菜单，实际上是在替换一批原来藏在代码里的约定。原来的管理员管多大范围，已有页面属于谁，后台任务以谁的身份跑，都要重新核对。
这次集成，我把资源映射与授权切换单独设计。界面接入只是可见部分，原有用户的数据范围不能在迁移时被悄悄放大。
用户操作和后台任务使用不同身份
页面查询由用户发起，按用户当前组织和权限执行。定时处理、系统集成使用明确的服务主体，不拿某个用户会话无限续期。
调用中还可能同时出现应用身份与用户上下文。应用身份说明哪个应用接入，用户上下文说明替谁执行，不能把两份权限取并集。访问范围同时受应用能力和用户权限约束。
认证中间件建立可信主体，资源适配器解析旧标识，授权客户端判断动作与资源，业务处理器执行操作。各层保留同一请求标识，日志能把决策与业务结果串起来。前端 SDK 负责菜单和可用操作的表达，服务端不依赖它已经检查过的假设。
资源迁移不等于整批开放
产品的页面、模板、组件和数据源，不一定都成为统一平台中同一种资源。是否需要单独授权，取决于谁管理、如何共享和业务用户能否理解这个粒度。版本覆盖这样的生命周期规则可以留在产品内，组织范围的管理能力则需要统一表达。
映射表保留租户、原资源类型、原标识、新引用与迁移批次，并设置唯一约束。重复执行同一批迁移，返回同一对象，不新增一份看起来相同的资源。
原产品管理员也不能直接映射为平台超级管理员。把原来允许的动作与范围列出来，再生成角色绑定。已有页面的归属、共享规则与旧链接的访问行为，在切换前有确定答案，不能上线时临时设成全部可读。
影子判断用于解释差异
旧权限继续决定请求结果，新平台对同一个请求只计算和记录。把分歧分成资源映射缺失、动作映射不符、范围不同和身份不一致，逐项确认。
这里不能用“两套任意一套允许就放行”来减少报错，那是在扩大权限。影子阶段不改变业务结果，差异有解释和确认记录以后，才把相应路径交给新决策入口。
切换按读请求、写请求、后台任务分段进行。授权服务不可用时，写操作拒绝；读操作是否允许短时间缓存，取决于事先定义的陈旧窗口。网络错误不能统一当成允许。
失败时回退什么
回退切换的是决策入口，已经产生的业务数据不跟着回滚。新旧资源映射保留，迁移批次记录不能被删掉，否则恢复以后可能再建一遍。
验证包括普通用户直接访问他人资源、只读用户修改、组织切换后使用旧链接、撤权后继续调用，以及应用暂停和授权服务失败。接口错误还要被前端转成可处理的状态，不能全部显示成重新登录。
本轮集成已完成。后续新增资源类型和应用版本时，沿相同的身份、映射、决策、业务执行路径检查，确认旧的访问约定仍然成立。这样才能知道一次问题来自接入关系，还是具体业务规则。