管理员角色中已经勾选菜单权限，打开页面仍返回 Access Denied。菜单可见和控制器授权是两次检查，自定义模块的 menu.xml、acl.xml 和控制器 ADMIN_RESOURCE 只要资源 ID 不一致就会失败。

固定复现条件

记录管理员、角色、菜单资源 ID、控制器类与失败 URL。使用全权限管理员和受限管理员对照，确认是否仅自定义页面失败。

grep -R --line-number 'ADMIN_RESOURCE|<resource id=' app/code/Vendor/Module 2>/dev/null
grep -R --line-number '<add.*resource=' app/code/Vendor/Module/etc/adminhtml/menu.xml
php bin/magento cache:clean config
SELECT role_id,parent_id,role_type,role_name FROM authorization_role ORDER BY role_id;
SELECT role_id,resource_id,permission FROM authorization_rule ORDER BY role_id,resource_id;

根据证据定位

菜单 resource 与控制器 resource 不同会出现看得见却进不去；acl.xml 父节点错误会让勾选项不代表真实资源。只对旧 Session 失败时，重新登录可刷新权限，但这不能修复资源定义错误。

修复与回滚

统一 acl.xml、menu.xml 和 ADMIN_RESOURCE，选择合理父资源并升级模块配置。后台角色应按最小权限重新保存；不要绕过 _isAllowed 或把控制器改为全局允许。

验收

新建最小权限角色，允许页面可访问、未授权页面继续拒绝；保存、导出、批量操作和 AJAX 子路由也要逐一验证。

生产环境操作前的检查

处理“Magento 2 修改管理员角色后仍提示 Access Denied”前，先记录 Magento 版本、部署模式、问题 Store View、复现时间和最近发布。所有 SQL 默认先执行 SELECT；写操作、目录清理、服务重启和配置切换必须确认范围、保留备份并准备回滚。多节点环境还要核对构建版本、app/etc/env.php 配置摘要和实际流量节点。

php bin/magento --version
php bin/magento deploy:mode:show
php bin/magento maintenance:status
php bin/magento indexer:status
php bin/magento cache:status

命令应由 Magento 文件所有者在项目根目录执行。不要在生产高峰同时运行全量索引、静态部署和数据修复；涉及客户、支付、税费、库存或订单的变更，应先在脱敏数据副本验证。

建立可比较的排查记录

每次实验只改变一个变量，记录操作前值、命令、开始与结束时间、结果和回滚方式。至少准备一个正常对象和一个异常对象；旧对象恢复而新对象仍能复现，说明根因尚未消除。

检查层证据通过标准
入口 URL、状态码、请求 ID、节点 路由与协议一致
应用 异常堆栈、模块、作用域 无新异常且可重复
数据 主键、时间、关联行数 关系完整无重复副作用
业务 正常、失败与重试路径 最终状态一致

修复后的观察窗口

上线后至少观察一轮 Cron、队列和索引周期，并在两台节点、无痕浏览器与目标 Store View 重复验证。临时调试日志必须脱敏，确认错误率、响应时间和数据量稳定后及时关闭。