镜像未生效是composer变慢主因，需先验证composer config -g repo.packagist输出是否为正确json格式且url末尾无斜杠，再结合-vvv日志确认请求域名是否为镜像站。
Composer 命令变慢，90% 不是缓存没清，而是镜像根本没生效——清缓存本身不会加速命令执行，除非你先确认并修复了源配置。
为什么 composer clear-cache 后 install/update 还是慢？
缓存清理只影响“下载和解压”阶段，不影响“依赖解析”和“元数据拉取”。如果 composer install 卡在 Loading composer repositories with package information，说明 Composer 正在反复请求 packagist.org 或错误镜像，而不是读缓存。
- 运行
composer config -g repo.packagist，输出必须是类似{"type": "composer", "url": "https://mirrors.aliyun.com/packagist"}—— 如果是{"type": "composer", "url": "https://packagist.org"}或空，镜像就没生效 - 键名必须是
repo.packagist（单数），不是repos.packagist（复数），拼错就写进无效字段 - URL 末尾不能带斜杠，
https://mirrors.tuna.tsinghua.edu.cn/packagist/会静默失败，正确写法是https://mirrors.tuna.tsinghua.edu.cn/packagist - 验证是否真正接管：加
-vvv执行composer show -p，第一行必须显示你的镜像地址，且日志里不再出现packagist.org
clear-cache 真正能加速的场景只有这三种
缓存清理对性能有实际帮助，仅限于以下明确可复现的情形：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer update卡在Extracting archive并报Corrupted zip file：损坏 ZIP 被反复复用，删对应~/.composer/cache/files/下的包归档即可，不用全清 - 切换 PHP 版本后，旧扩展缓存（如
ext-redis的 .so/.dll）残留导致composer install检查失败：此时clear-cache会清掉repo/中的平台约束快照，避免误判 - 公司私有仓库 URL 变更（如从 HTTP 改 HTTPS），但本地
repo/缓存仍指向旧地址：清缓存迫使 Composer 重新拉取最新packages.json
执行 clear-cache 时最容易踩的坑
命令看似简单，但权限、路径、上下文常让效果打折：
- Windows 上用 PowerShell 运行
composer clear-cache，~不自动展开，建议先用composer config --global cache-dir确认路径再操作 - IDE（如 PhpStorm）后台常驻 Composer 进程，会锁住缓存文件，导致
Permission denied；关掉 IDE 再试，或加-v看具体卡在哪条路径 - CI/CD 环境中不加
--no-interaction，命令会卡在交互确认，直接超时；推荐固定写法：composer clear-cache --no-interaction --dry-run先预检路径，再执行 - 用 snap 安装的 Composer（Ubuntu 默认），缓存被沙盒隔离，
clear-cache根本触达不到真实位置，只能手动删/var/snap/composer/common/cache/
比 clear-cache 更有效的长期提速方式
频繁清理缓存是治标，改配置才是治本。以下三项调整见效更快、副作用更小：
- 设大一点的缓存体积上限：
composer config --global cache-files-maxsize "1G"，避免 Composer 频繁触发垃圾回收 - 延长压缩包缓存时间：
composer config --global cache-files-ttl 2592000（30 天），减少重复下载 - 启用只读缓存（容器/CI 场景）：
composer config --global cache-read-only true，跳过写入校验，降低 I/O 开销
真正卡顿的根源往往不在缓存目录本身，而在每次命令启动时都要重建的内存级元数据——这些无法被 clear-cache 触及，也解释了为什么清完缓存，composer --version 依然慢半拍。
