先执行 composer clear-cache 安全清理无效缓存，再手动进入 ~/.composer/cache/files/ 按包名保留最新版、删除旧版；还可配置 cache-max-size 或禁用 cache-dist 预防膨胀。
Composer install 报错 disk space is insufficient 怎么办
不是磁盘真满了，而是 Composer 缓存了大量历史包的 zip 和 dist 文件，尤其在频繁切换版本、使用 composer update 或镜像源不稳定时，缓存会指数级膨胀。默认缓存路径在 ~/.composer/cache/（Linux/macOS）或 %APPDATA%\Composer\Cache\（Windows），单个包的多个版本可能共存，占几 GB 很常见。
- 先确认缓存大小：
du -sh ~/.composer/cache（Linux/macOS）或用资源管理器查看 Windows 缓存目录 - 别直接删整个
cache文件夹——这会让下次composer install重新下载所有包，耗时且加重网络压力 - 优先执行
composer clear-cache，它会安全清理无效、损坏、过期的缓存项，保留仍被本地项目引用的可用包
如何只删旧版本、留最新版缓存？
Composer 自身不提供“按版本号保留最新”的清理命令，但可借助缓存结构手动精简。它的 cache/files/ 下以包名哈希 + 版本号命名目录，每个目录含 .dist（zip/tar 包）和 .source（git clone）两类缓存。
- 进缓存根目录：
cd ~/.composer/cache/files - 按包名分组并保留最新版（需 bash/zsh）：
for d in */; do ls -t "$d" | tail -n +2 | xargs -I{} rm -rf "$d{}"; done - 该命令对每个包目录按修改时间倒序列出文件，跳过第一个（最新版），删掉其余——前提是同一包的不同版本确实按时间顺序缓存（Composer 通常如此）
- 注意：此操作不可逆，建议先备份
files/目录或至少ls -l看一眼再执行
composer clear-cache 为什么有时不释放空间？
因为 clear-cache 主要清理 cache/repo/（JSON 元数据）和损坏的 cache/files/ 条目，但不会主动删除“有效但陈旧”的包缓存。如果你长期没运行过该命令，repo/ 可能积压大量过期的 packages.json，而 files/ 里全是“合法”缓存，clear-cache 就视而不见。
OpenClaw 技能 — 给定一个 GitHub 仓库 URL，自动解析出 owner/repo 名称，发现其中的 YAML/properties 配置文件及其配对的中文字段说明；在 `workspace/{repo}/` 目录下按同步日期（格式为 `YYYY-MM-DD`）创建时间戳子目录；写入 `.openclaw-config-state.json` 状态文件。每次用户提问前，先比对远程仓库当前 ref（如 `main` 或 `master`）的最新提交 SHA 与本地状态文件中记录的 SHA：
- 检查
cache/repo/大小：du -sh ~/.composer/cache/repo，常有几百 MB 闲置元数据 - 强制重建元数据缓存：
composer clear-cache && composer update --dry-run（--dry-run避免真实安装，但会触发 repo 刷新） - 若用国内镜像（如阿里云、腾讯云），其
packages.json缓存策略更激进，更容易堆积，此时clear-cache后首次install可能稍慢，属正常
预防缓存爆炸：几个关键配置项
Composer 1.10+ 支持通过环境变量或 config 控制缓存行为，比事后清理更治本。
- 禁用 dist 缓存（省空间，但每次 install 都要重新下载 zip）：
composer config --global cache-dist false - 启用 source 缓存但限制深度（适合经常
composer update的人）：composer config --global cache-vcs true，再配git clone的 shallow clone 行为（需 Git 2.28+） - 设缓存最大尺寸（Composer 2.2+）：
composer config --global cache-max-size "500MiB"，超限时自动 LRU 清理 - 注意：
cache-dist false对 CI/CD 友好，但本地开发频繁切分支时可能变慢；cache-max-size不是硬限制，仅作提示，实际清理仍依赖后续命令触发
缓存目录结构松散、无中心索引，靠时间戳或哈希区分版本，导致“智能清理”很难真正可靠。最稳妥的做法仍是定期 clear-cache + 按需手动修剪 files/，而不是指望某条命令一劳永逸。
