直接答案：这是文件系统权限问题，非composer故障，需修正归属或权限。根本原因是当前用户对composer.json仅有读权限（r）无写权限（w），常见于git克隆后只读、root创建文件、windows ntfs挂载或docker卷未指定uid/gid；应先用ls -la确认owner和权限位，再用chmod u+w或sudo chown $user:$user修复，避免chmod 777。
这是文件系统权限问题，不是 Composer 故障，直接改归属或权限就能解决。
为什么提示“readable but not writable”
Composer 检查 composer.json 时发现当前用户有读权限（r），但没写权限（w）。常见于：
• 项目从 Git 克隆后被设为只读（如某些 CI 镜像）
• 文件由 root 或其他用户创建，当前用户无权修改
• Windows Git Bash 下挂载的 NTFS 路径未正确映射权限
• Docker 容器内挂载卷时未指定 uid/gid
怎么确认具体权限和归属
先看文件当前状态：
• ls -la composer.json —— 输出类似 -rw-r--r-- 1 root root 1234 Jul 10 03:00 composer.json
• 关键看第三列（owner）、第四列（group）和第一列开头的权限位（-rw- 表示 owner 可读写，-r-- 表示只读）
• 如果 owner 不是你当前用户（whoami），或权限位里没有 w（比如是 -r--r--r--），就必然报这个错
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
安全修复方式（不推荐直接 chmod 777）
优先用归属修正，避免权限过度开放：
• 当前用户是 owner，但没写权限：执行 chmod u+w composer.json
• owner 是 root 或别人：执行 sudo chown $USER:$USER composer.json
• 如果整个项目目录都这样（比如 src/、tests/ 下一堆只读文件）：先 ls -ld . 确认目录归属，再 sudo chown -R $USER:$USER .（注意末尾的 .）
• Windows Git Bash 用户：别在 /mnt/c/ 下操作，移到 ~/project（即 WSL 原生路径），再运行命令
CI/CD 或容器环境下的绕过方案
某些部署流程不允许改文件权限，可临时让 Composer 忽略写检查：
• 设置环境变量跳过验证：COMPOSER_ALLOW_SUPERUSER=1 composer install（仅限可信环境）
• 或用只读模式运行依赖安装：composer install --no-scripts --no-plugins（适合纯 vendor 构建场景）
• 更稳妥的做法：在构建前用 CI 脚本预处理权限，例如 GitHub Actions 中加一步：run: chmod u+w composer.json
真正要小心的是误用 sudo chown -R $USER:$USER . 后又执行 git clean -fdx——可能删掉你刚改完权限的 vendor/ 里的符号链接或 Phar 包。改权限前先确认当前目录是不是你要操作的项目根目录。
