ThinkPHP各版本PSR支持深度不同：5.1仅基础遵循PSR-2/4；6.0强制Composer、严格PSR-4路径映射并稳定兼容PSR-3；8.x全面支持PSR-3/7/11/15/16/17/18七项规范，底层重构实现契约化。
想快速判断一个ThinkPHP项目是否符合现代PHP工程标准，得先看清它对PSR规范的支持深度和版本兼容性，而不是只看表面功能堆砌。
ThinkPHP各版本对PSR规范的覆盖差异
ThinkPHP5.1开始明确遵循PSR-2命名规范与PSR-4自动加载规范，这是最低准入门槛；到ThinkPHP6.0，已强制要求通过Composer安装，且目录结构、类名、文件名全部按PSR-4路径映射规则落地——比如appcontrollerUserController必须对应app/controller/UserController.php，否则自动加载直接失败。
ThinkPHP8.x则全面拥抱PSR-3日志、PSR-7 HTTP消息、PSR-11容器、PSR-15处理器、PSR-16缓存、PSR-17工厂、PSR-18客户端等七项核心规范，底层重构后所有中间件、路由、HTTP响应都基于PSR接口契约实现。
不满足PSR-4路径映射会导致Class not found错误，且无法被Composer自动识别——这一步出错，后续所有依赖注入和Facade调用都会中断。
立即学习“PHP免费学习笔记（深入）”；
为什么PSR-4自动加载是ThinkPHP项目启动的前提
方法一：确认composer.json中autoload段落是否包含"psr-4": {"app\": "app/"}这类映射。没有这条，框架连控制器都找不到。
方法二：运行composer dump-autoload -o强制刷新类映射缓存。如果项目刚迁移或手动改过命名空间，旧缓存会残留错误路径，导致类加载跳转到不存在的文件。
【必须确保vendor/autoload.php被入口文件index.php正确引入】——漏掉这一行，整个PSR-4机制就形同虚设，哪怕配置全对也白搭。
PSR-3日志规范在ThinkPHP中的实际体现
第一步：查看config/log.php是否启用'type' => 'file'或'type' => 'trace'，且驱动类继承自PsrLogLoggerInterface。
第二步：在控制器里调用thinkLog::info('user login')，观察日志内容是否包含标准字段：timestamp、level、message、context四元组。缺任何一个，就不算真正兼容PSR-3。
第三步：检查日志输出格式是否为JSON或结构化文本。若仍是纯文本堆叠（如“[2026-08-06 12:16] INFO: user login”），说明未启用PSR-3适配器，只是框架自有日志模块的简单封装。
PSR-3不要求具体输出格式，但强制规定方法签名必须为log($level, $message, array $context = [])——ThinkPHP8.x已完全照此实现，而5.1仅部分支持，6.0起才稳定达标。
PSR-15中间件如何改变请求生命周期
ThinkPHP6.0引入PSR-15中间件后，所有中间件必须实现PsrHttpServerMiddlewareInterface，其process()方法接收ServerRequestInterface和RequestHandlerInterface两个参数。
旧版中间件（如5.1的handle($request, Closure $next)）在6.0+中会被自动包装，但无法参与原生PSR-15管道调度——这意味着你写的JWT校验中间件若没重写为PSR-15接口，就无法被Swoole协程环境正确识别。
方法一：新建中间件类，use PsrHttpServerMiddlewareInterface，实现process()方法，返回ResponseInterface实例。
方法二：直接使用框架内置中间件如thinkmiddlewareAllowCrossDomain，它已按PSR-15标准重写，可无缝接入任何PSR-7兼容服务器。
