composer clear-cache 在虚拟主机中基本不可用，因权限限制无法写入 ~/.composer/cache 且禁用系统命令，实际应聚焦项目级缓存控制与 /tmp 临时文件清理。
composer clear-cache 在虚拟主机中基本不可用——多数共享主机禁用写入 ~/.composer/cache，且无法执行系统级清理命令。真正能动手的，只有项目级缓存控制和临时文件干预。
为什么 composer clear-cache 在虚拟主机里大概率失败
虚拟主机通常限制以下行为：
- 禁止用户主目录（
~）下创建或写入.composer/目录，composer config --global cache-dir会报 Permission denied 或静默 fallback 到/tmp - 禁用
exec()、shell_exec()等函数，导致clear-cache内部调用的rm -rf或unlink()失效 -
/tmp分区常被设为只读，或配额极小（如 128MB），而 Composer 默认把 ZIP 解压、packages.json快照全扔进去 - 没有权限运行
sudo或修改环境变量COMPOSER_CACHE_DIR
如何在配额内强制跳过缓存写入
核心思路：不让 Composer 写任何缓存，所有操作走“无状态”模式。
- 每次安装都加
--no-cache：composer install --no-cache --no-dev --prefer-dist，它跳过读取本地repo/和files/，但仍会在sys_get_temp_dir()（通常是/tmp）解压 ZIP，这点无法绕过 - 手动指定临时目录到可写子目录：
COMPOSER_CACHE_DIR=./.composer-cache composer install --no-cache，前提是当前项目目录可写，且空间足够（建议先mkdir .composer-cache && chmod 700 .composer-cache） - 禁用 VCS 克隆（省掉最占空间的裸仓库）：
composer config --global cache-vcs false，但虚拟主机可能不让你写全局配置，那就改项目级：composer config cache-vcs false，再进composer.json加"config": {"cache-vcs": false}
清理 /tmp 下残留的 Composer 临时文件
这才是虚拟主机里最实际、最常见效的操作点——clear-cache 不管这里，但 Composer 每次下载 ZIP、解压 PHAR 都会往 /tmp 塞 composer_*.zip、php*.phar、composer_dist_* 等文件，积少成多直接撑爆配额。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 登录后先查：
ls -la /tmp/composer* | head -10（如果 shell 可用），或通过 FTP 进入/tmp手动删以composer_、php开头的文件 - 找不到
/tmp？试试echo sys_get_temp_dir();新建一个 PHP 文件执行，确认真实路径（常见于 cPanel 的/home/username/tmp） - 自动化清理（如支持 cron）：
find /tmp -name "composer_*" -mmin +60 -delete 2>/dev/null，删掉 1 小时前的临时包
真正省配额的长期做法
别指望定期“清”，要从源头压缩单次操作的磁盘足迹：
- 用
--prefer-dist强制走 ZIP 包，避免 Git 克隆（--prefer-source在虚拟主机根本跑不通） - 删掉
vendor/bin/里不用的二进制（如phpunit、phpstan），它们自带依赖树，体积不小 - 项目部署后立即删
composer.lock以外的所有开发相关文件：rm -rf vendor/*/{tests,Tests,docs,Documentation}（需 shell 权限） - 如果连
vendor/都放不下，考虑用composer create-project --no-install+ 手动dump-autoload -o，跳过完整安装流程
虚拟主机的缓存问题本质是权限与配额的双重压制，clear-cache 是个伪命题；盯紧 /tmp 和 vendor/ 的实际写入点，比反复尝试全局命令有效得多。
