thinkphp6本身不管理数据库用户权限，仅通过配置文件（如database.php或.env）传递账号密码连接数据库；真正的表级、操作级权限由mysql等服务端控制，需手动执行grant语句授权，并注意ip匹配、字符集一致性及读写分离账号最小权限原则。
ThinkPHP 本身不管理数据库用户的权限，它只用你给的账号密码连上去；真正控制“能查哪些表”“能不能删数据”的，是 MySQL/PostgreSQL 这类数据库服务端自身的用户权限体系。框架里写的 database.php 配置，只是告诉 TP6 “用哪个账号去连”，不是“让这个账号拥有什么权限”。
MySQL 用户权限必须手动在数据库里配，不是写在 TP6 配置里
很多人卡在“TP6 报错 Access denied for user”，第一反应是去改 database.php，其实问题出在 MySQL 侧：
- TP6 的
database.php只负责传参：比如'username' => 'app_user'，它不会帮你创建这个用户，也不会自动授予权限 - 你得登录 MySQL（用 root 或有 GRANT 权限的账号），手动执行
GRANT语句，例如：GRANT SELECT, INSERT, UPDATE ON `myapp_db`.* TO 'app_user'@'localhost';
- 别漏掉
FLUSH PRIVILEGES;，否则权限不生效 - 如果 TP6 部署在 Docker 或远程服务器，注意
'app_user'@'%'和'app_user'@'172.18.0.3'是不同用户，IP 必须匹配
TP6 的 database.php 配置要避开这几个坑
database.php 不是权限配置文件，但写错会导致连接失败，被误判为“没权限”：
- 别把密码写死在
database.php里，用env('database.password')从.env读取——否则部署到测试环境时容易复用生产库密码 -
'charset'必须和数据库实际编码一致，比如 MySQL 8.0 默认utf8mb4_0900_as_cs，但 TP6 的'charset' => 'utf8mb4'仍可连，只是排序规则不生效；如需严格匹配，得加'collation' => 'utf8mb4_0900_as_cs' -
'deploy' => 1开启读写分离时，'read' => [...]和'write' => [...]里的账号必须各自拥有对应库的最小权限（比如只读账号不能有DROP） - 使用 PDO 的
ATTR_EMULATE_PREPARES => false（TP6 默认开启）时，MySQL 用户需有EXECUTE权限（极少人知道，但某些存储过程调用会因此报错）
敏感操作要靠应用层权限控制，不是靠数据库账号隔离
想限制“普通用户不能删订单”，不能靠给它一个只读数据库账号——那样连自己订单都查不了。真实做法是：
- 所有接口统一用一个具备完整 CRUD 权限的数据库账号（如
app_rw） - 删订单前，在控制器里调用
PermissionService::check($user, 'admin/order/delete')，走 RBAC 校验 - 数据库账号权限只做兜底：比如禁止应用账号执行
DROP TABLE、SHOW DATABASES，防 SQL 注入逃逸 - 如果真要数据级隔离（如客服只能看本部门订单），靠关联表里的
scope_type/scope_id字段 + 查询时自动追加 where 条件，而不是靠多个数据库账号
最常被忽略的一点：数据库账号权限和应用逻辑权限是两层事。前者管“能不能连、能不能执行某类语句”，后者管“当前用户在这个请求上下文中能不能做这件事”。混淆这两者，轻则反复调试连不上库，重则用只读账号硬扛写操作，最后发现事务根本提交不了。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
