答案是/tmp下Composer临时文件属主为root导致普通用户无权操作，应精准定位后用sudo chown $USER:$USER修复属主，禁用sudo rm -rf和chmod 777。
临时文件权限问题不是“没权限”，而是“不属于你”——Composer 在 /tmp 下创建的 socket、lock 或缓存文件若属主为 root，普通用户后续就无法覆盖或删除。
为什么 /tmp 下的 Composer 临时文件会报 Permission denied
错误常出现在 composer global require、插件初始化或并发安装时，典型报错如：Failed to open stream: Permission denied 或 Could not acquire lock on /tmp/composer-xxxx.lock。这不是 /tmp 目录本身权限不够（它本就是 1777），而是某个 Composer 进程曾用 sudo 启动过，导致它在 /tmp 下创建的文件/目录属主变成 root，而你当前是普通用户，无权修改。
- 查证方式：运行
ls -l /tmp | grep composer，看输出中第三列是否为root - 常见污染源：
sudo composer global require hirak/prestissimo、CI 中未清理的缓存步骤、Docker 容器以 root UID 挂载宿主机/tmp -
/tmp是全局共享空间，但所有权不继承——哪怕你删了旧文件，新进程仍可能因残留 socket 或 umask 设置失败而卡住
怎么安全清理被 root 占用的 Composer 临时文件
别用 sudo rm -rf /tmp/composer* 粗暴清空（可能误删其他进程文件），应精准定位 + 归还所有权：
- 先找出具体路径：运行
composer config --list | grep cache，重点关注cache-dir和data-dir输出；若报错含/tmp/composer-*.lock，就直接查那个文件 - 只修复属主，不改权限：
sudo chown $USER:$USER /tmp/composer-*.lock（无-R，因为这是单个文件） - 若发现整个
/tmp/composer-*目录树都是root，用sudo chown -R $USER:$USER /tmp/composer-* - 验证是否生效：运行
ls -l /tmp/composer-*，确认第三列是你用户名
Docker / CI 场景下 /tmp 权限更隐蔽的坑
本地没问题，一进容器或流水线就失败，大概率是 UID 错位导致的“假权限”：
- Docker：宿主机
/tmp下的文件 UID=1000，但容器默认以 UID=0（root）运行 → 容器内进程能读，但 PHP CLI 写入时因 umask 或 open_basedir 限制失败；解法是在docker run加-u $(id -u):$(id -g)，或在Dockerfile里明确USER 1001 - GitHub Actions：runner 默认 UID=1142，但某步用了
sudo写了/tmp/composer-cache→ 后续步骤无法覆盖；应在 job 开头加：run: sudo chown -R ${{ runner.uid }}:${{ runner.gid }} /tmp/composer* - GitLab CI：
/tmp被挂载为 tmpfs，但 runner 用户组可能不含www-data→ 若项目依赖 Web 服务写缓存，需显式usermod -a -G www-data $USER
最易被忽略的是插件残留：比如 hirak/prestissimo 会在 /tmp 创建 Unix socket 文件并设为 root:root，即使卸载插件也不会自动清理。运行 ls -la /tmp | grep prestissimo 就能揪出来——这种文件不删掉，下次 composer install 仍会卡在 lock 获取阶段。
