执行 composer clear-cache 后需三步验证：先用 composer config --global cache-dir 确认真实路径；再检查该路径下 files/ 和 repo/ 子目录是否为空；最后运行 composer install --no-cache -v，若出现大量 Downloading 而非 Using cache 或 Extracting from cache，且无 Corrupted zip 报错，说明缓存已清干净。
执行 composer clear-cache 后怎么确认真清干净了
它只删 ~/.composer/cache/（Linux/macOS）或 %APPDATA%\Composer\Cache（Windows）下的 files/、repo/、vcs/ 子目录，不碰 vendor/ 或 composer.lock。但很多人执行完发现磁盘没变、日志还显示 Using cache，本质是没验证到位。
验证分三步走：
- 查路径是否真实：运行
composer config --global cache-dir，别信默认路径——公司镜像、COMPOSER_CACHE_DIR环境变量都可能改掉它 - 看目录是否空：Linux/macOS 用
ls -la $(composer config --global cache-dir)；Windows 进资源管理器粘贴路径后右键“属性”，重点确认files/和repo/两个子目录大小为 0 或不存在 - 跑一次带日志的安装：
composer install -v，盯紧输出里有没有Downloading字样。如果仍看到Using cache或Extracting from cache，说明缓存没清净，或者 Composer 正在读别的地方（比如sys_get_temp_dir()下残留的composer_*.zip）
为什么 composer install -v 日志里还有 Using cache
不是清理失败，而是 Composer 默认会复用 vendor/ 里的已安装包，哪怕缓存全空，只要 vendor/ 还在，它就跳过下载和解压。这跟缓存清理无关，是设计行为。
真正要测缓存是否生效，得配合 --no-cache 强制绕过所有本地缓存路径：
-
composer install --no-cache -v—— 如果这时出现大量Downloading https://...，说明缓存已清空且命令生效 - 如果仍秒完成，检查是否漏删了
vendor/或composer.lock：它们会让 Composer 直接复用已安装状态，根本不会触发下载逻辑 - CI 环境中尤其注意：Docker 构建时若挂载了宿主机缓存目录，
clear-cache只清容器内路径，实际缓存还在宿主机上
如何验证 metadata 缓存是否刷新成功
metadata 缓存滞后最典型的表现是 composer update 拉不到 Packagist 上刚发布的版本。光清 files/ 不够，必须确认远程索引被重拉。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
验证方式很直接：
- 删完缓存后，跑
composer update --dry-run -v - 紧盯日志开头几行：出现
Curl GET https://packagist.org/packages.json或类似Downloading https://mirrors.aliyun.com/.../packages.json，说明 metadata 正在重取 - 如果日志里只有
Reading /packages.json from cache，说明~/.composer/cache/repo/https---packagist.org/没清干净，得手动rm -rf掉那个目录 - 顺手检查
composer.lock里对应包的dist.sha256值是否更新——没更新就代表锁文件没同步，后续安装照样失败
临时目录残留 ZIP 文件常被忽略
composer clear-cache 完全不碰系统临时目录：/tmp（Linux/macOS）或 %TEMP%（Windows）。而 Composer 下载 ZIP、解压、重命名全过程都在这里做。磁盘满、解压失败、Corrupted zip file 报错，80% 是这儿卡住。
必须额外检查：
- Linux/macOS：
ls -lh /tmp/composer_*.zip 2>/dev/null || echo "no composer temp zip" - Windows：
dir %TEMP%\composer_*.zip，常见路径是C:\Users\XXX\AppData\Local\Temp\ - 如果发现一堆几百 MB 的
composer_*.zip，直接删：rm /tmp/composer_*.zip或del %TEMP%\composer_*.zip - 长期方案：设环境变量
TMPDIR="/mnt/bigdisk/tmp"（Linux/macOS）或set TMP=%USERPROFILE%\tmp（Windows），再mkdir -p并赋权
缓存清理不是一锤子买卖，验证的关键在于盯日志、看路径、分清楚 cache、vendor、temp 三块地盘各自管什么。漏掉任何一块，都会让“已清理”变成假象。
