根本原因是PHP无法写入系统临时目录（如/tmp），导致Composer解压、缓存等操作失败；常见于/tmp权限错误、容器只读挂载、SELinux拦截或PHP配置指向无效路径。
问题的根源往往不在Composer本身，而是它底层的“助手”——PHP——在关键时刻掉了链子。具体来说，是PHP无法向系统临时目录（比如常见的/tmp）写入文件，导致Composer在解压包、生成缓存、创建自动加载文件等一系列操作时直接卡住。
为什么 /tmp 权限会出问题
Composer本身并不直接管理临时文件，它依赖PHP的内置函数sys_get_temp_dir()来获取一个临时目录路径。这个目录，就是所有解压、缓存等中间过程的“工作台”。一旦这个“工作台”不可写，报错就来了，通常是failed to open stream: Permission denied或mkdir(): Permission denied这类权限拒绝信息。麻烦的是，错误提示常常不指明具体路径，很容易让人误以为是项目下的vendor目录出了问题，从而在错误的方向上浪费时间。
那么，哪些情况会让这个“工作台”失效呢？
- 共享服务器环境：服务器被多人共用时，
/tmp目录可能被其他用户或自动化脚本意外清空，或者权限被不当修改。 - 容器与CI环境：在Docker容器或某些CI Runner（如GitLab CI）中，
/tmp目录有时会被挂载为只读（read-only）文件系统，或者其可用空间受到严格限制。 - 安全策略拦截：像SELinux（常见于CentOS/RHEL）或AppArmor这类强制访问控制安全模块，可能会阻止PHP进程向
/tmp目录写入。 - PHP配置指向错误：PHP配置文件（php.ini）中的
sys_temp_dir或upload_tmp_dir指令，可能指向了一个不存在的目录，或者一个当前用户没有写入权限的路径。
确认 PHP 实际使用的临时目录
别靠猜测，动手验证才是最靠谱的。打开终端，运行下面这行命令，看看PHP到底把临时文件放在哪儿：
php -r "echo sys_get_temp_dir();"
输出结果通常是/tmp，但也可能是/var/tmp，甚至是用户家目录下的某个路径。接下来，就要检查这个路径是否真的“健康”。
- 检查权限与属性：运行
ls -ld $(php -r "echo sys_get_temp_dir();")。重点关注输出中的权限部分，正常情况下应该包含drwxrwxrwt。注意末尾的t，这是粘滞位（sticky bit），能防止用户删除他人的文件，是/tmp目录的标准配置。 - 诊断与修复：如果权限不对（比如缺少
w写入位），或者目录的所有者、所属组导致当前用户无法写入，就需要进行修复。更极端的情况是，这个路径根本不存在。这时，需要手动创建它并设置正确的权限：mkdir -p /path/to/temp && chmod 1777 /path/to/temp。切记，这里要用1777（包含粘滞位），而不是简单的777。
清理 /tmp 并避免误删关键文件
当怀疑是/tmp目录太满或太乱导致问题时，清理是必要的，但方法一定要谨慎。直接执行rm -rf /tmp/*是一剂“猛药”，风险极高——可能会误删正在运行的服务（如systemd、MySQL）使用的临时socket文件，影响系统稳定性。
更稳妥的做法是进行“精准清理”：
- 针对Composer残留：清理Composer明确使用的文件，例如
find /tmp -maxdepth 1 -name "composer-*.phar" -delete。 - 清理过期会话文件：可以清理那些长时间未修改的PHP Session文件，例如
find /tmp -name "sess_*" -mmin +60 -delete。 - 排查磁盘空间：如果问题是磁盘空间不足，先用
df -h /tmp查看挂载点空间使用率，再用du -sh /tmp/* | sort -hr | head -10找出占用空间最大的前十个文件或目录，针对性处理。 - 牢记权限原则：任何时候，都不要图省事对
/tmp使用chmod 777。这会给系统带来严重的安全隐患。chmod 1777才是既保证可写性又维持基本安全性的标准做法。
PHP 配置与容器/CI 场景的特殊处理
在Docker、GitHub Actions、GitLab CI这类现代化部署和集成环境中，临时目录的问题有其特殊性。/tmp可能是一个内存文件系统（tmpfs），或者是一个权限受限的Docker Volume。
这就需要一些针对性的配置技巧：
- 显式指定PHP临时目录：最直接的方法是在
php.ini中明确设置：sys_temp_dir = /tmp/php-tmp。然后，确保这个目录存在且权限正确：mkdir -p /tmp/php-tmp && chmod 1777 /tmp/php-tmp。 - Dockerfile最佳实践：在构建Docker镜像时，就可以预先创建并设置好这个目录。在Dockerfile中加入：
RUN mkdir -p /tmp/php-tmp && chmod 1777 /tmp/php-tmp。在运行容器时，再通过环境变量（如PHP_INI_SCAN_DIR）确保PHP能加载到相关配置。 - CI环境的注意事项：像GitHub Actions官方提供的
actions/setup-php通常已经处理好了临时目录。但如果使用的是自定义Runner，务必确保/tmp挂载在一个可写的标准文件系统（如ext4）上，而不是NFS或CIFS这类网络文件系统，后者可能带来额外的权限或性能问题。
最后，还有一个极其隐蔽的“陷阱”：即使/tmp目录的权限完全正确，PHP也可能因为open_basedir配置的限制而无法访问它。运行php -i | grep open_basedir检查一下，如果输出不是no value，就意味着存在访问限制。这时，必须将PHP使用的临时目录路径，添加到open_basedir的白名单列表中，问题才能彻底解决。
