ThinkPHP 是类 MVC 框架，非严格三端分离，核心特点是默认不强制分层、路由与控制器强绑定、模板引擎深度内建、运行时动态加载突出。
ThinkPHP 的 App::run() 启动流程和 Laravel 的 Kernel::handle() 本质不同
ThinkPHP 启动后先读取 app.php 配置，再通过 App::run() 进入「模块检测 → 控制器定位 → 方法执行 → 视图渲染」线性链；Laravel 则依赖服务容器和中间件管道，Kernel::handle() 是事件驱动+责任链模式。
这意味着：ThinkPHP 的请求生命周期更短、调试路径更直，但拦截/修改请求的能力弱于 Laravel 的中间件系统。
常见踩坑点：
- 在 ThinkPHP 中试图用中间件做全局请求日志，结果发现
beforeAction钩子只对控制器方法生效，不覆盖静态资源或未注册路由 - 想复用 Laravel 风格的「Request 对象注入」，但 ThinkPHP 默认传参靠
input()或$this->request->param()，没有自动类型绑定
模板引擎不是可选插件，而是 View 类原生组成部分
ThinkPHP 的 View 类直接封装了 fetch()、assign()、display()，且默认使用自研模板语法（支持原生 PHP、变量输出、条件判断、循环、布局继承）。它不像 Django 或 Flask 那样允许自由切换 Jinja2 / Mako / Twig。
实操影响：
- 不能直接用
include 'header.php'，必须写成{:include('header')}，否则被模板编译器忽略 - 开启
'tpl_cache' => true后，模板会编译为 PHP 文件缓存在runtime/view/下，改完模板要清缓存才能生效 - 若强行引入 Twig，需手动重写
think\view\driver\Think类，并替换view_replace_str等配置项，得不偿失
Db::name('user')->where(...)->select() 看似 ActiveRecord，实际是 Query Builder 封装
ThinkPHP 的 Db 类不生成模型实例，返回的是二维数组或 Collection 对象（5.1+），不是 Eloquent 那样的 Active Record 实体。它的 where() 是链式构造 SQL 条件，最终调用 buildSql() 拼接，而非持久化对象状态。
典型表现：
-
$user = Db::name('user')->find(1);返回数组，不是对象，无法调用$user->save() - 想做关联查询，得用
with('profile')（需定义模型）或手写join()，不能像 Rails 那样用user.posts直接访问 - 事务中如果混用
Db::table()和Model::create()，可能因连接实例不同导致事务失效
模块化靠目录约定，而非命名空间自动映射
ThinkPHP 的 app/index/controller/Index.php 被映射为 index/Index/index，这个路径由 Route::rule() 和默认路由规则共同解析，不依赖 PSR-4 自动加载。也就是说，你把控制器放错目录层级，或者没按 app/模块名/controller/类名.php 命名，404 就来了，不会报「Class not found」。
关键细节：
- 多应用模式下，
app/admin和app/api是平行目录，但共用同一套config/，容易误配数据库前缀或缓存驱动 - 关闭「URL 大小写敏感」后，
/Index/index和/index/index都能访问，但 Windows 开发环境可能因文件系统不区分大小写导致部署到 Linux 后 404 -
route_check设为false时，所有请求都进index/index，适合做 SPA 后端统一入口，但会绕过所有路由规则
立即学习“PHP免费学习笔记（深入）”；
ThinkPHP 的设计取舍非常明确：牺牲部分抽象灵活性，换取开发速度和部署简易性。它的「隐式约定」比「显式配置」多，所以出问题时，往往不是语法错，而是某个配置项没对上目录结构或 URL 解析规则。
