ThinkPHP6接入第三方SDK应手动引入extend/目录下的SDK并用EXTEND_PATH常量加载，无命名空间的类需new \ClassName()，有命名空间的需use后实例化，冲突类名应重命名并记录。
ThinkPHP6 接入第三方 SDK，核心就一条：别指望自动加载能兜底，手动路径控制 + 显式引入才是最稳的路。尤其当你用的是百度 AIP、阿里云 AFS、腾讯 COS 这类没 PSR-4 规范、也没 composer.json 的 SDK 时，use 命名空间直接报错是常态。
SDK 放哪？必须放 extend/ 目录下
TP6 的 extend/ 是专为手动物理引入预留的目录，它不参与 Composer 自动加载，但路径稳定、权限可控、无命名空间污染风险。所有非 Composer 安装的 SDK 都应解压后整目录丢进去，比如：
- 百度 NLP SDK →
extend/aipbaidusdk/（确保AipNlp.php在该目录下） - 阿里云 AFS SDK →
extend/aliyun-php-sdk-afs/和extend/aliyun-php-sdk-core/ - 自定义 JSSDK →
extend/share/Jssdk.php（注意命名空间要匹配目录结构）
别放 vendor/ —— 那里是 Composer 管的，手动塞进去会导致 autoload 冲突或被下次 composer update 清掉；也别放 app/ 下——容易和业务代码混在一起，后期迁移或升级时难剥离。
require_once 路径怎么写？认准 EXTEND_PATH 常量
在控制器或服务类里引入时，必须用 require_once 显式加载，且路径要基于 TP6 提供的内置常量 EXTEND_PATH（它恒等于项目根目录下的 extend/），例如：
立即学习“PHP免费学习笔记（深入）”；
require_once EXTEND_PATH . 'aipbaidusdk/AipNlp.php'; require_once EXTEND_PATH . 'aliyun-php-sdk-core/Config.php';
绝对不要写相对路径如 ../extend/... 或硬编码 ./extend/... —— 应用部署结构一变就挂；也别用 __DIR__ 拼接，控制器位置挪动后路径立即失效。用 EXTEND_PATH 是唯一可移植写法。
实例化时类名前面要不要加 \？看 SDK 是否声明命名空间
这是最容易踩坑的地方：如果 SDK 类文件顶部没有 namespace（比如百度 AIP 的 AipNlp.php 就是纯全局类），那必须用 new \AipNlp()，开头的反斜杠不能省。否则 PHP 会默认在当前控制器命名空间（如 app\controller）下找 app\controller\AipNlp，直接报 Class not found。
而像阿里云 SDK 这种带完整命名空间的（如 AlibabaCloud\Client\AlibabaCloud），则必须先 use，再 new AlibabaCloud()，不能加反斜杠。
简单判断方式：
- 打开 SDK 主类文件，看第一行是不是
namespace xxx; - 是 → 用
use+ 不带\实例化 - 否 → 用
new \ClassName()，强制走全局空间
多个 SDK 共存时类名/常量冲突怎么办？
阿里云 SDK 和某些老版 SDK（如早期的 OSS）可能都定义了 DefaultProfile 或 ERROR_REPORTING 这类通用名，导致 Fatal error: Cannot redeclare class。
临时解法有二：
- 在引入前加
error_reporting(0);（仅限调试，不推荐上线） - 更稳妥的是改 SDK 源码：把冲突类名重命名为
AliyunDefaultProfile，并在所有调用处同步替换（搜索整个 SDK 目录里的DefaultProfile）
注意：这类修改必须记录在项目文档里，后续 SDK 升级时得人工合并，不能靠 diff 工具自动覆盖。
真正麻烦的不是“怎么引”，而是“引完之后怎么管”——每个 SDK 的初始化逻辑、配置注入、错误处理风格都不一样，一旦混在控制器里写死，后期维护成本会指数上升。建议把 SDK 实例化封装进 app/service/ 下的独立服务类，并通过依赖注入或工厂方法统一管理生命周期。
