Composer install 在虚拟机中重装 vendor 是因文件系统隔离导致路径和哈希校验失败；挂载宿主机 vendor 不推荐，因符号链接、权限、opcache 和扩展 ABI 不兼容；正确做法是宿主机执行 install，虚拟机仅运行，确保 PHP 版本与核心扩展一致。
为什么 composer install 在虚拟机里会重新下载 vendor？
因为 Composer 默认把 vendor 目录建在项目路径下，而虚拟机和宿主机的文件系统是隔离的。即使你用共享文件夹把代码同步过去，Composer 仍会认为这是个“全新环境”，检查不到已有的 vendor（尤其是 vendor/autoload.php 路径不一致、composer.lock 的哈希可能因平台差异校验失败），于是重装一遍。
直接挂载宿主机 vendor 目录可行吗？
不推荐。多数虚拟机（如 VirtualBox/Vagrant）对符号链接和文件权限支持不稳定，vendor 里的软链（比如 bin 文件指向源码）容易失效；PHP 运行时还可能报 failed to open stream: Permission denied 或 Class not found —— 根本原因是 PHP 的 opcache 和 realpath 缓存对跨挂载点路径处理不一致。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 宿主机
vendor是为 macOS/Linux/macOS 编译的扩展（如ext-redis）无法在虚拟机的 Linux 下直接加载 -
composer dump-autoload -o生成的优化类映射依赖绝对路径，挂载后路径变了就失效 - 某些包的
post-install-cmd脚本（比如生成配置、写缓存）会在虚拟机里执行，但写入位置可能是宿主机不可写的路径
真正能用的方案：只同步代码，vendor 留在宿主机 + COMPOSER_VENDOR_DIR
让 Composer 把 vendor 写在宿主机上、但 PHP 运行时能正确加载——关键不是“共享目录”，而是“统一加载路径”。做法是：在虚拟机里设置 COMPOSER_VENDOR_DIR 指向一个宿主机可访问的固定路径（比如 /vagrant/vendor），同时确保这个路径被映射且有读写权限；再用 composer install --no-scripts 避开可能失败的钩子脚本。
- 启动虚拟机前，在
Vagrantfile中加：config.vm.synced_folder "./vendor", "/vagrant/vendor", owner: "vagrant", group: "www-data" - 进入虚拟机后，运行：
export COMPOSER_VENDOR_DIR=/vagrant/vendor（建议写进~/.bashrc） - 执行：
composer install --no-scripts --no-dev（跳过post-install-cmd和开发依赖，减少出错面） - PHP 加载时需确认
include_path或自动加载器能覆盖到/vagrant/vendor/autoload.php，通常 require 它即可
更稳的做法：根本不用虚拟机跑 composer install
把 Composer 当成纯构建工具，只在宿主机执行安装，虚拟机只负责运行。只要宿主机和虚拟机 PHP 版本兼容（比如都是 8.1+）、扩展集基本一致（mbstring, curl, json 等核心扩展存在），vendor 就能直接复用。
- 宿主机跑：
composer install --optimize-autoloader --no-dev，生成优化后的vendor/autoload.php - 虚拟机里不做任何
composer操作，只确保 Web 服务器 DocumentRoot 指向共享的代码目录 - 如果遇到
Class not found，大概率是 autoloader 缓存没刷新，删掉vendor/composer/autoload_classmap.php和autoload_static.php重试 - 注意：Laravel 的
bootstrap/cache/config.php等缓存文件不能跨系统复用，每次换环境要清空bootstrap/cache/
vendor 看似只是路径问题，实际牵扯到 PHP 扩展 ABI、文件系统语义、autoloader 路径解析三层耦合——最省事的方式，其实是别让虚拟机碰 composer install 这个动作。 
