ThinkPHP企业级开发需从首行代码起严格管控边界、生命周期与耦合；默认配置仅适用于演示，生产环境必须独立初始化多应用入口，显式调用think\App::init()并传入应用名。
ThinkPHP 企业级开发不是“能跑就行”，而是必须从第一行代码就控住边界、管住生命周期、防住耦合。默认安装结构和配置只适合演示，直接用于生产项目等于埋雷——路由污染、缓存键冲突、权限硬编码、事务裸奔，都是高频踩坑点。
多应用入口文件必须独立初始化
常见错误现象：admin.php 和 api.php 共用 index.php，结果 admin 应用读到 api 的数据库配置，或中间件错乱执行。
必须显式调用 think\App::init() 并传入应用名：
// public/admin.php
<?php
// ...
$app = new think\App();
$app->init('admin'); // 关键：指定应用名
$app->run()->send();
- 每个应用（
admin、api、web）必须有专属入口文件 -
init()不只是命名，它会触发对应app/admin/下的配置加载与服务注册 - 漏掉这步，
config/admin/database.php将不会被加载，框架回退到全局配置
配置继承不能靠“覆盖”，必须显式合并
使用场景：为 api 应用单独配从库，但又不想重复写 host、port、charset 等通用字段。
错误写法：config/api/database.php 只写新增连接，不包含 default 定义 → 导致 Db::connect('default') 报错“未定义连接”。
立即学习“PHP免费学习笔记（深入）”；
正确做法：显式引入基础配置并合并：
// config/api/database.php
return array_merge(
include '../config/database.php', // 基础配置（含 default 连接定义）
[
'connections' => [
'api_slave' => [
'type' => 'mysql',
'hostname' => '192.168.1.100',
'database' => 'api_readonly'
]
]
]
);
- 不写
array_merge()，框架不会自动“叠加”配置，只会用子目录下文件的完整内容替换 - 环境变量（如
env('APP_NAME')）在配置加载时已解析，可安全用于动态值 - 所有应用专属配置都应走此模式，避免遗漏关键字段
缓存前缀必须绑定应用名，否则 Redis 键全乱
性能 / 兼容性影响：多个应用共用 cache:menu 这类键，会导致 admin 刷新菜单后 api 接口拿到脏数据，且无法定位来源。
在各应用专属配置中设置动态前缀：
// config/admin/cache.php
return [
'default' => [
'type' => 'redis',
'prefix' => env('APP_NAME', 'admin') . ':', // 关键：加冒号分隔
],
];
-
env('APP_NAME')需在对应入口文件（如admin.php）中提前设置，例如putenv('APP_NAME=admin'); - 前缀末尾加
:是约定，避免adminmenu和admin_menu冲突 - Redis 中实际键变为
admin:menu、api:order_list，彻底隔离
权限中间件里不做 ABAC 动态校验，等于没权限控制
常见错误现象：中间件里只查 auth_rules 表的 role_id 和 path，放行后才发现用户能编辑别人团队的订单。
ABAC 要求运行时解析上下文：
- 从请求中提取资源标识：
$request->param('order_id') - 获取当前用户上下文：
Auth::user()->team_id - 拼装查询条件：
['order_id' => $orderId, 'team_id' => $userTeamId] - 拒绝响应必须带具体原因：
['code'=>403, 'message'=>'操作受限：非本团队订单']
关键点：权限元数据表（auth_rules）需含 condition 字段存表达式字符串（如 "user.team_id == resource.team_id"），运行时白名单校验后 eval() 或预编译为闭包执行——硬编码 RBAC 在企业场景下基本失效。
array_merge、在入口设 putenv、给每张权限表加 condition 字段。企业级不是功能多，是每个环节都得有人盯着边界。 
