vendor目录写入被拒的根源是用户权限不匹配，常见于误用sudo导致归属root；应始终以项目所属用户运行composer，修复需chown -r $user:$user vendor并chmod -r u+rw vendor。
vendor 目录被拒绝写入：常见报错和根本原因
执行 composer install 或 composer update 时出现类似 Permission denied: mkdir(): Permission denied 或 Could not write to /path/to/vendor/autoload.php，基本说明当前运行 Composer 的用户对 vendor 目录（或其父目录）没有写权限。这不是 Composer 本身的 bug，而是 linux/unix 系统权限模型的正常表现——比如用 sudo composer install 初始化了 vendor，后续再用普通用户操作就会失败。
不要用 sudo 运行 Composer（最常踩的坑）
用 sudo composer install 会导致整个 vendor 目录及其子文件归属变成 root，普通用户彻底失去修改权。后续所有命令（包括 composer dump-autoload）都会失败，且手动 chown 容易遗漏嵌套目录。
- 永远用当前项目所属用户运行 Composer，不加
sudo - 如果必须提权（如全局安装），改用
sudo composer global require，但绝不用于项目本地命令 - 检查当前用户：运行
whoami和ls -ld vendor对比所有者是否一致
修复已有权限混乱的 vendor 目录
若已误用 sudo，先确认当前用户（如 www-data 或你的登录用户名），再批量修正：
chown -R $USER:$USER vendor/ chmod -R u+rw vendor/注意：$USER 是 shell 变量，会自动展开为当前用户名；chmod -R u+rw 确保用户有读写权，但不开放组/其他人的写权限（避免安全风险）。如果项目部署在 Web 服务器下（如 nginx/apache），还需确保 Web 用户（如 www-data）能读取 vendor，可追加：chgrp -R www-data vendor/ && chmod -R g+r vendor/。
预防：设置 umask 或提前声明目录所有权
新项目初始化前，可通过设置 umask 控制新建文件默认权限（推荐 umask 002，使组成员可写），或在 composer.json 中配置 config.process-timeout 等参数不影响权限，但真正起效的是环境层面控制：
- 在项目根目录执行
umask 002（临时）或加入 shell 配置（如~/.bashrc） - 确保项目目录本身可写：
chown -R $USER:$GROUPNAME my-project/ - 避免把项目放在
/var/www等系统保护路径下，优先用家目录或专用工作区
权限问题本质是用户、组、目录三者归属关系没对齐，Composer 不提供“权限管理”功能，它只按当前用户身份操作文件——所以修复永远从“谁在运行”和“目录归谁”两个点切入，别在 composer.json 里找开关。