Composer卡在“Loading composer repositories”本质是HTTPS请求Packagist失败，因DNS污染或TLS握手慢导致连接hang死；解决方式是缩短超时、换用国内镜像源并验证代理配置。
composer install/update 为什么会卡在“Loading composer repositories”
本质是 Composer 默认用 HTTPS 请求 Packagist，但国内网络环境下 DNS 污染或 TLS 握手慢，导致连接 hang 死在初始阶段——不是包多，是连不上源。超时默认值（约 300 秒）太长，你等了两分钟才看到报错，实际早该失败重试。
解决方式不是调大 timeout，而是缩短等待阈值并换源：
- 执行
composer config -g repo.packagist composer https://packagist.phpcomposer.com（已失效）或更推荐的：composer config -g repo.packagist composer https://packagist.org+ 配合中国镜像代理（见下条） - 全局启用镜像：
composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/ - 强制缩短单次 HTTP 超时：
composer config -g http-timeout 60（单位秒，别设低于 15，否则小包也容易误杀） - 若仍卡住，加
-vvv看具体卡在哪一步，常见是Resolving dependencies阶段被某个包的composer.json远程读取拖住，此时可临时禁用 packagist 查询：composer install --no-plugins --no-scripts
vendor/autoload.php 不生效？先查 classmap 是否过期
不是 Composer 没加载，是类自动加载映射没更新。Laravel 启动时靠 vendor/autoload.php 中的 ClassLoader 实例查 classmap 或 PSR-4 映射，而 composer require 只改 composer.json 和 vendor/ 目录，不重生成映射表。
典型表现：新装的包里类名能 use，但运行时报 Class not found；或本地 OK，CI 报错——因为 CI 通常只跑 composer install，没触发 dump。
- 立刻修复：
composer dump-autoload（开发时建议加-o生成优化版 classmap） - 确认该包是否声明了 autoload：打开其
vendor/{vendor}/{package}/composer.json，检查是否有"autoload": {"psr-4": {...}}或"classmap"字段 - Laravel 5.5+ 自动发现只对未被
extra.laravel.dont-discover排除的包生效；若包没自动注册 Service Provider，需手动加到config/app.php的providers数组
升级包时出现 “Your requirements could not be resolved”
这不是版本写错了，是 Composer 在解依赖时陷入无限回溯——它尝试了所有可能组合都失败，最后放弃。根本原因是 composer.lock 锁死了旧约束，而新包要求更高版本的 illuminate/* 或 PHP，但当前环境不满足。
不要直接删 lock 文件或跑 composer update 全量升级，那等于重启整个依赖宇宙。
- 精准升级：
composer update vendor/package --with-dependencies，让 Composer 只松动必要路径 - 先看兼容底线：
composer why-not vendor/package:^3.0（替换为你要升的版本），它会告诉你卡在哪一层（比如laravel/framework v10.32.1 requires php ^8.1，而你本地是 8.0.30） - 升级后必做：
php artisan config:clear && php artisan cache:clear，某些包（如spatie/laravel-permission）会在服务启动时缓存策略，不清理会导致权限判断异常 - CI 失败常见于 PHP 版本不一致：本地
php -v是 8.2，CI runner 是 8.1，composer.lock里记录的包版本却依赖 8.2 特性——这时要统一基础环境，而不是改 lock
为什么 Laravel 项目启动变慢？autoload 性能被忽视的细节
Composer 自动生成的 autoload 文件本身没问题，但加载逻辑受 PHP 扩展和配置影响极大。尤其当 APCu 开启但未用于 autoloader 时，每次请求都要重新解析上千个 .php 文件路径。
关键不在“有没有 APCu”，而在“APCu 是否被 autoloader 主动使用”。
- 验证是否启用：
if (extension_loaded('apcu') && ini_get('apc.enabled')) { echo "APCu enabled"; } - 在
public/index.php或bootstrap/autoload.php中，在require vendor/autoload.php后立即加：ComposerAutoloadClassLoader::register(true, 'composer_autoload_'.md5(__DIR__)); - 避免滥用 PSR-4：一个包若只有 3 个类，却声明
"App\Helpers\": "app/Helpers/"，会导致每次new HelperX都去扫描整个目录；应改用classmap或合并进主 autoload - 定期清理无用 autoload：运行
composer remove vendor/unused-package后，记得再dump-autoload -o，否则残留映射仍在
真正卡住 Composer 的，往往不是网络或磁盘，而是开发者没意识到：autoload 是运行时链路的一环，不是安装完就结束的事。每次 php artisan 命令、每个 HTTP 请求，都在走这一套映射逻辑——它既可能被 APCu 加速，也可能因一个没清理的 classmap 条目拖垮整站。
