composer是项目级依赖管理工具，pear是系统级安装工具；composer通过vendor目录隔离依赖、支持语义化版本与sat求解、自动加载及packagist生态，而pear缺乏依赖解析、版本管理混乱、生态萎缩且已被php官方弃用。
Composer 没有“库架构演进”这个概念——它本身不是库，而是依赖管理工具；所谓“演进”，实质是其设计范式倒逼 PHP 生态重构标准、组织方式与协作流程。
PEAR 全局安装机制为何必然被淘汰
PEAR 把所有包装到系统级目录（如 /usr/share/php），导致：
• 多个项目共用同一份 Mail 或 DB 类，但 A 项目需要 v1.2，B 项目依赖 v2.0 → 直接报 Class 'MDB2' not found 或方法不存在
• 安装常需 sudo pear install，CI 环境无法无权执行，Docker 构建失败率高
• PHP 5.3 之前无命名空间，PEAR::setErrorHandling() 和自定义 setErrorHandling() 冲突频发
• 无 composer.lock 类机制，pear upgrade 后环境不可复现
Composer 的 vendor/ 目录结构如何强制 PSR-4 落地
Composer 不生成类文件，而是生成 vendor/autoload.php，它依赖包作者在 composer.json 中声明：
• "autoload": { "psr-4": { "Monolog\": "src/" } }
• 运行 composer dump-autoload 后，Monolog\Logger 自动映射到 vendor/monolog/monolog/src/Logger.php
• 若包未声明 autoload 或路径不匹配，new Monolog\Logger 就会触发 Fatal error: Class 'Monolog\Logger' not found
• 框架如 Laravel 强制要求扩展包提供 PSR-4 映射，否则 composer require 后根本无法实例化——这不是约定，是加载器的硬性校验
composer.json 的 require 字段怎样成为事实上的接口契约
当一个框架（如 Symfony）在 composer.json 中写：
• "require": { "php": "^8.1", "ext-mbstring": "*", "doctrine/cache": "^2.0" }
它实际在声明：
• 运行环境必须满足 PHP 版本 + 扩展可用性，否则 composer install 直接终止并报错 Your requirements could not be resolved
• doctrine/cache v2.x 的接口（如 CacheItemPoolInterface）就是该框架的调用契约，v3.x 若破坏兼容，Composer 解析时就会拒绝安装
• 第三方包若想被 Symfony 兼容，必须实现相同接口并发布到 Packagist，否则 composer require 会因版本约束不匹配失败
packagist.org 如何用 metadata 替代人工文档同步
Packagist 不托管代码，只抓取 GitHub 仓库的 composer.json 并解析：
• name 字段决定包唯一标识（monolog/monolog），而非 URL 或 ZIP 名
• type 字段（如 library、symfony-bundle）触发不同安装逻辑，Laravel 的 package:discover 钩子只扫描 type=laravel-package 的包
• autoload 和 require 字段实时生成依赖图谱，搜索 “cache” 时返回结果已按 PHP 版本、是否支持 PHP 8.5、是否含 ext-redis 过滤
• 文档链接、GitHub stars、下载量全部来自元数据自动聚合，不再靠作者手动更新 README
真正推动标准化的从来不是规范文档，而是工具链的刚性约束——Composer 让不符合 PSR-4 的包无法加载，让未声明 require 的扩展无法被框架识别，让没提交到 Packagist 的代码等于不存在。这种“不配合就无法运行”的机制，比任何倡议都更彻底地重塑了 PHP 生态。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
