预判 vendor/ 写入失败需检查三处路径属主是否为当前用户，并确认 umask 值（如 0022 或 0002）是否允许生成可读写文件，二者缺一不可。
报错前怎么预判 vendor/ 写入失败
Composer install 失败几乎从不发生在“执行中”，而是在第一次尝试写文件时就卡住——比如 file_put_contents(/path/to/vendor/autoload.php)。与其等报错再排查，不如在运行前确认三处关键路径的属主和权限是否匹配当前用户。
- 用
ls -ld vendor/ composer.lock $(composer config --global cache-dir)一次性检查三个最常出问题的位置 - 输出中第三列（owner）必须是
$(whoami)，否则composer install必然失败；第四列（group）可宽松些，但若 Web 服务器（如 nginx）以不同用户运行，后续 PHP 加载类时可能报Class not found - 如果任意一项显示
root root或其他非当前用户名，说明目录已被sudo composer污染过，别急着 chmod，先sudo chown -R $USER:$USER归还所有权
umask 设置不合理会导致 install 后权限不可用
即使 vendor/ 创建成功，PHP 进程也可能因缺少读或执行权限而无法加载类——这不是所有权问题，而是新文件默认权限太严。关键看当前 shell 的 umask 值。
- 运行
umask查当前值：0022 表示新建目录为 755、文件为 644；0002 才能让组成员也具备写权限（适合开发机或共享组） - 临时生效：
umask 002 && composer install；长期生效可加到~/.bashrc或~/.zshrc - Docker 或 CI 环境中，
umask常被重置为 0022，务必在composer install前显式设置，否则vendor/bin/xxx可能无执行位，导致脚本调用失败
共享主机或容器里要额外验证项目根目录可写
某些环境（如 cPanel 共享主机、OpenShift Pod）对 ~/public_html/ 或 /var/www/html/ 目录有写入限制，composer install 会直接拒绝创建 vendor/，哪怕你拥有子目录所有权。
- 先运行
touch test_write && rm test_write验证当前目录是否可写；失败则说明路径本身被锁定，需换到~/myapp/等纯用户目录再操作 - 在 Docker 中，若用
docker run -v /host/project:/app挂载，宿主机文件 UID/GID 与容器内不一致时，ls -l可能显示?????，此时应改用--chown=1001:1001或启动时指定 UID - Windows WAMP 下，若
composer install报Access is denied且路径含%APPDATA%，大概率是 ACL 权限未授予当前 PHP 用户（如IIS_IUSRS），不能只看文件属性里的“只读”勾选
CI/CD 流水线中容易忽略的全局缓存归属
本地没问题，CI 上却报 Could not write to ~/.composer/cache？因为流水线 Agent 常以固定用户（如 runner）运行，但全局缓存目录可能残留上一次构建的 root 所有权。
- 在 CI 脚本开头加一句：
sudo chown -R $USER:$USER $(composer config --global cache-dir) 2>/dev/null || true，避免因缓存目录归属异常中断整个流程 - 更稳妥的做法是禁用全局缓存：
composer install --no-cache，或用COMPOSER_CACHE_DIR=/tmp/composer-cache指向临时可写路径 - GitLab CI 中若用
cache:缓存vendor/，注意它不会自动同步~/.composer/cache，后者仍需单独处理
实际运行 composer install 前，真正需要确认的只有两件事：当前用户是不是目标路径的 owner，以及 umask 是否允许生成可读写的文件。其余多数“权限问题”都是这两点的衍生现象。
