Composer install 卡在 Resolving dependencies 主因是依赖解析策略保守、OPcache 未启用、composer.lock 缺失或私有源配置错误；应确保锁文件提交、设 minimum-stability 为 stable、启用 OPcache、检查并清理仓库配置。
为什么 composer install 总是卡在 Resolving dependencies
这不是网络慢，而是 Composer 默认启用的依赖解析策略过于保守：它会尝试所有可能的版本组合来满足 composer.json 中所有约束，尤其当项目含大量私有包、模糊版本号（如 ^1.0 || ^2.0）或未锁定 composer.lock 时，耗时呈指数级增长。更隐蔽的问题是 PHP 的 OPcache 未预热或 CLI 模式下被禁用，导致每次解析都重新编译大量 Composer 自身代码。
- 确保
composer.lock始终提交到 Git —— 跳过解析，直接安装已知兼容版本 - 把
minimum-stability设为stable，避免自动拉取dev-或alpha分支触发额外校验 - 运行前加
php -d opcache.enable_cli=1（PHP 7.4+ 默认开启，但某些 Docker 镜像或自定义 ini 会关掉）
换镜像源没用？检查 composer config 是否被覆盖
国内用户常配阿里云或腾讯云镜像，但实际生效需确认三层配置优先级：命令行参数 > 当前项目 composer.json > 全局 config.json。最易踩的坑是项目根目录存在 composer.json 里写了 "repositories"，且其中某条指向了已下线的私有源，Composer 会逐个尝试超时后才 fallback，拖慢整条链路。
- 执行
composer config --list --global和composer config --list对比，看实际生效的repositories - 临时禁用所有自定义源：用
composer install --no-plugins --repository=https://packagist.org - 若必须用私有源，确保其
packages.json支持providers-url和provider-includes，否则无法跳过全量元数据下载
composer install 比 update 慢？那是你没用对命令
install 本应比 update 快得多，因为不涉及版本解析。但如果 composer.lock 里记录的包在当前源不可达（比如私有包域名变更、认证失效），Composer 会退化成边查边装，行为接近 update。另一个常见原因是启用了 --with-all-dependencies 或 --ignore-platform-reqs，这会让 Composer 绕过缓存并重新校验所有依赖树。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 始终先跑
composer validate --strict，确认lock文件格式合法且无缺失哈希 - CI 环境中固定使用
composer install --no-interaction --no-progress --optimize-autoloader，禁用交互和进度条可减少 I/O 开销 - 避免在生产部署中混用
install和update—— 同一项目只允许update在开发机执行，install在服务器执行
Autoload 优化不是锦上添花，而是安装阶段就决定的
很多人以为 autoload 优化只影响运行时，其实 composer dump-autoload 的结果直接影响 install 后首次请求的冷启动时间，而这个过程在 install 阶段已由 --optimize-autoloader 触发。如果项目含大量 PSR-0/PSR-4 混用、动态注册或 classmap 扫描路径过宽，生成的 autoload_classmap.php 会极大拖慢安装后的第一次加载。
- 在
composer.json的"autoload"中显式声明"exclude-from-classmap"，过滤测试文件、旧版兼容层等非运行时代码 - 用
"psr-4"替代"psr-0"（后者已被废弃），并确保命名空间与路径严格匹配，避免 fallback 查找 - CI 中加一步验证：
composer dump-autoload --no-scripts && php -l vendor/autoload.php，防止生成损坏的 autoload 文件阻塞后续流程
真正卡住安装的，往往不是网络或磁盘，而是配置错位、锁文件腐化、或 autoload 规则隐式膨胀。这些点不显眼，但改一行 composer.json 或删一个无效仓库配置，就能从 5 分钟降到 20 秒。
