Composer是PHP项目级依赖求解工具，核心为SAT求解器在版本约束空间中寻找数学可行解；composer.lock是该解的确定性快照，vendor仅为可重建产物。
Composer 不是“装包工具”，而是 PHP 项目构建的决策引擎——它决定哪些版本能共存、哪些类在哪儿加载、哪些代码真正进入生产环境。掌握它，等于掌握了现代 PHP 应用的启动逻辑和运行边界。
依赖求解：快慢不在下载，而在数学计算
composer install 卡在 Resolving dependencies？这不是网络问题，是本地 CPU 正在暴力穷举所有可能的版本组合。常见诱因包括：
- 写了
"minimum-stability": "dev"，让求解器主动纳入大量不稳定版本 - 依赖声明含冲突逻辑，例如同时 require
guzzlehttp/guzzle:^7.0和^8.0 - 删掉了
composer.lock文件，导致每次 install 都退化为 update - 启用了 xdebug（会让求解慢 5–10 倍），或未禁用插件干扰
安装提速：关掉默认冗余动作比换镜像更关键
实测从 3 分钟压到 30 秒内，核心不是加速下载，而是跳过非必要环节：
-
--no-dev：跳过require-dev中全部包（如 phpunit、phpstan），省 30–60% 时间 -
--prefer-dist：强制走 ZIP 包而非 Git clone（需配合镜像源才生效） -
--optimize-autoloader：生成扁平类映射，避免 PSR-4 运行时路径扫描 -
--classmap-authoritative：告诉 autoloader “找不到就真没有”，不 fallback 到文件系统（仅用于生产/CI）
完整命令示例：composer install --no-dev --prefer-dist --optimize-autoloader --classmap-authoritative
立即学习“PHP免费学习笔记（深入）”；
全局配置：一劳永逸影响所有项目
这些设置写入全局 config，优先级高于项目级，建议一次配齐：
- 镜像源：
composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/ - 缓存目录（务必指向 SSD）：
composer config -g cache-dir ~/.composer/cache - 自动丢弃变更（防 CI 卡住）：
composer config -g discard-changes true - 并发下载数（Composer 2.2+）：
composer config -g parallel-downloads 8（建议设为 CPU 核心数 × 1.5，上限 12）
设完别忘了清缓存：composer clear-cache
autoload：不是拼文件，而是建映射表
vendor/autoload.php 是 Composer 构建的加载策略中心，背后是三类映射机制：
-
PSR-4：前缀 → 目录映射，如
"Monolog\": "src/"→ 加载MonologLogger时自动找src/Logger.php - classmap：扫描后生成的全量类名 → 文件路径数组，适合无命名空间的老库
- files：直接 require 指定 PHP 文件，常用于函数库
修改 autoload 后必须运行 composer dump-autoload，否则新增类不会被识别。
