composer卡住大概率是目录写保护所致，应先用lsof -p pid和touch测试定位vendor/或缓存路径的写权限问题，再检查mount参数、挂载选项及文件系统限制。
Composer 在执行 install 或 update 时卡在某个目录（如 vendor/ 或缓存路径），终端无报错但进程不退出——大概率是该目录被系统级写保护，而非 Composer 自身逻辑问题。
确认挂起是否由写权限缺失导致
别急着重装或清缓存，先验证是不是权限堵住了。Composer 卡住时通常正在尝试写入文件（例如解压 ZIP、生成 autoloader、写 lock 文件），若目标路径不可写，它会阻塞等待（尤其在某些 NFS 或容器挂载场景下）。
- 用
ps aux | grep composer查看卡住的进程，记下 PID - 用
lsof -p PID看它当前打开的文件和路径，重点关注vendor/、~/.composer/cache/或项目根目录下的临时目录 - 手动测试写入：
touch /path/to/suspected/dir/test.tmp && rm test.tmp，失败则直接定位到权限/挂载问题 - 注意：某些 macOS 上的 APFS 加密卷或 Windows WSL2 的跨文件系统挂载，
chmod可能无效，得看挂载参数
检查挂载选项与文件系统限制
写保护常来自底层挂载策略，而非用户 UID/GID 错误。Composer 进程以当前用户身份运行，但若目录所在分区是以 noexec、nosuid、ro 或 nodev 挂载，即使 ls -l 显示可写，实际也无法创建文件。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
mount | grep $(df . | tail -1 | awk '{print $1}')查当前分区挂载参数 - 重点排查：
ro（只读）、noexec（影响 Phar 解包）、uid=/gid=强制映射（常见于 Docker volume 或 Samba 挂载） - Docker 场景下，检查
docker run是否用了--read-only或 volume 挂载时加了:ro - WSL2 中若项目放在 Windows 挂载点（
/mnt/c/...），默认启用元数据禁用（metadata未开启），会导致chmod失效且部分写操作静默失败
绕过缓存写入失败的临时调试法
如果确认是缓存目录（如 ~/.composer/cache/）被锁死，可临时切换到内存路径规避磁盘权限问题，快速验证是否为根源：
- 设环境变量：
export COMPOSER_CACHE_DIR="/tmp/composer-cache-$$"（$$防冲突） - 再执行
composer install --no-cache，观察是否仍卡住 - 若成功，则问题锁定在原缓存路径；若仍卡，说明是
vendor/或项目目录本身被保护 - 注意：
--no-cache不跳过写入 vendor，仅跳过下载缓存，所以仍需确保vendor/可写
容器或 CI 环境中的典型陷阱
CI（如 GitHub Actions、GitLab Runner）或容器中，vendor/ 目录常因构建层缓存机制或非 root 用户权限配置不当而变成只读。
- GitHub Actions 默认工作目录是
read-only的，除非显式用actions/checkout设置persist-credentials: false并确保后续步骤有写权限 - Dockerfile 中若用
COPY --chown=user:user . .但未给vendor/目录赋权，后续composer install会卡在首次写入 - Kubernetes Pod 中若 volumeClaimTemplate 使用
readOnly: true或 initContainer 未正确 chown，也会复现此现象 - 调试建议：在卡住步骤前加
ls -ld vendor/ && id && touch vendor/test，直接暴露权限断点
真正麻烦的不是“没权限”，而是“看起来有权限却写不了”——比如挂载参数覆盖了 chmod、SELinux 上下文限制、或文件系统配额耗尽。遇到卡住，优先查 lsof 和 mount，而不是翻 Composer 日志。
