GRANT和REVOKE是数据库SQL命令，非PHP函数；PHP应用应使用DBA预置的最小权限专用账号连接，禁止在PHP中执行GRANT，因其需GRANT OPTION权限、易被注入滥用、云数据库屏蔽且无法可靠刷新权限，权限变更后已建连接不会感知，须通过服务重启生效。
GRANT 和 REVOKE 不是 PHP 函数，而是数据库层面的 SQL 命令。PHP 应用本身不“管理”数据库用户权限，它只使用已配置好的数据库账户连接并操作数据。真正该由 DBA 或部署脚本在 MySQL/PostgreSQL 启动后执行的是这些命令。
为什么不能在 PHP 里用 mysqli_query() 执行 GRANT
大多数生产环境的数据库用户（比如 'php_app'@'192.168.10.5'）被明确禁止拥有 GRANT OPTION 权限。这是硬性安全限制：
- MySQL 默认关闭普通用户的
GRANT权限，除非显式授予WITH GRANT OPTION - 即使开了，PHP 进程若被注入或泄露，攻击者就能动态创建高权账号
-
GRANT语句需要重新加载权限表（FLUSH PRIVILEGES），PHP 没法可靠触发 - 云数据库（如阿里云 RDS、AWS RDS）直接屏蔽所有
GRANT类语句
PHP 应用该用哪个数据库用户连接
应用代码里使用的数据库账号，必须是提前由运维/DBA 创建并授权的专用账号，不是 root，也不是开发本地账号。
- 创建账号时指定可信主机：
CREATE USER 'webapp'@'10.0.2.15' IDENTIFIED BY 'strong_pass_2026'; - 只授业务所需最小权限：
GRANT SELECT, INSERT, UPDATE ON mydb.posts TO 'webapp'@'10.0.2.15'; - 绝不授予
DROP、CREATE USER、FILE、PROCESS等危险权限 - 密码通过环境变量注入，而非写死在
config.php中：getenv('DB_PASSWORD')
权限变更后 PHP 怎么感知不到？
PHP 不会自动感知数据库权限变更——它只依赖连接时认证成功的那个账号的当前权限快照。一旦连接建立，后续所有查询都按该会话权限执行，哪怕 DBA 同时在另一终端 REVOKE DELETE ON mydb.users FROM 'webapp'@'%';，已存在的 PHP 连接仍能删数据，直到连接断开重连。
- 长连接（如 PHP-FPM 的 persistent MySQL 连接）风险更高，权限变更完全不可见
- 连接池（如 ProxySQL）也缓存权限元信息，需手动刷新或重启
- 唯一可靠方式：让应用在每次关键操作前，用最小权限账号重连做一次探针查询（不推荐）；更现实的做法是把权限变更纳入发布流程，配合服务滚动重启
常见错误：把应用权限和数据库用户权限混为一谈
开发者常犯的错，是以为给 PHP 的 $_SESSION['role'] = 'admin' 就等于给了数据库 GRANT ALL —— 完全不是一回事。
立即学习“PHP免费学习笔记（深入）”；
-
$_SESSION['permissions']控制的是“能不能调用deleteUser()这个 PHP 方法” - 而数据库用户权限控制的是“这个 PHP 方法内部执行的
DELETE FROM users能不能成功” - 前者防逻辑越权，后者防数据层越权；两者缺一不可，但作用域完全不同
- 最危险的情况：PHP 权限校验被绕过（如 URL 改 ID），而数据库账号又有
DELETE全局权限 → 直接删库
webapp 用户，对 logs 表只有 INSERT，对 users 表只有 SELECT，对 config 表完全不可见——这种约束靠 PHP 代码根本无法模拟，只能靠 GRANT 在数据库侧钉死。 
