为什么ThinkPHP必须限制数据库用户的写入权限【安全】

说到ThinkPHP的数据库权限，很多人容易搞混一点：TP本身并不管理用户权限，它只是个传话的。真正的权限控制全在MySQL服务端，得靠手动执行GRANT语句来配，而且IP得对得上，还得刷新缓存。最小权限原则和应用层的RBAC校验，缺一不可。

ThinkPHP本身不控制数据库账号权限，只负责传参

在实际调试中，遇到“Access denied for user”的错误提示，很多人第一反应就是去翻database.php或.env文件，改来改去还是连不上。其实思路错了：ThinkPHP从来不会主动创建用户或授予权限，它只是把你在配置里写的username和password原封不动地传给PDO去连接MySQL。真正决定你能不能删表、能不能查密码字段的，是MySQL服务端的GRANT规则。

也就是说，database.php里写的'username' => 'app_user'，只是告诉TP6“用这个账号去连”，而不是“让这个账号拥有什么权限”。权限必须手动在MySQL里配，而且得匹配连接来源IP——写错一个IP段，权限就白配了。

为什么不能用 root 或全库权限账号

root账号一旦泄露——比如配置文件误传到GitHub、日志里打印了密码、备份文件被下载——攻击者就能直接DROP DATABASE、导出所有表、甚至写入恶意存储过程。最小权限原则不是为了“以防万一”，而是给代码出bug时留一个兜底方案：

• 前台页面只读数据 → 只给SELECT权限，且限定到shop_db.*，禁用跨库查询
• 用户提交订单 → 额外加INSERT到orders表，不给UPDATE或DELETE
• 后台编辑商品 → 再开放UPDATE，但限制WHERE条件（比如WHERE status != 'deleted'）
• 绝对不授GRANT OPTION、ALTER、DROP、CREATE USER这类高危权限

TP6默认开启PDO::ATTR_EMULATE_PREPARES => false，某些存储过程调用还需要EXECUTE权限——这点极少人注意，但漏了就会报错。

读写分离账号必须各自最小化

开启'deploy' => 1后，TP6会分别用'read'和'write'数组里的账号连接。这时候容易犯两个错：

• 把同一个账号同时填进read和write → 失去隔离意义，读账号也能删数据
• 读账号仍保留DELETE权限 → 某个接口误用读连接执行删除，权限检查形同虚设

正确做法是：读账号只给SELECT，写账号按需给INSERT/UPDATE/DELETE，两张账号的GRANT语句要分开执行，IP白名单也得对应——比如写账号只允许来自应用服务器内网IP，读账号可放宽到缓存集群。

应用层权限和数据库权限不是一回事

有人想靠“给普通用户配只读数据库账号”来防止删订单，这是典型误解。那样用户连自己订单都查不了——因为订单列表页需要JOIN用户表、状态表等，而只读账号没权限查关联表。

真实做法是：所有接口统一用一个具备完整CRUD权限的账号（比如app_rw），删操作前在PHP层调用PermissionService::check($user, 'admin/order/delete')做RBAC校验。数据库权限只防“意外越权”，不替代业务逻辑校验。

最常被忽略的一点：MySQL的权限生效依赖FLUSH PRIVILEGES;。GRANT执行完不刷缓存，新权限就永远不会生效——这比写错SQL更隐蔽，也更难排查。