报错路径直接暴露问题目录，重点查归属而非权限：如“failed to open stream”指向/tmp/composer_abc123，则执行ls -ld /tmp/composer_确认属主是否为当前用户，非则sudo chown $USER:$USER /tmp/composer_；避免chmod -R 777。
报错路径直接暴露问题目录，别猜，先查归属
看到 failed to open stream: Permission denied 或 Could not write to /tmp/composer... 这类错误，重点不是 /tmp 本身是否只读，而是 Composer 试图写入的临时子目录（比如 /tmp/composer_archive_abc123）是否归你所有。Linux 下挂载为 ro 的文件系统会直接拒绝所有写操作，但更常见的是：该临时目录被 root 创建（例如之前用 sudo composer install 触发过），导致当前用户无权在其中创建或覆盖文件。
立刻执行这三步定位：
-
ls -ld /tmp/composer_*—— 看输出第三列（属主）是不是你的用户名 -
mount | grep " /tmp "—— 确认/tmp是否真被挂为ro（极少，但信创终端或加固系统可能启用） -
echo $TMPDIR—— 如果设置了自定义临时目录，问题可能在别处，比如$HOME/.cache/tmp
chown 是首选修复动作，chmod -R 777 是危险操作
95% 的情况是所有权错配，不是权限位不足。用 chmod -R 777 /tmp 不仅无效（因为 /tmp 本身有 sticky bit 保护），还会触发安全扫描告警、CI 工具拦截，甚至让 Git 提示 ownership changed。
正确做法是归还控制权：
- 清理已污染的临时目录：
rm -rf /tmp/composer_* - 确保后续生成的临时目录归你所有：运行
sudo chown $USER:$USER /tmp（仅需一次，/tmp默认允许用户创建子目录） - 若
$TMPDIR指向非标准路径（如~/.cache/tmp），同样执行：sudo chown -R $USER:$USER $TMPDIR
Docker/CI 中临时目录只读的典型表现与绕过
容器或 CI 环境里，/tmp 常被挂载为只读，或宿主机 /tmp 的 UID 不匹配容器内用户，导致 Composer 在解压依赖时卡死在 Extracting archive 阶段，错误不显眼但流程中断。
应对方式不是硬改系统挂载，而是绕开：
- Dockerfile 中加：
ENV COMPOSER_CACHE_DIR=/app/.composer-cache && RUN mkdir -p /app/.composer-cache，再把缓存和临时目录统一指向项目内可写路径 - GitHub Actions 中，在
composer install前插入：run: export TMPDIR=$PWD/.tmp && mkdir -p $TMPDIR && chmod 700 $TMPDIR - GitLab CI 中，避免复用系统
/tmp，改用cache:显式声明key: $CI_COMMIT_REF_SLUG-composer并绑定到项目子目录
信创终端或加固系统下真正的只读挂载怎么识别
如果 mount | grep " /tmp " 输出含 ro，或错误中反复出现 Read-only file system，说明不是 Composer 的问题，而是系统级挂载策略。这类环境（如统信UOS、麒麟V10）常对 /tmp 或整个根分区启用防篡改只读保护。
此时不能靠 chown 解决，必须运维介入：
- 确认是否启用系统保护机制（如 UOS 的“系统防护”开关）
- 临时恢复读写：
sudo mount -o remount,rw /tmp（注意：部分信创系统禁止此操作，需联系管理员） - 长期方案：将 Composer 临时目录迁出系统盘，例如设为
export TMPDIR=$HOME/tmp && mkdir -p $HOME/tmp
真正棘手的是嵌套污染——一次 sudo composer install 可能让 /tmp 下残留个别 root 所有子目录，ls -la /tmp | grep root 才能揪出来；这种情况下 chown -R $USER:$USER /tmp 仍有效，但如果已触发 Composer 内部缓存校验失败，删掉整个 /tmp/composer_* 并重试反而更快。
