Composer install报“path does not exist”实为权限或归属问题，非路径真缺失；应检查报错中明确路径的归属（如vendor/、composer.lock、全局缓存），用ls -ld确认是否属root，再以chown -R $USER:$USER修复，禁用chmod -R 777。
报错里带路径的那一行就是问题所在
Composer install 报错 “path does not exist” 或类似提示（比如 file_put_contents(/xxx/vendor/autoload.php): Failed to open stream: No such file or directory），根本不是目录真丢了，而是当前用户对目标路径**没有写入权限**，或该路径**归属错误**。Windows 上常见于 vendor/、composer.lock 或全局缓存目录（如 ~/.composer/cache）被 root 或 SYSTEM 占有。
别信“路径不存在”这个误导性描述——它只是 PHP fopen() 失败后的通用 fallback 提示。真正要看的是报错里明确写出的完整路径，比如：
-
Could not write to /var/www/myapp/composer.lock→ 问题在composer.lock -
Writing cache file ~/.composer/cache/repo/https---packagist.org/→ 问题在全局缓存目录 -
file_put_contents(/home/alex/myapp/vendor/autoload.php)→ 问题在vendor/
立刻执行这三行查归属：
ls -ld vendor/ ls -ld composer.lock ls -ld $(composer config --global cache-dir)
只要任意一行第一列显示 root（如 drwxr-xr-x 12 root root），就确认是所有权错配，不是路径本身不存在。
chown 是解药，chmod -R 777 是毒药
改权限 ≠ 改归属。chmod 控制“能不能读写”，chown 才决定“这东西归不归你”。误用 chmod -R 777 会导致：
-
vendor/bin/phpunit这类可执行文件被 CI 工具或安全扫描器直接拒收 - Git 提交时提示
ownership changed - 后续
composer update可能只失败一半，连chown -R都救不回来
正确做法是归还控制权：
- 修复项目内目录：
sudo chown -R $USER:$USER vendor/ composer.lock - 修复全局缓存：
sudo chown -R $USER:$USER $(composer config --global cache-dir) - 整个
~/.composer都属 root？直接重置：sudo chown -R $USER:$USER ~/.composer
sudo 这里只是临时提权跑 chown，不是让你去跑 sudo composer install——后者才是污染源头。
嵌套权限混乱最容易被忽略
一次 sudo composer install 可能让 vendor/ 下混进个别 root 所有子目录，ls -la vendor/ 就能发现。这时候别硬修，直接 rm -rf vendor/ 再重装更省事——前提是确认当前用户对项目根目录、composer.lock 和缓存目录都有完整所有权。
Docker、CI 和 global require 场景下权限问题往往不报在主流程里，但一样卡住：
- Docker 中宿主机 UID 是 1000，容器却以 UID 0 (root) 运行 → 挂载卷时加
user:1000或 Dockerfile 里加USER 1001 -
composer global require报错？先查composer config --global home，如果输出是/root/.composer或/var/www/.composer，说明环境已被污染 - 插件干扰：加
--no-plugins --no-interaction试试，composer install --no-plugins成功，大概率是某个全局插件（比如hirak/prestissimo）在/tmp创建 socket 后没释放权限
Windows 上报“路径不存在”要盯住 PATH 和 PHP_BINARY
Windows 用户看到“路径不存在”，90% 是 composer.bat 找不到 php.exe，或者 PATH 超长导致 CreateProcess failed。
先验证 PHP 是否真可用：
- 运行
where php—— 如果无输出，说明 shell 当前 session 没加载到 PHP 路径 - 运行
php -v和C:\php\php.exe -v对比，确认是否调用了预期版本（比如 MAMP 自带的 PHP 通常不在 PATH） - 路径含空格（如
C:\Program Files\php\php.exe）时，旧版 Composer 解析不稳定，建议用短路径（C:\PHP\php.exe）或设PHP_BINARY环境变量
PATH 超限也会伪装成路径错误：
- 运行
echo %PATH% | powershell -Command "$input.Length"查长度，超 32767 就会卡在exec() - 重点清理重复的
%APPDATA%\Composer\vendor\bin条目，它常被 IDE 插件反复写入 - 禁用 Composer 自动改 PATH 的行为：检查注册表
HKEY_CURRENT_USER\Environment\PATH，删掉可疑条目
真实路径存在但 Composer 仍报错，可能是 composer.json 有 BOM 头（Windows 记事本保存）、软链接断裂、或容器挂载路径映射失败——这些不会报权限错，但结果一样是“找不到”。
