Composer仅执行PSR-4自动加载配置，不校验PSR-12风格；PSR-4要求命名空间末尾双反斜杠（如"App": "src/"），改配置后须运行composer dump-autoload，且仅支持类/接口/特质/枚举加载。
Composer 本身不强制你写符合 PSR 的代码，但只要你用它管理依赖、生成自动加载、发布到 Packagist，就绕不开 PSR——尤其 PSR-4。不理解 PSR，composer dump-autoload 就像在黑盒里按按钮，出问题时连日志都看不懂。
PSR-4 是 Composer 自动加载的“语言”，不是可选项
Composer 的 autoload 配置不是自由发挥的映射规则，它直接翻译成 PSR-4 定义的命名空间→路径逻辑。比如你在 composer.json 写：
"autoload": {
"psr-4": {
"App\": "src/"
}
}
这行配置生效的前提是：所有 App* 命名空间下的类，必须落在 src/ 下对应子目录中，且文件名与类名严格一致（AppControllerHome → src/Controller/Home.php）。否则 vendor/autoload.php 会静默失败，报错却是 Class 'AppControllerHome' not found。
- PSR-4 不是“建议风格”，它是 Composer 加载器解析路径的硬编码逻辑
- 你删掉
composer.json里的psr-4段，或写错反斜杠（App写成App/），composer dump-autoload仍会成功，但运行时必报错 - PSR-0 已废弃，Composer 仍兼容，但新项目用它等于主动放弃性能和未来支持
为什么 PSR-7/PSR-11/PSR-16 这些“接口标准”也得懂
这些 PSR 不管自动加载，但它们定义了“包之间怎么说话”。如果你在项目里 require 一个 HTTP 客户端，又想换另一个，就得看它是否实现 psr/http-client-implementation（即 PSR-18）；如果要用缓存，就得确认组件声明了 psr/cache-implementation（PSR-6 或 PSR-16）。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
立即学习“PHP免费学习笔记（深入）”；
- Composer 安装的是包，但真正决定能否替换、复用、组合的，是包是否遵循 PSR 接口契约
- 框架如 Laravel 的
CacheManager、Symfony 的HttpClient都只依赖 PSR 接口，不绑定具体实现——没 PSR，这种解耦就不存在 - 你在
composer.json的require里看到"psr/log": "^3.0"，这不是一个“库”，而是一组接口定义，实际干活的是monolog/monolog这类实现
不学 PSR 的典型翻车现场
很多开发者直到部署失败或 CI 报错才意识到 PSR 不是“理论课”：
- 本地开发用
composer require myorg/utils，但该包的composer.json没配autoload，也没声明psr-4，结果vendor/autoload.php根本不认它的类 - 写了个私有组件上传到内部 Packagist，别人
require后报Class not found，查半天发现你用了files加载全局函数，却没在composer.json显式声明"autoload": {"files": ["helper.php"]} - 升级 PHP 版本后，
composer install成功，但运行时报Attribute类不存在——因为你的包依赖了 PHP 8.2+ 的#[Attribute]，而composer.json没设"platform": {"php": "8.2"}，导致 Composer 没在安装阶段校验
PSR 规范不是文档墙，而是 Composer 生态的“接线图”。你看不懂 psr/http-message，就无法判断两个中间件能不能串在一起；你不清楚 PSR-4 路径映射，就只能靠 var_dump(get_included_files()) 猜 autoload 到底加载了谁。它不增加功能，但决定了功能能不能被安全地组装起来。
