磁盘配额不足时 composer install 报 mkdir(): permission denied 是因 quota 超限被系统映射为权限错误，需用 quota -s 验证；临时方案包括禁用脚本、强制用压缩包、清缓存等，根本解法是迁移 vendor 目录或精简操作。
磁盘配额不足时 composer install 报错 mkdir(): Permission denied 怎么判断
错误信息里出现 mkdir(): Permission denied，但 ls -ld . 显示当前目录权限正常、属主正确，大概率是磁盘配额（quota）触发的静默限制——系统不报“disk full”，而是把写失败统一映射成权限错误。这种现象在共享主机、学校/企业 Linux 环境中极常见。
验证方式只有一条命令：quota -s（或 quota -u $USER）。如果输出里有 block limits 或 files limits 且显示 soft/hard 已用尽（尤其是 % 列为 100+），就是它了。
- 注意：
df -h可能显示磁盘还有大量剩余空间，这恰恰是配额限制的典型特征 - 某些主机面板（如 cPanel）会把 quota 信息藏在「文件管理器」或「高级」菜单里，需手动点开查看
- Web 服务器用户（如
www-data）和 CLI 用户配额可能不同，whoami后再查 quota 更准
配额超限后 vendor 目录写入失败的临时绕过方案
配额无法立刻扩容时，得让 Composer 少写、写小、写快：
- 禁用所有非必要操作：
composer install --no-scripts --no-plugins --no-dev，跳过 post-install-cmd 和 autoload 生成，大幅减少文件写入次数 - 强制使用压缩包而非 Git 克隆：
composer config --global prefer-source false，避免 checkout 产生大量小文件 - 清空缓存再装：
composer clear-cache && composer install --no-cache，防止缓存包解压中途因 quota 失败卡住 - 若项目允许，删掉
composer.lock后用composer update --lock替代install，跳过 vendor 清空重建步骤
vendor 目录写入失败但配额未满？检查隐藏配额陷阱
有些环境配额策略更隐蔽：
-
~/.composer/cache/单独受限：运行composer config --global cache-dir查路径，再quota -u -p $(basename $(composer config --global cache-dir))看该子目录是否被单独设限 - Web 根目录（如
~/public_html）常被主机服务商额外加配额，哪怕你项目放在~/myapp，只要vendor/是符号链接指向~/public_html/vendor，就会触发该限制 - WSL 或 Docker 挂载卷下，宿主机 NTFS 分区可能启用了 Windows 磁盘配额（
fsutil quota可查），此时 Linux 层看到的是 quota 被硬性截断，而非权限问题
长期规避配额导致的 vendor 写入失败
根本解法不是调大 quota（通常无权操作），而是改变写入位置和方式：
- 把
vendor移出配额目录：设COMPOSER_VENDOR_DIR=/tmp/myapp-vendor（确保/tmp不受 quota 约束），再rm -rf vendor && composer install - 用
composer create-project替代install：它直接下载完整归档包，比逐个解压依赖包产生的文件数少 30%～50% - 对 Laravel 等框架，启用
APP_ENV=production+composer install --optimize-autoloader，减少 autoload_files 数量，间接降低写入压力 - 若用 CI/CD，构建阶段提前在无 quota 机器上跑
composer install，打包vendor/进镜像，部署时跳过安装
配额限制下的 vendor 写入失败，本质是系统级资源管控与 Composer 文件操作模型的冲突。修复动作必须落在「路径迁移」或「操作精简」上，任何 chmod/chown 都无效——它根本不是权限问题，而是系统在说“你没额度了”。
