ThinkPHP 5.1 支持 PSR-4 但需手动配置 composer.json 并执行 composer dump-autoload，不接管注册逻辑；TP6.x 基本符合 PSR-12 但不强制校验；TP5.0 完全不兼容 PSR-7；各版本 PHP 兼容性有明确边界且需实测关键反射与函数行为。
ThinkPHP 5.1 是否支持 PSR-4 自动加载
支持，但需手动配置 composer.json 并执行 composer dump-autoload，框架自身不接管 PSR-4 的注册逻辑。它依赖 Composer 的标准自动加载机制，而非自己实现 spl_autoload_register 的兼容层。
常见错误现象：Class not found 却确认文件路径和命名空间无误——大概率是没跑 composer dump-autoload -o，或 autoload 段未声明 "psr-4" 映射。
- TP5.1 默认的
app目录不自动纳入 PSR-4 加载，需在composer.json中显式添加，例如："autoload": { "psr-4": { "app\": "app/" } } - 控制器、模型等类若放在非默认命名空间（如
domainuserUserService），必须对应目录app/domain/user/UserService.php，且composer.json里要有匹配的映射 - 修改
composer.json后，composer install不会自动重生成 autoload，必须手动触发dump-autoload
ThinkPHP 6.x 的 PSR-12 兼容性表现
TP6.x 的核心代码基本符合 PSR-12，但不强制校验，也不提供内置的代码风格修复工具。它的“合规”是结果导向的——靠人工维护+CI 阶段用 php-cs-fixer 或 phpcbf 补齐。
使用场景：团队启用 PHP-CS-Fixer 时，发现 TP6 的 thinkApp 或 thinkRequest 类被报错，比如多空行、括号换行位置不符——这不是框架 bug，而是 PSR-12 是建议规范，TP6 选择“可读优先”的折中格式。
立即学习“PHP免费学习笔记（深入）”；
- TP6 的
config/下 PHP 返回数组的写法（如return ['app' => ['debug' => true]];）不违反 PSR-12，但若开启array_syntax: short规则，会要求改用[]，而框架源码仍用array() - 方法参数列表超过 4 个时，TP6 倾向于单行书写（如
public function handle($a, $b, $c, $d)），PSR-12 推荐每参数一行，但框架未强制 - 不要指望
think:vendor:publish或think:swoole这类命令输出的代码模板自动符合 PSR-12，它们只是功能脚手架，格式由开发者后续统一处理
TP5.0 与 PSR-7 的实际脱节点
TP5.0 完全不兼容 PSR-7，它的 Request 和 Response 是自研对象，没有实现 PsrHttpMessageRequestInterface 等接口。强行桥接需额外封装，且无法用于标准中间件栈（如 relay/ringphp）。
错误现象：试图把 TP5.0 的 thinkRequest 直接传给一个依赖 PsrHttpMessageServerRequestInterface 的日志组件，会抛出 TypeError。
- TP5.0 的
input()、param()、file()等方法返回的是数组或thinkFile实例，不是 PSR-7 的UploadedFileInterface - 响应输出靠
Response::send()直接 echo/header，不返回PsrHttpMessageResponseInterface，因此无法参与zendframework/zend-stratigility这类管道式中间件流程 - 升级到 TP6 才有原生 PSR-7 支持（通过
thinkResponse实现接口），但注意 TP6 默认仍用传统模式，需在config/app.php开启'response_type' => 'json'等配置才会走 PSR-7 路径
PHP 版本与 ThinkPHP 各版的最小兼容边界
TP6.3 要求 PHP >= 7.2，但实际运行在 PHP 8.1+ 时，部分反射调用（如 ReflectionParameter::getType()）行为变化会导致扩展类（如某些第三方验证器）失效；TP5.1 在 PHP 8.0 下 strpos 返回 null 的严格检查可能暴露隐式类型转换漏洞。
性能影响：PHP 8.0+ 的 JIT 对 ThinkPHP 应用收益极小，因为框架大量使用动态调用（call_user_func_array、魔术方法），JIT 无法有效优化；但属性类型声明（PHP 7.4+）能让 IDE 和静态分析更准，TP6.3 已在核心类中逐步补全。
- TP5.0 最高只测到 PHP 7.3，PHP 7.4 的
arrow function和typed property在框架内不可用，业务代码可用，但别在common.php或行为类里用，否则低版本环境直接 parse error - TP6.0–6.2 在 PHP 8.1 下运行正常，但若用了
#[Attribute]自定义注解，需确认是否与框架的thinknnotationAnnotation冲突——两者机制不同，不能混用 - 不要仅看官方文档写的“支持 PHP 8.x”，要实测
vendor/topthink/framework/src/think/App.php中涉及gettype()、is_callable()、func_get_args()的地方，这些在 PHP 8 里语义有微调
composer dump-autoload 和 php-cs-fixer fix。 
