直接运行composer install即可恢复vendor目录，前提是composer.lock存在且未被修改；否则依赖版本可能漂移，导致类加载失败。
vendor 目录丢了，直接 composer install 就能恢复——但前提是 composer.lock 还在且没被改坏；否则装出来的依赖可能和线上不一致，甚至类都加载不了。
vendor 目录丢失后为什么不能只跑 composer update
因为 composer update 会重新解析 composer.json 里的版本约束，可能把 thinkphp/framework 从 v6.0.42 升到 v6.1.0（如果约束是 "^6.0"），而你的生产环境锁的是旧版。更糟的是：它不会清掉 vendor 里残留的旧文件，autoload 映射也可能指向已删除的类路径。
-
composer update的目标是“升级”，不是“还原” - 它会修改
composer.lock，提交前必须人工确认 diff - TP 项目常依赖特定 patch 版本修复路由或模型 bug，升版后可能出
Class not found或Method not exists
删了 vendor 但 composer.lock 还在，该用 composer install 还是 composer install --no-cache
优先用 composer install --no-cache。哪怕 lock 文件完好，本地缓存（~/.composer/cache/）里可能存着旧版 TP 包的 zip，Composer 会直接解压缓存，跳过校验——结果是“看着装了，实际还是老文件”。加 --no-cache 强制走网络下载，确保哈希匹配 lock 文件声明。
- 检查是否真拉新包：终端输出里要有
Downloading https://api.github.com/...或类似 URL - Windows 下若卡在 “Downloading”，先关杀毒软件实时扫描，或换 WSL 执行
- 宝塔面板里执行时，注意 PHP 版本和扩展（如
fileinfo、curl）必须启用，否则composer install会静默失败
vendor 和 composer.lock 都没了，怎么安全重建 TP 依赖
别急着 composer update。先确认 composer.json 里 thinkphp/framework 的版本写法：是 "^6.0" 还是精确锁定 "6.0.42"？前者会按当前 Packagist 状态拉最新兼容版，后者才可控。重建分三步：
- 删干净：
rm -rf vendor composer.lock（Windows 用rmdir /s vendor && del composer.lock） - 补平台信息（尤其宝塔）：
composer config platform.php 8.1.22（填你实际 PHP 版本），避免因平台不匹配漏装 polyfill - 装并锁：
composer install --no-cache—— 它会基于composer.json生成新 lock，再安装，行为可复现
这一步之后，立刻运行 composer dump-autoload，不然 TP 的 thinkRoute 或你自己的 appcommonservice* 类可能仍加载失败。
重装完 TP 依赖，autoload 映射却没更新怎么办
常见于 Windows 或 macOS 上手动改过命名空间路径，或删过 vendor/composer/autoload_psr4.php。不要信终端那句 “Generating autoload files…”——打开 vendor/composer/autoload_psr4.php，搜 think\，确认值是 ['vendor/topthink/framework/src/'] 而不是空数组或旧路径；再临时加一行：var_dump(class_exists('think\Route'));，返回 false 就说明映射没生效。
- 强制刷新：
composer dump-autoload -o（优化模式）比默认快，且会重建autoload_classmap.php - TP 自定义 PSR-4 映射（如
"app\": "app/"）必须写在composer.json的autoload段，改完要再跑一次dump-autoload - 大小写敏感：macOS 默认文件系统不区分大小写，但 Composer autoloader 区分；
App\Service\和app\service\在代码里混用会导致class_exists返回false
