Class not found 错误根源在于自动加载机制失效，而非 phpEnv 工具本身；需重点检查 vendor/autoload.php 是否被正确引入、Composer 自动加载映射是否更新、命名空间与文件路径是否严格匹配（含大小写），并排除不可见字符等隐性问题。
phpEnv 本身不解决 Class not found 错误——它只是个 PHP 多版本切换工具，不干预自动加载逻辑。真正起作用的，还是你项目里那套 Composer 配置、命名空间路径和 vendor/autoload.php 的引入方式。
确认 phpEnv 是否影响了 autoloader 路径解析
phpEnv 切换 PHP 版本时，不会重写或覆盖你的项目文件，但它可能间接导致问题：
- 如果你在不同 PHP 版本下执行
composer install（比如用 phpEnv 切到 8.1 装依赖，却用 8.2 运行），而vendor/autoload.php里有版本相关逻辑（如某些插件生成的 classmap），就可能加载失败 - phpEnv 启动的 CLI 环境中，
getcwd()可能不是你预期的项目根目录，导致require __DIR__ . '/vendor/autoload.php'找错位置 - 某些 phpEnv 封装脚本会修改
include_path，干扰 PSR-4 映射查找（极少见，但php -i | grep include_path可验证）
检查 vendor/autoload.php 是否被正确 require
这是最常被跳过的一步，尤其在 phpEnv 环境下容易忽略：
- 入口脚本（如
index.php或测试用的test.php）顶部必须有require __DIR__ . '/vendor/autoload.php';，不能是include，也不能漏掉 - 如果脚本不在项目根目录（比如放在
public/下），__DIR__指向的是public/，此时应写成require dirname(__DIR__) . '/vendor/autoload.php'; - 用
php -d display_errors=1 -f public/index.php直接运行，看是否报failed to open stream—— 那就是路径错了
运行 composer dump-autoload -o 后仍报错？检查映射是否生效
phpEnv 不改变 Composer 行为，但你要确认映射确实写进去了：
立即学习“PHP免费学习笔记（深入）”；
- 执行
composer dump-autoload -v（加-v查看详细输出），确认终端打印出类似Generated autoload files...且列出你新增的命名空间 - 打开
vendor/composer/autoload_psr4.php，手动搜索你的命名空间前缀（如'App\' => array('app')），确认键值对存在且无全角空格或 BOM - Linux/macOS 下检查文件名大小写：哪怕
git status显示文件已提交，ls app/Controllers/UserController.php也可能返回空——因为实际文件名是usercontroller.php，系统找不到
ThinkPHP 或 Laravel 在 phpEnv 下的特殊注意点
框架自带的类注册机制（非 Composer）可能和 phpEnv 共存时失效：
- ThinkPHP 的
Loader::addNamespace()是运行时注册，不写入vendor/autoload.php；若你用 phpEnv 启动 CLI 命令（如php think make:controller），但没加载框架引导文件，这个注册就不存在 - Laravel 的
bootstrap/app.php里$app->register()的服务提供者，如果类路径写死相对路径（如../app/Providers/CustomProvider.php），在 phpEnv 切换版本后，getcwd()变化可能导致 require 失败 - 所有框架 runtime 缓存（如 ThinkPHP 的
runtime/cache/、Laravel 的bootstrap/cache/config.php）都与 PHP 版本无关，但若缓存里存了旧的类路径，清空它们比重启 phpEnv 更有效
真正卡住人的，往往不是 phpEnv 或 Composer 配置本身，而是命名空间里混进了不可见字符（比如从网页复制代码时带入的零宽空格），或者 IDE 自动补全生成了不存在的类名——这种错误连 composer dump-autoload -v 都不报，只能靠逐字符核对 namespace 声明和文件路径。
