临时文件权限问题本质是Composer写入元数据时被系统拦截，需检查报错路径属主、挂载选项及install参数是否匹配环境。
报错含 vendor/composer/installed.json 或 cache/repo/ 是临时文件权限问题
这类错误本质不是代码缺陷，而是 Composer 在写入运行时生成的元数据文件时被系统拦截。典型路径如 vendor/composer/installed.json、~/.composer/cache/repo/https---packagist.org/packages.json 或 vendor/composer/ClassLoader.php 出现 Permission denied，说明当前用户对这些目录没有写权限。
先确认报错里完整路径指向哪个位置，再针对性检查：
- 若路径含
vendor/composer/，执行ls -ld vendor/composer/，看属主是否为当前用户（$(whoami)） - 若路径含
~/.composer/cache/，运行ls -ld $(composer config --global cache-dir)，同样核对属主 - 若路径是
/tmp/composer*，说明系统/tmp目录启用了noexec或nosuid挂载选项，需换缓存目录：composer config -g cache-dir /home/$USER/.composer-cache
反复出现 modified 但没改代码，其实是临时文件残留
composer status 报 modified 却找不到手动改动痕迹？大概率是上一次 install 或 update 中断后，部分包的 post-install-cmd 脚本没跑完，导致 vendor/ 下混入了半生成状态的临时文件（比如 Symfony 的 var/cache/dev/、Laravel 的 storage/framework/views/）。这些文件不在 Git 忽略列表中，会被 status 扫描到。
验证方式：
- 加
-v参数重跑：composer status -v，它会列出具体哪些文件被标记为 modified - 若输出含
vendor/symfony/cache/或vendor/laravel/framework/src/Illuminate/Foundation/Console/stubs/类路径，基本可判定是脚本中断残留 - 清理方法：删掉整个
vendor/后重装，或仅删对应包下的var/、cache/、build/等临时子目录（不碰src/和composer.json）
dump-autoload 生成 autoload_static.php 失败，常因临时目录不可写
composer dump-autoload 卡在 Generating autoload files 或报 file_put_contents(/path/to/vendor/composer/autoload_static.php): Permission denied，说明 Composer 尝试写入静态加载器时失败。这个文件是纯生成产物，不参与版本控制，但必须可写。
关键检查点：
- 目标路径父目录（通常是
vendor/composer/）是否可写：touch vendor/composer/test && rm vendor/composer/test - 是否误用
sudo composer dump-autoload导致该目录属主变成 root，后续普通用户无法覆盖 —— 此时sudo chown -R $USER:$USER vendor/composer/比重装更高效 - 某些容器环境（如 Alpine）默认禁用
proc_open，而 Composer 生成静态文件时依赖它；检查php -i | grep disable_functions是否含proc_open
CI/CD 流水线里 vendor/ 下一堆 .git/ 和 .lock 临时文件？是 install 参数没配对
流水线打包后发现 vendor/ 里混入大量 .git/ 子目录、composer.lock 副本或 package.xml，说明 composer install 执行时没加 --no-dev --optimize-autoloader --no-scripts。Composer 默认会保留开发依赖的源码元信息，而这些正是“临时文件”的来源。
正确做法：
- 上线构建必须用：
composer install --no-dev --optimize-autoloader --no-scripts --prefer-dist - CI 阶段若需测试，应分两步：先
composer install --no-scripts（跳过 post-install-cmd），再单独跑测试所需脚本 - 禁止在生产镜像中保留
composer.lock的副本（如vendor/composer/installed.json已包含足够信息），避免被误当配置文件扫描
临时文件问题最麻烦的地方在于：它不总在同一个路径报错，但根因高度一致——要么属主错位，要么目录挂载策略限制写入，要么 install 参数没对齐环境角色。盯住报错里的绝对路径，比猜“是不是网络”或“是不是证书”快得多。
