应将 Composer 的 autoload.php 放在 ThinkPHP base.php 之前加载，以确保其 PSR-4 规则优先生效；对非标准命名空间库，需在 composer.json 中配置 psr-4 映射或手动注册 autoloader；TP6 应避免使用 extend/ 和 thinkLoader，统一通过 Composer 管理自动加载。
Composer autoload 与 ThinkPHP 的 autoloader 冲突怎么办
ThinkPHP 5.1+ 默认使用自己的 thinkLoader，但 Composer 的 vendor/autoload.php 也注册了 PSR-4 和 classmap 自动加载器。两者共存时，若类名重复或路径重叠，class not found 错误常发生在第三方包里调用自身依赖时。
根本解法不是禁用 ThinkPHP 加载器，而是让 Composer 的加载优先级更高——在 public/index.php 中，必须把 require BASE_PATH . '/vendor/autoload.php' 放在 require THINK_PATH . 'base.php' 之前。否则 ThinkPHP 会先注册自己的加载逻辑，后续 Composer 的 PSR-4 规则可能被跳过。
- 错误顺序：
require THINK_PATH . 'base.php';→require BASE_PATH . '/vendor/autoload.php'; - 正确顺序：
require BASE_PATH . '/vendor/autoload.php';→require THINK_PATH . 'base.php'; - ThinkPHP 6+ 默认已按此顺序，但升级项目或手动迁移时极易忽略
如何让 ThinkPHP 正确识别 vendor 下的非标准命名空间
有些第三方库（比如老版本的 aliyun-openapi-php-sdk）没遵循 PSR-4，类文件放在 vendor/aliyun/openapi/ 里，但命名空间却是 Aliyun\OpenApi\，且没有 composer.json 的 autoload 配置。这时候 Composer 不会自动映射，直接 new AliyunOpenApiClient() 就报错。
两种实操路径：
立即学习“PHP免费学习笔记（深入）”；
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 在项目根目录
composer.json的autoload段加psr-4映射："autoload": { "psr-4": { "Aliyun\OpenApi\": "vendor/aliyun/openapi/src/" } }然后运行composer dump-autoload - 更轻量：在
app/common.php或public/index.php顶部用spl_autoload_register手动补漏，例如：spl_autoload_register(function ($class) { if (strpos($class, 'Aliyun\OpenApi\') === 0) { $file = BASE_PATH . '/vendor/aliyun/openapi/src/' . str_replace('\', '/', substr($class, 13)) . '.php'; if (is_file($file)) require_once $file; } });
tp6 使用 composer require 后类不生效的常见原因
执行 composer require guzzlehttp/guzzle 成功，但在控制器里 use GuzzleHttpClient; 却提示 Class 'GuzzleHttpClient' not found，大概率不是加载问题，而是环境或配置偏差。
- 检查 PHP CLI 和 Web Server（如 nginx + php-fpm）是否共用同一份
vendor目录；有时本地composer install在 CLI 下完成，但 Web 进程读的是另一套缓存或旧路径 - 确认
composer.json中"minimum-stability"没设为dev导致某些包被跳过（尤其带-dev后缀的版本） - ThinkPHP 6 的容器绑定机制会拦截部分 new 实例，如果想在服务中注入
GuzzleHttpClient，需在app/provider.php显式绑定：return [ 'GuzzleHttpClient' => GuzzleHttpClient::class, ];否则app()->make('GuzzleHttpClient')会失败
自定义类库放哪里、怎么注册才不被覆盖
很多人把自定义 SDK 放进 extend/ 目录，然后在 app/common.php 里写 Loader::addNamespace('Sdk', EXTEND_PATH . 'sdk/');。这在 TP5 是可行的，但在 TP6 中 extend/ 已废弃，且 thinkLoader 不再推荐直接调用。
标准做法是回归 Composer：
- 新建目录
library/Sdk/，写好命名空间Sdk\和对应类 - 在
composer.json中添加："autoload": { "psr-4": { "Sdk\": "library/Sdk/" } } - 运行
composer dump-autoload -o（加-o生成优化后的 classmap，提升生产环境性能） - 注意：TP6 的
composer.json默认有"autoload-dev"，别误把生产类库配进 dev 段，否则线上composer install --no-dev会漏掉
第三方类库集成最易卡在“谁先加载、谁管命名空间、谁负责实例化”这三个环节，细节顺序比语法更重要。
