ThinkPHP本身不管理数据库账号权限，仅传递配置；真实权限由MySQL服务端控制，需手动GRANT授权并遵循最小权限原则，同时应用层须配合RBAC与数据范围过滤实现双重防护。
数据库账号权限过大等于给攻击者配钥匙
ThinkPHP 本身不控制数据库账号能做什么，它只负责把 database.php 或 .env 里填的账号密码传给 PDO。一旦连接成功，后续所有 SQL 操作——包括 DROP TABLE、TRUNCATE、SELECT * FROM mysql.user——都由 MySQL 服务端按该账号的实际权限放行。如果这个账号是 root 或被授予了 ALL PRIVILEGES，那一个 SQL 注入漏洞、一次配置文件泄露、甚至一段写错的 Db::execute() 就可能直接清空整库。
TP6 报 Access denied 不一定是账号密码错
很多开发者看到 Access denied for user 'app_user'@'172.18.0.3' 就猛改 database.php，其实问题常出在 MySQL 授权语句没执行或 IP 不匹配：
-
GRANT SELECT, INSERT, UPDATE ON `myapp_db`.* TO 'app_user'@'172.18.0.3'—— Docker 容器内 PHP 进程的 IP 是固定的，@'%'在某些网络模式下不生效 - 执行完
GRANT必须跟FLUSH PRIVILEGES，否则权限缓存不更新 - MySQL 8.0+ 默认密码认证插件是
caching_sha2_password，而旧版 PDO 可能不兼容，需显式指定'auth_plugin' => 'mysql_native_password'
读写分离时，read 和 write 账号权限必须严格区分
开启 'deploy' => 1 后，TP6 会分别使用 read 和 write 配置里的账号。但很多人只配了连接参数，忘了权限隔离：
-
read_user只应有SELECT权限，且不能跨库（比如禁止查information_schema） -
write_user虽需INSERT/UPDATE/DELETE，但应禁用DROP、ALTER、CREATE等 DDL 权限 - 若用了存储过程或函数调用，PDO 设置
ATTR_EMULATE_PREPARES => false（TP6 默认开启）时，账号还需EXECUTE权限，否则报错HY000: No database selected或权限拒绝
数据权限不能靠数据库账号隔离
想让普通用户“只能删自己的订单”，不是给它一个只读数据库账号就完事——那样连自己订单都查不了。真实做法是：
立即学习“PHP免费学习笔记（深入）”；
- 所有接口统一用一个具备完整 CRUD 权限的账号（如
app_rw） - 删订单前，在 Service 层调用
PermissionService::check($user, 'admin/order/delete:own')，走 RBAC + 数据上下文校验 - 查询时通过
$this->getDataScopeWhere()动态拼WHERE条件，而不是依赖账号权限过滤数据
数据库账号最小权限，防的是代码层漏洞被放大；应用层数据权限，防的是业务逻辑越权。两者缺一不可，但作用层面完全不同。
