答案是执行composer install前必须确保composer.lock存在且兼容，否则会静默失败或拉错版本；Hyperf中install本质是按lock还原依赖树，缺失lock、镜像未生效或未加--no-dev均会导致启动异常如Segmentation fault或Class not found。
执行 composer install 前必须确保 composer.lock 存在且与当前 composer.json 兼容，否则会静默失败或拉错版本——这不是网络慢，是依赖解析被跳过。
为什么 composer install 在 Hyperf 里经常“没反应”或报错？
Hyperf 项目中 composer install 不是单纯装包，它要严格按 composer.lock 还原依赖树。常见卡点：
-
composer.lock缺失或格式损坏 → Composer 会尝试生成新 lock，但若composer.json里有不兼容约束（比如"hyperf/framework": "^3.4"和"php": ">=8.0"冲突），直接卡在Resolving dependencies - 镜像未生效 → 静默回退到 packagist.org，国内环境常卡住或超时；验证方式：运行
composer config -g repo.packagist，输出必须是完整 JSON：{"type":"composer","url":"https://mirrors.aliyun.com/composer/"} - 全局配置写错键名（如
repos.packagist）、type 值非composer、URL 少末尾/→ 全部静默失效，不会报错
composer install --no-dev 是启动 Hyperf 的硬性前提
Hyperf 启动失败（Segmentation fault / Class not found / 静默无输出）90% 源于没走这步：
-
composer install --no-dev会跳过require-dev中的包（如 phpunit、phpstan），避免 dev-only 类被 autoload 加载干扰协程环境 - 若只跑
composer install（带 dev 包），bin/hyperf.php启动时可能因注解扫描器加载了 dev 工具类而崩溃 - 生产部署必须加
--no-dev；开发环境可先composer dump-autoload -o确保 PSR-4 映射正确，再启动
执行后 vendor 目录结构异常？检查三个关键点
Hyperf 官方组件（如 hyperf/http-server）在 vendor/hyperf/xxx 下应有 src/ 目录，若为空或只有 composer.json，说明安装过程被中断或镜像返回了错误 dist 包：
- 确认
composer.lock中任意hyperf/xxx条目的dist.url字段是否为镜像地址（如https://mirrors.aliyun.com/composer/dists/...）；不是则说明镜像未参与本次 install - 删掉
vendor/和composer.lock，再执行composer update --lock强制重写 lock 文件中的 dist URL - 避免手动
composer require hyperf/xxx单个组件——极易引发版本错位；新功能优先通过composer create-project hyperf/hyperf-skeleton:3.1.25初始化骨架项目
Hyperf 对 Composer 的依赖解析极其敏感，install 行为本质是“还原”，不是“安装”。任何对 composer.lock 的忽略、对镜像配置的将就、或对 --no-dev 的绕过，都会在启动时以不可预测的方式爆发——往往不是报错，而是静默失败。
