角色和能力可以持久保存在站点数据中。停用某个角色管理插件，未必自动撤销它创建的角色或修改；需要核对实际角色定义、用户分配与扩展卸载行为，而不能用插件列表状态推断权限已恢复。
先保存当前权限清单
记录自定义角色、各自能力以及分配给哪些用户，区分插件提供的管理界面与数据库里的实际定义。某些角色名称看起来普通，但能力曾被修改。只截图角色名称，不能支持之后确认是否恢复默认权限。
阅读停用与卸载差异
停用通常停止程序加载，卸载是否清理数据取决于扩展实现及设置。不要假设所有插件都删除角色，也不要为了清数据反复删除重装。先在测试副本验证实际生命周期，对仍有业务使用的角色制定迁移安排。
处理用户与能力两层关系
删除一个自定义角色前，给相关用户分配合适的新角色，并检查是否存在直接授给用户的额外能力。用户只换了角色，但个别直接能力仍在，可能继续允许敏感操作。多站点下还要按所属子站逐一核对。
回测实际操作而不是只比表格
使用受控账号检查编辑、上传、导出及管理功能。权限工具显示的结果需要与实际请求一致，服务端自定义能力过滤也应考虑。记录最终角色定义和修改理由，避免下一次启用旧插件又悄悄恢复历史配置。
关键区别
插件停用：停止对应代码；未必清理角色。
角色定义：保存能力集合；可能持续存在。
用户直授：单用户额外能力；换角色也需核查。
怎样确认处理到位
相关用户均有明确角色，遗留角色与直接能力经过处理，允许和拒绝的实际操作符合新方案，重新启用影响已说明。
容易误判的边界
没有统一的“卸载即还原”规则；清理前必须理解原有业务依赖，不能直接删除所有非默认角色。
