ThinkPHP6.x请求流程由Http::run()驱动，依次初始化应用、绑定Request、进入runWithRequest()；Route::check()返回Dispatch对象才执行控制器及中间件，否则抛RouteNotFoundException；漏return $next($request)将导致响应为空。
ThinkPHP6.x 的一次 HTTP 请求不是“进控制器→出响应”这么简单，关键在「哪个阶段能拿到什么对象」「哪些操作会直接中断流程」。整个流程由 think\Http::run() 驱动，中间任何一环抛异常、返回空或漏掉 $next($request)，都会导致响应为空或 500，但未必报错。
入口文件执行到 Http::run() 发生了什么
所有请求都从 public/index.php 开始，最终调用 think\Http::run()。这一步会做三件确定性的事：初始化应用（加载配置、触发 appInit 事件）、自动创建并绑定 Request 实例到容器、然后进入 runWithRequest() 主流程。注意：Request 对象此时已存在，但它的 param()、input() 还不能可靠取值——因为 URL 解析和路由尚未发生，参数还没被解析进 Request 内部。
- 别在
Http::run()调用前读input()或param()，返回空或默认值 -
appInit事件里可以注册服务、修改配置，但不能依赖Request或Response - 如果启用了多应用模式，
runWithRequest()会先根据域名或 PATH_INFO 决定进入哪个应用目录，再加载对应配置
Route::check() 返回 Dispatch 对象意味着什么
Route::check() 不是布尔判断，它返回一个 think\route\Dispatch 实例（匹配成功）或 null（失败）。这个对象里封装了模块名、控制器类路径、方法名、参数数组、是否 RESTful 等全部调度元信息——后续控制器实例化、中间件注入、方法调用全靠它驱动。一旦返回 null，框架立刻抛出 think\exception\RouteNotFoundException，跳过所有控制器逻辑，直奔异常渲染。
- 闭包路由（如
Route::get('api/user', function(){})）不走控制器自动解析，因此绕过控制器中间件，但全局中间件仍会执行 - 自定义路由里用
allowCrossDomain()设置的响应头，只对当前匹配路由生效，不影响其他路由 - 如果路由规则里写了
['https' => true]但请求是 HTTP，Route::check()直接返回null，不会降级处理
控制器中间件为什么没执行
中间件是否运行，取决于它被注册的位置和调度时机：app/middleware.php 里的全局中间件一定执行；应用级中间件在应用初始化后加载；而控制器/方法级中间件（通过 middleware 属性或注解声明）只有在该控制器被 Dispatch 明确选中、且类文件存在、可实例化时，才会压入执行栈。换句话说：路由匹配失败、控制器类不存在、构造函数抛异常——这些都发生在中间件链启动之前。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
立即学习“PHP免费学习笔记（深入）”；
- 漏写
return $next($request)是最隐蔽的问题：后续中间件和控制器完全不执行，HTTP 响应体为空，无错误提示 - 中间件中调用
$request->withParam('foo', 'bar')会影响控制器里$this->request->param('foo')的结果 - 控制器中间件无法拦截
Route::miss()定义的兜底逻辑，因为它在路由失败后才执行
Response::send() 前还能改响应吗
可以，但仅限于 app_end 钩子内。ThinkPHP6 的响应输出分两步：先生成 Response 对象（含状态码、Header、Content），再调用 send() 真正发给客户端。而 app_end 是最后一个可干预点，它接收 Response 实例作为参数，允许你修改 Header 或 Content——但不能再抛异常、不能重定向、不能修改状态码（底层已 send headers）。
-
app_end里调用$response->header()有效，但调用$response->redirect()会失效，因为 headers 已发送 - 视图渲染（
view或fetch）发生在控制器 return 之后、Response构造之前，所以模板里写的 PHP 代码仍可触发日志或缓存操作 - 如果控制器 return 的是数组，且配置了
default_return_type = 'json'，框架会自动调用Response::json()封装，无需手动 new Response
真正容易被忽略的是：路由匹配和控制器实例化之间没有缓冲层，Dispatch 对象一旦生成，后续所有行为（包括中间件顺序、参数注入、资源路由解析）都由它决定；而这个对象本身，既不校验控制器类是否存在，也不检查方法是否 public——这些检查留到实例化那一刻才做，错误直接崩在中间件之前。
