class not found 是 autoload 未生效，需先验证 class_exists() 返回 true：检查文件路径与命名空间是否严格匹配（如 app/service/userservice.php 和 namespace app\service;），执行 php think optimize:autoload 刷新映射，再确认控制器是否被容器接管或改用方法参数注入。
Class not found 是 autoload 没生效，不是容器坏了
ThinkPHP 8 报 Class not found 或 ReflectionException，90% 的情况跟容器配置无关，而是 class_exists('app\service\UserService') 返回 false。容器连类都加载不出来，自然没法反射、绑定、注入。
必须按顺序验证：
- 文件路径是否为
app/service/UserService.php（注意斜杠方向、大小写） - 文件首行
namespace是否严格为namespace app\service;（末尾分号不能少，反斜杠不能错） - 执行
php think optimize:autoload刷新 Composer 映射（改过路径或命名空间后这步必做） - 在命令行运行
php -a，输入var_dump(class_exists('app\service\UserService'));确认返回true
控制器构造函数不走容器，别白写 UserService $service
TP8 默认用 new Index() 实例化控制器，完全绕过容器反射机制。你写的 public function __construct(UserService $service) 根本不会被调用，参数永远不会注入，属性永远是 null。
有三个可行解法，按推荐度排序：
- 改用方法参数注入：
public function index(UserService $service)—— 路由层自动解析，无需额外配置，兼容性最好 - 启用容器接管控制器：在
app/provider.php的providers数组中加入控制器全类名，如app\controller\Index::class - 删掉
__construct()，改用initialize()做初始化（但别在里面手动app()->make()，会破坏可测试性）
接口注入失败，是因为没 bind，不是“框架不支持”
写 public function __construct(UserRepositoryInterface $repo) 却报错？不是 PHP 不支持，是容器根本不知道 UserRepositoryInterface 应该对应哪个实现类。TP8 不会猜，也不会自动扫描实现类。
必须显式绑定，且必须用完整限定名：
- 在
app/provider.php中添加映射：'app\repository\UserRepositoryInterface' => 'app\repository\DbUserRepository' - 如果实现类依赖其他服务（比如
DbUserRepository构造函数要Connection），那Connection也得能被容器 resolve 出来，否则整条链断裂 - 第三方接口（如
PSR\Log\LoggerInterface）也要绑定，不能只靠monolog/logger自动注册——TP8 不默认预绑非核心接口
TP6 升级到 TP8 后实例化失败，大概率是命名空间或大小写错了
TP6 对命名空间容忍度高，TP8 严格依赖 PSR-4 自动加载。升级后常见错误不是逻辑问题，而是硬性规范不满足：
- 控制器文件
app/controller/IndexController.php必须以namespace app\controller;开头，类名必须严格匹配文件名（IndexController≠indexcontroller） - 多应用下子目录（如
app/admin）必须有独立的config/和route/目录，且app_multi配置必须设为true，multi.php文件已失效 - 所有框架类（
think\App、think\Db）现在全由 Composer 加载，删掉任何require_once 'thinkphp/library/think/...'类硬引用
Linux 下大小写敏感问题最容易被忽略——开发时没问题，上线就报 Class not found，务必在部署前用真实环境跑一次 class_exists() 校验。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
