是，换镜像不能解决本地缓存问题；需确认cache-dir存在可写、未禁用缓存、权限正确，并合理配置代理或优化dist/source策略。
composer install 速度慢，是不是该换镜像？
不是换镜像就能解决缓存问题。国内镜像（如阿里云、腾讯云）只是把 packagist.org 的包同步过来，它不帮你缓存你本地反复拉的 dev 版本、private 包、或你正在调试的 path 类型依赖。真卡在反复下载，大概率是没启用本地 cache，而不是镜像选得不对。
怎么确认 composer 正在用本地缓存？
运行 composer config --global cache-dir，看输出路径是否存在且可写；再执行一次 composer clear-cache 后立刻 composer install，观察首次下载后第二次是否跳过下载步骤——如果仍重下，说明缓存没生效，常见原因：
-
cache-dir被设成/dev/NULL或只读路径 - 项目里写了
"config": { "cache-dir": false }，直接关掉了缓存 - 用了
--no-cache参数（CI 脚本里容易漏掉） - PHP 进程用户（如 www-data）对缓存目录无写权限
想用代理缓存（比如 Nexus、Satis），要改哪些配置？
Composer 本身不内置代理服务，所谓“代理缓存”其实是用外部 http 代理拦截并缓存 vendor 包请求。关键不是改 composer.json，而是设环境变量或全局 config：
- 设
http_proxy和https_proxy环境变量指向你的缓存代理地址（如http://127.0.0.1:8081） - 必须同时配
no_proxy="packagist.org,repo.packagist.org"，否则镜像源请求也被转发，反而绕过镜像 - 禁用 Composer 自带的 HTTPS 验证（仅限内网可信代理）：
composer config --global disable-tls true，否则会因证书失败退回到直连 - 代理服务本身需支持
Cache-Control和 304 响应，否则 Composer 每次都当新包处理
本地开发频繁切分支/改 composer.json，怎么避免重复下载？
靠镜像或代理都不如直接复用已下载的 dist 包。Composer 默认会把 zip 包解压进 vendor，但源码（source）和压缩包（dist）是分开缓存的。高频调试时建议：
- 始终用
composer install --prefer-dist（默认行为），别加--prefer-source - 在
composer.json里为私有包显式指定"dist": { "url": "..."}，避免每次走 git clone - 用
path类型依赖时，确保目标目录有composer.json且 version 字段固定（别写dev-main），否则 Composer 认为是新版本，强制重 fetch - CI 中可提前
composer install --no-scripts+composer dump-autoload -a，跳过脚本执行节省时间
缓存机制依赖文件哈希和 lock 文件精确匹配，composer.lock 里任何一行变动（哪怕只是空格），都可能让缓存失效——这点最容易被忽略。