根本原因是共享目录文件系统（如vboxsf）不支持POSIX权限和符号链接，导致composer install创建软链、设可执行权限失败；应避免在共享目录运行该命令，改用虚拟机本地磁盘操作。
composer install 命令在虚拟机里报 Permission denied 怎么办
根本原因是宿主机挂载的共享目录（如 VirtualBox Shared Folders、VMware Fusion 的 Shared Folders）在 Linux 虚拟机里默认以 vboxsf 或 vmhgfs 文件系统挂载，不支持 POSIX 权限和符号链接，而 composer install 会尝试创建软链（比如 vendor/bin/xxx 指向 ../xxx）、写入可执行文件、设置 chmod +x —— 这些操作全被拒绝。
实操建议：
- 不要在共享目录里直接运行
composer install；把项目代码复制到虚拟机本地磁盘（如/home/vagrant/myapp），再执行 - 如果必须用共享目录开发，改用
--no-scripts --no-plugins --no-dev降低权限需求，但部分包仍会失败 - 别试图用
sudo composer install：root 用户也无法绕过文件系统限制，反而污染vendor/所有权
composer 全局安装后命令找不到：bash: composer: command not found
不是没装成功，是 composer.phar 没放进 $PATH，或者放错了位置。常见于手动下载后只执行了 php composer.phar，却没设为全局可执行命令。
实操建议：
- 下载后用
sudo mv composer.phar /usr/local/bin/composer（注意没后缀），再sudo chmod +x /usr/local/bin/composer - 检查
echo $PATH是否含/usr/local/bin；若用的是/home/vagrant/bin，得把该路径加进~/.bashrc并source ~/.bashrc - 别用
php ~/composer.phar方式“假装”已安装——每次都要输完整路径，且 IDE、Git Hook 等调用不到
共享目录里 vendor/ 权限混乱，宿主机看不到自动加载文件
Linux 虚拟机里生成的 vendor/ 是由 www-data 或 vagrant 用户写的，但共享目录在宿主机上显示为只读或所有者是 root:vboxsf，导致 PhpStorm 无法索引、自动补全失效、甚至 Git 提交时提示权限错误。
实操建议：
- 彻底放弃在共享目录中生成
vendor/：通过composer config --global vendor-dir /home/vagrant/.composer/vendor把全局 vendor 放本地，再用autoload-files或 symlink 手动桥接（不推荐） - 更稳的做法：用
composer install --no-dev --optimize-autoloader在虚拟机本地跑完，然后把整个vendor/目录从虚拟机拷回宿主机对应位置（用rsync或scp） - 别依赖 VirtualBox 自动挂载的
/media/sf_*目录做开发主路径——它天生不适合 PHP 生态的文件操作模型
为什么不用 Docker 替代虚拟机跑 Composer
不是不能，而是多数人卡在“想复用现有 Vagrant 环境”或“公司强制用 VirtualBox”。但得说清一点：Docker 容器里跑 composer install 本质是把依赖装进容器层，不涉及宿主-容器间文件系统权限博弈，vendor/ 可读可写可 symlink，IDE 索引也正常。
实操建议：
- 如果只是本地开发，优先用
docker run --rm -v $(pwd):/app -w /app php:8.2-cli composer install，一行搞定，不碰虚拟机共享目录 - Vagrantfile 里加个
config.vm.synced_folder ".", "/vagrant", type: "rsync"，让 rsync 同步代替实时挂载，避开vboxsf缺陷 - 别为了“统一环境”硬在 VirtualBox 里模拟 Docker 行为——文件系统抽象层级不同，强行对齐只会放大问题
真正麻烦的从来不是 Composer 本身，而是共享目录那层看不见的权限墙。越早接受“代码在宿主机、依赖在虚拟机本地”这个分工，越少半夜 debug symlink(): Operation not permitted。
