直接运行 composer clear-cache --expired 可安全清理超期 zip/tar 包，仅作用于 files/ 子目录，不触碰 repo/ 和 vcs/，避免首次安装变慢；执行前须用 composer config --global cache-dir 确认路径并核查大小，不足 200mb 无需清理。
定时清理前先确认缓存路径和实际占用
别直接写 cron 脚本。先跑 composer config --global cache-dir 看真实路径，再用 du -sh $(composer config --global cache-dir)（Linux/macOS）或右键属性（Windows）查大小。不到 200MB 的缓存不值得每周清——它本身就在自动淘汰，cache-files-ttl 默认是 180 天，不是“永久存”。真正该盯的是 files/ 子目录，它占缓存 90% 以上空间。
用 composer clear-cache --expired 替代全量清空
composer clear-cache --expired 只删 files/ 下修改时间超 cache-files-ttl 的 ZIP/TAR 包，不影响 repo/（元数据）和 vcs/（Git 克隆），也不会让下次 install 变慢。它等价于：
find ~/.composer/cache/files -name "*.zip" -o -name "*.tar.gz" -mtime +180 -delete
但更安全：Composer 自己处理文件锁和路径拼接，Windows 也能用。执行前可加 --dry-run 预览：composer clear-cache --expired --dry-run。
crontab 示例与关键避坑点
Linux/macOS 下每周日凌晨 2 点执行（避免白天构建冲突）：
0 2 * * 0 /usr/bin/composer clear-cache --expired >/dev/null 2>&1
- 必须用绝对路径调用
composer，否则 cron 环境找不到命令 - 重定向
/dev/null避免邮件堆积，尤其在无 MTA 的 Docker 容器里 - 不要加
sudo—— 如果缓存属主是 root，说明之前用过sudo composer install，得先chown -R $USER ~/.composer/cache - CI/CD 构建机上禁用此定时任务，因为每次构建都是干净环境，
~/.composer/cache基本为空
为什么不用 post-install-cmd 做定时清理
post-install-cmd 是按需触发的钩子，不是定时器。它只在 composer install/update 后跑一次，且运行时可能正在写缓存，强行清理会触发 Corrupted cache file 报错。真正的定时清理必须脱离 Composer 主流程，在系统级静默执行——这也是为什么所有可靠部署方案都把缓存清理交给 cron、systemd timer 或 CI 的 cleanup stage，而不是塞进 scripts 字段。
