Composer install后vendor权限不足表现为PHP运行时“Permission denied”错误；需用chown修正归属，find设755/644权限，禁用777；可通过post-install-cmd脚本自动修复；Docker中应避免挂载冲突，优先多阶段构建。
Composer install 后 vendor 目录权限不足的典型表现
执行 composer install 或 composer update 成功后，PHP 应用运行时报错：「Permission denied」写入 vendor/autoload.php、缓存文件或日志；或者 Laravel 的 php artisan config:cache 失败，提示无法写入 vendor/composer/ 下的 JSON 文件。这不是 Composer 安装失败，而是后续运行时因目录权限不足被系统拒绝。
Linux/macOS 下 vendor 目录权限修复的实操步骤
默认情况下，Composer 创建的 vendor 目录权限由当前用户 umask 决定，常导致组/其他用户无写入权。需主动修正：
- 确保项目根目录归属正确：
sudo chown -R $USER:www-data /path/to/project（Ubuntu/Debian）或sudo chown -R $USER:_www /path/to/project（macOS） - 重设
vendor及其子目录权限：find vendor/ -type d -exec chmod 755 {} \; - 重设
vendor下所有文件权限：find vendor/ -type f -exec chmod 644 {} \; - 特别处理可执行脚本（如
bin/下的）：chmod +x vendor/bin/* 2>/dev/null || true
注意：不要对整个 vendor/ 执行 chmod -R 777 —— 这会暴露第三方包中的敏感路径或调试脚本，且部分包（如 symfony/console）依赖精确的文件权限判断。
通过 Composer 配置避免重复权限问题
Composer 本身不提供「自动设权限」选项，但可通过 scripts 在安装后自动修复：
{
"scripts": {
"post-install-cmd": [
"@php -r \"file_exists('vendor/') && system('find vendor/ -type d -exec chmod 755 {} \\; && find vendor/ -type f -exec chmod 644 {} \\;');\""
],
"post-update-cmd": ["@post-install-cmd"]
}
}
该脚本仅在 Linux/macOS 生效；Windows 用户需改用 PowerShell 脚本或手动处理。另外，composer.json 中的 config.process-timeout 和 config.autoloader-suffix 不影响权限，勿混淆。
Docker 环境中 vendor 权限的特殊处理
容器内运行 Composer 时，若宿主机挂载了 vendor 目录，常见问题是 UID/GID 不匹配 —— 容器内用户（如 www-data:33）与宿主机用户（如 1001:1001）不同，导致挂载后目录不可写。
- 构建阶段用多阶段 Dockerfile：先在 builder 阶段运行
composer install，再 COPYvendor/到运行镜像，避免挂载 - 若必须挂载，启动容器时指定 UID：
docker run -u $(id -u):$(id -g) ... - 禁用 Composer 的
vendor-dir挂载，改用绑定挂载到非 vendor 路径（如/app/shared），再通过符号链接指向vendor
最易忽略的是：Docker Desktop for Mac 的文件共享机制默认以 root UID 挂载，即使指定了 -u，vendor/ 目录仍可能被创建为 root 所有 —— 此时需在容器内首次运行前手动 chown。
