Composer 本身不支持运行时按需加载依赖，但可通过 PSR-4 自动加载+类文件分离+条件检测实现逻辑上的按需加载；关键在命名空间与路径严格匹配、避免 classmap 和 files 全局加载、合理使用 require-dev 与运行时存在性判断。
Composer 的“按需加载依赖”本质上是个常见误解——它本身不支持运行时按需加载包，但可以通过 autoload 配置 + PSR-4/PSR-0 自动加载机制 + 条件性 require 控制来实现“逻辑上的按需加载”。关键在于：不是 Composer 做了什么魔法，而是你如何组织代码和配置自动加载规则。
如何用 autoload 实现类级别的按需加载
Composer 的自动加载器只在首次使用某个类时才加载对应文件（延迟加载），这是默认行为。只要类名与文件路径严格匹配 PSR-4 规则，就能做到“用到才加载”。
-
composer.json中的"autoload": {"psr-4": {"App\\": "src/"}}是基础，确保App\Foo\Bar类映射到src/Foo/Bar.php - 不要把所有类都塞进一个大文件里；每个类单独一个文件，才能触发真正的按需加载
- 如果用了
classmap，它会提前扫描并生成全量映射表，反而失去“按需”特性，慎用 - 运行
composer dump-autoload -o会生成优化版加载器（vendor/composer/autoload_classmap.php），但此时已不是严格按需，而是查表加载，性能更高但失去动态性
如何让某些依赖只在特定环境或条件下加载
Composer 本身不支持“仅在测试时加载 phpunit”，但可通过 require-dev + 手动条件引入实现逻辑隔离。
Find JSON Path Online
下载
Easily find JSON paths within JSON objects using our intuitive Json Path Finder
- 把非核心依赖（如
phpunit/phpunit、mockery/mockery）放进require-dev，它们不会被生产环境composer install --no-dev安装 - 在代码中用
class_exists('PHPUnit\Framework\TestCase')或function_exists('dd')判断依赖是否存在，再决定是否执行相关逻辑 - 避免直接
require 'vendor/autoload.php'后无条件调用 dev-only 类；应把依赖相关功能封装成可选服务，启动时检测后注册 - 某些框架（如 Laravel）通过服务提供者 +
when()或shouldRegister()实现条件注册，本质也是运行时判断
为什么 composer require 后类没被自动加载？
最常见原因是命名空间与路径不匹配，或未更新自动加载映射。
- 确认包是否声明了
autoload字段（查看其composer.json），有些老旧包只靠classmap或根本不支持自动加载 - 运行
composer dump-autoload（开发中无需-o），否则新添加的 PSR-4 映射不会生效 - 检查是否误用了
filesautoload 类型：它会在每次请求时无条件加载指定文件，不满足“按需”，且容易引发重复定义错误 - 若使用了 Composer 插件（如
hirak/prestissimo），极少数情况下会干扰 autoload 生成，可临时禁用验证
{
"autoload": {
"psr-4": {
"App\\": "src/",
"Tests\\": "tests/"
},
"files": ["src/helpers.php"]
},
"autoload-dev": {
"psr-4": {
"Tests\\": "tests/"
}
}
}
真正需要警惕的是“伪按需”：比如在全局作用域里写 if (ENV === 'local') { require 'vendor/some-debug-tool/autoload.php'; } ——这绕过了 Composer 加载器，可能导致类冲突、命名空间错乱或无法被 IDE 识别。坚持走标准 autoload 流程，哪怕多写几行检测逻辑，也比手动 require 更可靠。
