Linux下Class not found主因是大小写敏感：类名UserModel必须对应UserModel.php且命名空间appmodel与路径app/Model严格一致；需执行composer dump-autoload -o更新映射，并清OPcache或重启PHP-FPM。
Linux服务器上类名大小写不匹配直接触发Class not found
本地Windows/macOS开发时文件系统不区分大小写，UserModel类放在usermodel.php或UserModel.php都能加载成功；一到线上Linux服务器，class UserModel定义在app/Model/usermodel.php里，就会彻底找不到——因为PSR-4自动加载严格按命名空间+类名拼路径，而Linux文件系统拒绝匹配。
常见错误现象：Fatal error: Class 'appmodelUserModel' not found，但你确认文件存在、命名空间也写了namespace appmodel;。
- 用
ls -l app/Model/看真实文件名，不是靠编辑器“重命名”假象 - 类名首字母必须大写，对应文件名也必须首字母大写：
UserModel→UserModel.php，不能是usermodel.php或user_model.php - 命名空间里的目录名也要小写一致：如果类在
app/model/UserModel.php，命名空间就得是appmodel（反斜杠双写为app\model），不能写成AppModel或appModel
composer dump-autoload没跑或没生效
改完类名、挪了文件、加了新目录，只改composer.json是没用的。vendor/composer/autoload_classmap.php和autoload_psr4.php不会自动更新，线上环境尤其容易漏这步。
使用场景：Git拉代码后直接php think run或刷新页面，报错说类找不到，但git status显示一切正常。
立即学习“PHP免费学习笔记（深入）”；
- 进项目根目录执行
composer dump-autoload -o（-o生成优化版映射，必须加） - 检查
vendor/composer/autoload_psr4.php里有没有你新增的命名空间映射项，例如'app\model\' => ['app/Model/'] - 如果用了Docker，确认
composer install或dump-autoload是在容器内执行的，不是宿主机上跑的
OPcache缓存了旧的自动加载映射
PHP启用OPcache后，autoload_*.php文件被编译进共享内存，即使你重新dump-autoload，只要OPcache没清，就还在用旧映射——这就导致“明明改对了，还是报错”。
性能影响不大，但排查成本极高：你反复验证路径、命名空间、大小写，全都没问题，就是不加载。
- 临时解决：在入口文件
public/index.php开头加opcache_reset();（仅限调试，上线前删掉） - 正式方案：重启PHP-FPM进程（
sudo systemctl restart php*-fpm）或清空OPcache（php -r 'opcache_reset();'） - 检查
php.ini里opcache.validate_timestamps=0是否开启——若开启，必须手动重置，否则改了文件也不生效
CLI和Web环境加载路径不一致
你在命令行跑php think optimize:schema成功，但浏览器访问就Class not found，大概率是两个环境读的不是同一份composer.json或autoload配置。
原因：Web服务器（如Nginx）用的是www-data用户，CLI可能是你自己的用户，两者getcwd()不同、include_path不同、甚至PHP配置文件都不同。
- 在Web入口加
echo getcwd() . " "; die();，对比CLI下pwd输出 - 在Web入口打印
print_r(get_include_path());，确认vendor/autoload.php路径是否真能被找到 - 检查
phpinfo()里Loaded Configuration File路径，确认Web和CLI用的是同一个php.ini
