ThinkPHP本身不管理数据库用户权限，仅传递账号密码连接数据库；真正权限由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。
为什么不能用 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 权限——这点极少人注意，但漏了就会报错。
立即学习“PHP免费学习笔记（深入）”；
读写分离账号必须各自最小化
开启 '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 更隐蔽，也更难排查。
