ThinkPHP企业级开发完整指南-ThinkPHP-PHP中文网

企业级开发核心是控边界、管生命周期、防耦合；thinkphp 8 多应用需手动拆分、显式配置、动态隔离，避免路由污染、配置共享、缓存冲突与权限硬编码。

thinkphp企业级开发完整指南

企业级开发不是堆功能，而是控边界、管生命周期、防耦合。ThinkPHP能做到，但默认配置和目录结构不直接满足——必须手动拆、主动配、提前压。

ThinkPHP 8 的 multi-app 不是“开箱即用”的隔离，而是目录物理隔离 + 手动映射的组合。一旦漏掉关键配置，admin 应用就可能读到 api 的数据库配置，或共享同一个缓存前缀导致键冲突。

入口文件必须独立：每个应用（如 admin.php、api.php）需调用 think\App::init() 并传入对应应用名，不能共用 index.php
配置继承要显式切断：在 config/api/database.php 中，不要只写新增字段，必须用 array_merge(include '../config/database.php', [...]) 显式合并基础配置，否则会丢失 default 连接定义
缓存前缀必须动态化：在各应用专属配置中设 'prefix' => env('APP_NAME', 'default')，否则 Redis 中 cache:menu 在 admin 和 api 下会互相覆盖
路由文件不自动加载：route/api.php 不会被自动识别，需在 app/api/RouteService.php 中重写 register() 方法，手动加载该文件

用 Auth 扩展或 bjyadmin 的角色表只能解决“谁有权限”，但企业场景常需“谁在什么条件下能访问什么资源”。比如：销售总监可编辑订单，但仅限自己团队的；运维可重启服务，但禁止在工作日 9:00–18:00 操作。

ThinkPHP5.1企业站点快速开发

下载

中间件中不查 auth_rules 表就放行：应解析请求上下文（$request->param('order_id')、$request->ip()、date('w')），再拼装查询条件
权限元数据必须支持表达式字段：在 auth_rules 表中加 condition 字段（TEXT 类型），存 PHP 表达式字符串，如 "user.team_id == resource.team_id"，运行时用 eval()（需严格白名单校验）或预编译为闭包
拒绝响应不能只返回 403：应统一返回 ['code'=>403, 'message'=>'操作受限：非本团队订单']，前端据此提示具体原因，而不是笼统“无权限”

常见错误是把订单创建、库存扣减、消息通知全塞进 OrderController::create()，导致测试难、复用差、事务边界模糊。ThinkPHP 的模型不是 ORM 映射器，而是业务聚合根载体。

控制器只负责协议转换：接收参数 → 校验格式 → 调用 OrderService::place($data) → 返回结果，不碰 DB 或事务
服务类（app/service/OrderService.php）才封装完整用例：内建 Db::transaction()、调用 StockModel::decrease()、触发 event('order.placed')
模型专注数据契约：一个 OrderModel 只定义字段、验证规则、关联关系；复杂计算（如满减优惠）抽成 app/contract/DiscountCalculator.php，由服务类注入使用
禁止在模型中调用 Cache::get() 或 Mail::send()：这些属于基础设施层，应通过依赖注入传入接口（如 CacheInterface），方便单元测试 mock

本地跑通 ≠ 线上可用。ThinkPHP 默认的调试配置在生产环境会引发严重问题，而某些关键开关根本不在 .env 里暴露。

app_debug 必须关：它不仅显示错误堆栈，还会开启模板编译缓存自动刷新，高并发下大量写磁盘导致 502
log.level 不能设 debug：生产环境日志量爆炸，尤其开启 SQL 日志后，单次请求日志可达 2MB，迅速撑爆磁盘
cache.type 别用 file：分布式部署时，各节点缓存不同步，用户登录后在 A 节点看到菜单，在 B 节点 404；必须强制设为 redis 并配置统一连接池
app_host 要显式声明：Nginx 反向代理后，Request::domain() 可能返回 localhost，导致生成的绝对 URL 错误；应在 config/app.php 中写死 'app_host' => 'https://api.example.com'