phpMyAdmin无“禁止编辑存储过程”开关，需通过MySQL权限控制实现：用户必须被撤销ALTER ROUTINE、CREATE ROUTINE及GRANT OPTION权限，否则即使界面显示“编辑”按钮，保存时也会因权限不足报错#1227；界面不预判权限，仅依赖MySQL服务端校验。
phpMyAdmin 本身不提供“禁止编辑存储过程”的开关
它没有类似 DisableRoutineEditing 这样的配置项。所谓“禁止编辑”，实际只能靠权限控制 + 界面限制双重实现：MySQL 层面不让用户有修改权限，phpMyAdmin 层面则因权限不足而自动隐藏编辑入口或报错。
关键在 MySQL 用户权限，不是 phpMyAdmin 配置
即使你在 phpMyAdmin 界面看到“编辑”按钮，点击后执行的仍是 ALTER PROCEDURE 或 DROP/CREATE PROCEDURE，这些操作最终由 MySQL 服务端校验权限。所以真正起作用的是用户的 MySQL 权限设置：
- 用户必须没有目标数据库的
ALTER ROUTINE权限（这是修改/删除存储过程的必需权限） - 同时不能有
CREATE ROUTINE（否则可删旧建新绕过） - 也不能有
GRANT OPTION，否则可能自行授予权限 - 确认权限已生效：
SHOW GRANTS FOR 'user'@'host';
常见错误现象：用户在 phpMyAdmin “例程”页能看到存储过程列表，也能点“编辑”，但保存时报 #1227 - Access denied; you need (at least one of) the SUPER or ALTER ROUTINE privilege(s) —— 这说明权限控制已起效，只是界面没提前拦截。
phpMyAdmin 界面不会主动隐藏“编辑”按钮
它只根据当前用户能否执行 SHOW PROCEDURE STATUS 来决定是否显示存储过程列表，但不检查 ALTER ROUTINE 是否存在。因此，即使用户无权修改，按钮仍会显示，直到点击保存才失败。
立即学习“PHP免费学习笔记（深入）”；
- 这不是 bug，是设计使然：phpMyAdmin 不做二次权限预判，它信任 MySQL 的权限返回结果
- 如果你希望彻底不暴露入口，唯一办法是让该用户连
SHOW PROCEDURE STATUS都无权执行（即不给SELECT权限到mysql.proc表，或升级到 MySQL 8.0+ 并用INFORMATION_SCHEMA权限控制） - MySQL 8.0.16+ 中，
INFORMATION_SCHEMA.ROUTINES的可见性受SELECT权限控制，但需注意：默认所有用户都能查这个视图，除非显式REVOKE SELECT ON INFORMATION_SCHEMA.ROUTINES FROM ...（不推荐，可能影响其他功能）
别依赖 $cfg['Servers'][$i]['AllowRoot'] = false 来防存储过程修改
这个配置只影响 phpMyAdmin 是否允许 root 用户登录，和存储过程编辑毫无关系。哪怕你禁了 root，只要普通用户被授予了 ALTER ROUTINE，照样能改。
- 真正要锁死，得在 MySQL 层执行：
REVOKE ALTER ROUTINE, CREATE ROUTINE ON `db_name`.* FROM 'user'@'host'; - 记得
FLUSH PRIVILEGES;，尤其在直接操作mysql.procs_priv表后 - 如果用户有全局权限（如
GRANT ALL ON *.*），局部REVOKE可能无效——MySQL 权限是叠加生效的，得先REVOKE ALL PRIVILEGES ON *.*再重授最小集
最易忽略的一点：存储过程内部 SQL 是以 DEFINER 身份执行的，所以即使你禁止了用户改过程，他仍可能通过调用已有过程间接读写敏感数据——权限控制必须同时考虑调用者（INVOKER）和定义者（DEFINER）两层逻辑。
