在宝塔面板中使用计划任务定期清理Composer镜像缓存的脚本-composer-PHP中文网

不能直接用 composer clear-cache 塞进宝塔计划任务，因其会因环境缺失、权限错乱或并发冲突静默失败，甚至误删其他用户缓存；必须先确认缓存真实路径与归属用户，再用 find 按时间+空目录安全清理 dist/source，避开 repo 目录，并在脚本中指定绝对路径、用户权限及日志防护。

在宝塔面板中使用计划任务定期清理composer镜像缓存的脚本

不能直接用 composer clear-cache 塞进宝塔计划任务——它会因环境缺失、权限错乱或并发冲突静默失败，甚至删掉其他用户的缓存。

确认 Composer 缓存的真实路径和归属用户

宝塔里多个 PHP 站点可能共用一个全局缓存，也可能各自写到不同位置。不查清就删，风险极高。

先用对应用户身份查路径：sudo -u www /usr/local/bin/composer config --global cache-dir（把 www 换成你网站实际运行用户）
常见路径不止 $HOME/.composer/cache：可能是 /www/wwwroot/example.com/.composer/cache 或 /root/.composer/cache
用 ls -ld $(sudo -u www composer config --global cache-dir) 看目录属主，后续脚本必须用同一用户执行
别信“所有项目都走全局缓存”——某些项目在 composer.json 里写了 "config": {"cache-dir": "./.composer/cache"}，缓存就在项目内

用 find 安全清理过期的 dist/source 包文件

composer clear-cache 是粗暴清空，而镜像缓存里大量 dist 和 source 目录其实可按时间筛选：旧版本包下载后长期不用，占空间却不参与当前构建。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

先预览要删什么：find /root/.composer/cache/dist -type d -mtime +30 -name "*" | head -10
真正清理命令示例（以 root 用户为例）：find /root/.composer/cache/dist -mindepth 1 -type d -mtime +30 -empty -delete
加 -empty 是关键：只删空目录，避免误删正在解压中的临时包
source 目录同理处理，但别碰 repo（含包元数据），否则下次 composer install 要重新 fetch 全量索引
如果缓存路径属 www 用户，命令前必须加 sudo -u www，否则权限拒绝且无报错

宝塔计划任务里怎么填这个脚本

直接粘贴命令进「Shell 脚本」框就行，但得绕开三个坑：

不写相对路径：cd ~ 会失败，因为宝塔 cron 工作目录是 /root，所有路径用绝对路径
不依赖 $PATH：脚本开头显式指定解释器和 composer 路径，例如：/usr/local/bin/composer（用 which composer 确认）
加日志和防护判断：避免重复执行或空路径导致误删

#!/bin/bash
CACHE_DIR="/root/.composer/cache"
if [ ! -d "$CACHE_DIR" ]; then
  echo "$(date): cache dir not found" >> /var/log/composer-clean.log
  exit 1
fi
find "$CACHE_DIR/dist" -mindepth 1 -type d -mtime +30 -empty -delete 2>>/var/log/composer-clean.log
find "$CACHE_DIR/source" -mindepth 1 -type d -mtime +30 -empty -delete 2>>/var/log/composer-clean.log

为什么不能只靠 composer clear-cache --dry-run 预览

--dry-run 只告诉你“打算清哪个目录”，但不告诉你该目录下哪些子目录实际已失效、哪些正被其他项目引用。它无法识别 dist 中某版本包是否还在 composer.lock 里被依赖。

手动跑 composer clear-cache --dry-run 输出的路径，可能包含当前项目仍在用的 source 快照
并发风险：若另一个终端正执行 composer update，clear-cache 可能中途删掉它正在写的临时文件，触发 Corrupted cache file
更稳妥的做法是：用 find 按时间 + 空目录双条件删，既避开活跃包，又不依赖 Composer 内部状态

真正容易被忽略的是：Composer 缓存不是“越清越快”，而是“清错就变慢”。删掉 repo/ 下的 packages.json 后，首次 composer install 会多花 2–5 秒拉取元数据——这在 CI/CD 或部署时就是雪崩起点。