Composer没有“渲染模式”或“导出无响应”概念，所谓卡死实为install/update/dump-autoload执行阻塞，根源是网络、权限、依赖冲突或PHP环境异常。
Composer 没有“渲染模式”这个概念，也不存在“导出无响应”或“崩溃”的官方功能——你遇到的卡死、假死、长时间无输出，实际是 composer install、composer update 或 composer dump-autoload 在执行过程中被阻塞，根源通常是网络、权限、依赖冲突或 PHP 运行环境异常。
为什么 composer install/update 卡在 “Loading composer repositories” 不动
这不是界面卡顿，而是命令根本没发出去。Packagist.org 直连在国内基本不可达，DNS 解析失败、TLS 握手超时、连接被重置都会导致这一现象。
- 立即切阿里云镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 切完必须清缓存：
composer clear-cache，否则旧失败记录仍会复现 - 若仍卡住，检查 DNS：Docker 环境加
--dns 8.8.8.8；Linux/macOS 可临时改/etc/resolv.conf；Windows WSL 建议用systemd-resolved - 企业内网用户补代理：
composer config -g http-proxy http://10.0.1.100:8080
composer dump-autoload 执行后类还是找不到
composer dump-autoload 本身不报错 ≠ 自动加载生效。它只按 composer.json 的 autoload 配置扫描目录，一旦配置写错，就完全跳过你的代码。
- PSR-4 命名空间末尾必须带反斜杠：
"App\": "src/"✅，"App": "src/"❌（少\就不匹配） - 路径值不能带
./或../："src/"✅，"./src/"❌（Composer 要求纯相对路径，从项目根开始算） - 运行
composer dump-autoload -v，如果第一行就显示Skipping autoload configuration，说明composer.json有硬伤：BOM 头、单引号、注释、多逗号——全删掉重试 - 确认入口脚本真引入了自动加载器：
require __DIR__ . '/vendor/autoload.php';，不是../vendor/autoload.php（路径错位会导致整个加载器失效）
composer update 报错后反复重试仍失败
“Your requirements could not be resolved” 是逻辑无解，不是网络或缓存问题。删 vendor、重跑 install 或清缓存，只会重复失败。
- 先查谁拦路：
composer why-not php:8.3（把 8.3 换成你要的版本），输出最后一行是你写的composer.json，第一行是封杀者 - 检查
require-dev：很多冲突来自phpunit/phpunit或orchestra/testbench锁死了旧版laravel/framework - 看真实依赖树：
composer show --tree | head -20，比composer.json更可信；过滤某包：composer show --tree monolog/monolog | grep guzzlehttp - 升级单个包务必加
--with-dependencies：composer update monolog/monolog --with-dependencies，否则子依赖不动，新版本大概率跑不起来
Docker 容器里 composer install 极慢甚至失败
慢和失败常混在一起，但原因完全不同：慢多因挂载性能差，失败多因权限或扩展缺失。
- 别用
-v $(pwd):/app直接挂载源码进容器跑install——macOS/Windows 上文件桥接 I/O 极差，vendor写入可能卡数分钟 - 正确做法：用命名卷缓存
vendor：docker run -v $(pwd):/app -v composer-vendor:/app/vendor image composer install - 确保容器内装了必要扩展：
zip、openssl、phar和系统工具git、unzip，缺一个都可能静默失败 - 权限陷阱：宿主机目录属主是
root，容器内用户没写权限。验证方式：docker exec -it container ls -ld /app/vendor；修复：启动前chown -R $USER:$USER .
最易被忽略的一点：所有“崩溃”“无响应”背后，几乎都藏着一个未显式报错的前置条件——PHP CLI 版本与 composer.json 中 php 字段不一致、扩展缺失、或 composer.lock 被手动改坏。不要盯着“卡住”本身，先用 php -v、php -m | grep -E "mbstring|openssl"、composer validate 过一遍基础环境。
