thinkphp的extend目录默认不参与自动加载，因其不在composer.json autoload配置中，需手动注册psr-4命名空间或用require_once引入；import()函数在tp6已彻底移除。
ThinkPHP 的 extend/ 目录默认不参与自动加载，直接放类文件不会被识别——这不是配置漏了，是框架设计如此。
为什么 extend/ 下的类总报 Class not found
因为 ThinkPHP 6+ 完全依赖 Composer 的 PSR-4 加载机制，而 extend/ 不在 composer.json 的 autoload 配置里，也不在框架内置扫描路径中。它只是个“自由存放区”，没有注册命名空间 + 没执行 composer dump-autoload，就等于不存在。
- 常见错误现象：
Class "extendmylibHelper" not found，但文件明明在extend/mylib/Helper.php - 即使写了
namespace extendmylib;，没注册命名空间前缀，Loader 就不会去extend/下找 - 别信“丢进去就能用”，TP5 的
thinkLoader::addNamespace()在 TP6 已废弃，调了也没反应
让 extend/ 类生效的两种可靠方式
必须二选一，不能混用；推荐方式一（标准、可维护）。
-
方式一：走 Composer PSR-4（推荐）
编辑项目根目录的composer.json，在"autoload": {"psr-4": {...}}中加一行："extend\": "extend/"
注意：命名空间末尾双反斜杠\、路径末尾正斜杠/缺一不可
然后运行：composer dump-autoload -o -
方式二：手动 require（适合临时调试）
在要用的地方顶部加：require_once EXTEND_PATH . 'mylib/Helper.php';
或在app/common.php中统一加载：if (is_file($file = EXTEND_PATH . 'mylib/Helper.php')) { require_once $file; }
extend/ 和 app/utils/ 该选哪个放工具类
优先放 app/utils/ 并配 PSR-4，而不是塞进 extend/。
-
app/utils/更符合 ThinkPHP 6+ 的组织习惯，且容易纳入团队协作规范 - 配 PSR-4 后，
new apputilsArrHelper()可直接 new，无需 import 或 require -
extend/本质是为“不改源码也能加功能”准备的，比如临时补丁、私有 SDK 封装，不适合长期维护的业务工具类 - 如果已有大量
extend/类，迁移成本不高：改命名空间（如namespace extendmylib;→namespace apputils;），移动文件到app/utils/，再更新composer.json
import() 还能用吗？
不能。TP6 已移除 import() 函数，调用会报 Call to undefined function import()。
- 它在 TP5.1 就被标记废弃，TP6 彻底删除
- 试图在
common.php里重写import()是徒劳的——Loader 类不再暴露 import 接口 - 如果你看到文档或老代码还在用
import('mylib.Helper')，一律替换成 PSR-4 +new，或改用require_once
最易被忽略的一点：改完 composer.json 后，必须运行 composer dump-autoload -o，否则所有配置都是空谈；而加了 -o 后，Composer 会生成优化 classmap，此时 PSR-4 规则实际失效——开发阶段建议先不加 -o，确认能加载后再加。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
