报错路径即真实问题目录，需用ls -ld检查bin/、vendor/或全局缓存目录归属，属主非当前用户则sudo chown -R $USER:$USER修复；WSL/Docker/Windows等环境应启用metadata或改用bin-compat=copy模式。
Composer install 报 symlink failed 怎么定位真实路径
报错里带 symlink(): Permission denied，说明 Composer 尝试创建符号链接时被拒，但根本原因不是“不能建软链”，而是目标目录或其父级没有写权限，或挂载点禁止 symlink。关键看完整错误行，比如：symlink(/home/alex/myapp/vendor/bin/phpunit, /home/alex/myapp/bin/phpunit): Permission denied → 问题在 /home/alex/myapp/bin/ 目录；若报错是 symlink(/tmp/composer_xxx, /home/alex/myapp/vendor/composer/xxx) → 问题在 vendor/ 或其父级。
Linux/macOS 下 symlink 失败的三个常见归属陷阱
软链失败绝大多数仍属所有权错配，不是 umask 或 SELinux（除非明确启用）。重点检查三处：
-
ls -ld bin/（或报错中目标路径的父目录）：如果属主是root，chown $USER:$USER bin/即可 -
ls -ld vendor/：若vendor/是 root 所有，vendor/bin/下所有软链都会失败，必须先修复vendor/ -
ls -ld $(composer config --global cache-dir)：缓存解压时若需重建软链（如 global 包），这里属主错也会卡住
Windows / WSL2 / Docker 环境下 symlink 的特殊限制
这些环境默认禁用软链或需显式配置，和 Linux 权限无关，但错误信息一样是 Permission denied：
- WSL2：确认
/etc/wsl.conf含[automount]+options = "metadata"，否则 Windows 挂载盘不支持symlink - Docker：运行容器时加
--cap-add=SYS_ADMIN（不推荐）或改用copy模式：在composer.json加"config": {"bin-compat": "copy"} - Windows 原生 Git Bash / CMD：默认禁用开发者模式时，
mklink被拦截，报错同symlink()；启用「开发者模式」或改用composer config --global bin-compat copy
修复后仍报 symlink failed 的隐藏原因
即使所有权正确，以下情况仍会失败：
- 目标目录挂载自 NFS / SMB / VirtualBox Shared Folder：这些文件系统常禁用
symlink，无法绕过，只能强制用copy模式 -
vendor/bin/已存在同名文件（非软链），Composer 不会覆盖，直接报错；删掉冲突文件再重试 - PHP 配置禁用了
symlink()：检查disable_functions是否含该函数（少见，但 CI 容器可能这么设）
最稳妥的兜底操作是统一关闭软链：运行 composer config --global bin-compat copy，之后所有 vendor/bin/ 下命令都以复制方式生成，不再依赖 symlink()。
