不能一次性装全所有数据库驱动，因会导致依赖爆炸、自动加载臃肿、包体积增大、类名冲突及版本互斥；必须按需显式声明、隔离加载，通过配置与工厂模式控制运行时实例化。
核心原则很明确：绝不能指望一个 composer require 命令就把所有数据库驱动都塞进来。正确的做法是，按需引入、显式声明、隔离加载。
为什么不能把所有数据库驱动都 require 进来
一个常见的误区是，看到项目未来可能用到 MySQL、PostgreSQL、SQLite，就图省事，一股脑执行：
composer require doctrine/dbal composer require illuminate/database composer require cakephp/database
这么做的后果是什么？首先是依赖树爆炸，自动加载映射变得异常臃肿，直接导致 vendor/autoload.php 加载速度变慢，部署包的体积也会无谓增大。但更关键的问题在于，不同驱动包之间很可能存在类名冲突——比如各自都定义了一个叫 PDOConnection 的封装类。此外，版本约束也可能互斥，例如 doctrine/dbal ^3.0 和 illuminate/database ^10.0 对 PHP 版本的要求可能不同，这会让 composer update 直接失败，或者在运行时冷不丁抛出 Class not found 的错误。
composer.json 中如何安全声明可选驱动
这里有个核心原则：只在 require 部分放入**当前环境绝对必需的驱动**，其他所有可能用到的驱动，要么放入 require-dev，要么干脆先不写——等到真正需要时再加也不迟。
- 如果生产环境只用 MySQL？那就只在
require里写："illuminate/database": "^10.0"。 - 测试环境需要跑 SQLite？可以把
"phpunit/phpunit": "^10.0"放到require-dev，并在phpunit.xml中配置 SQLite 的 DSN。注意，很多框架（如 Lara vel）或 DBAL 已经内置了对 SQLite 的支持，**通常无需额外 require 专门的 SQLite 驱动包**。 - 想保留未来切换数据库的能力？可以考虑使用
provide字段来声明接口兼容性，例如："provide": { "psr/sql": "1.0" }。不过要清楚，这只是一个语义声明，并不会实际安装任何代码。
运行时按需加载驱动类的实际做法
首先要明确一点：Composer 本身并不支持“在运行时动态 require 某个包”。我们所说的“按需”，指的是通过代码逻辑来控制类的加载路径，而不是指望 Composer 自动做条件加载。
- 不要在入口文件里
require_once 'vendor/autoload.php'之后，就直接实例化所有可能用到的驱动类。 - 正确的做法是，将数据库连接的初始化过程抽象成工厂方法，根据配置文件来决定实例化哪个具体的驱动类：
$driver = config('database.driver') === 'pgsql' ? new PgsqlDriver() : new MysqlDriver(); - 当然，前提是确保各个驱动类所在的包，都已经通过
composer require显式安装过了，并且其autoload规则已经写入了composer.json，同时执行过composer dump-autoload。 - 如果驱动来自不同的包（比如
spatie/lara vel-sqlite和lara vel/framework自带的 MySQL 支持），那么它们的命名空间和类路径本身就是天然隔离的，通常不会互相干扰。
部署时如何避免多余驱动被带上
这一点最容易被忽略：即使你没在 require 里写上某个驱动，但只要它曾经被 composer require 过，就很可能还留在 composer.lock 文件里，并且可能在你执行 composer install --no-dev 时被一并安装到生产环境。
- 务必检查
composer.lock文件，搜索相关的驱动包名（如sqlite3、pdo-pgsql），确认它们是否仍然存在。 - 要彻底移除不用的驱动，可以执行：
composer remove ext-pdo-pgsql（注意，这是 PHP 扩展名，不是 Composer 包名）或composer remove doctrine/dbal。 - 在 CI/CD 部署脚本中，强制使用
composer install --no-dev --optimize-autoloader --ignore-platform-reqs命令。其中--ignore-platform-reqs参数可以跳过对未安装的 PHP 扩展（如pdo_pgsql）的检查，防止因为扩展缺失而导致整个安装过程中断。
说到底，真正的“按需”边界是在代码层，而不是在 Composer 层。Composer 只负责把你声明过的包准备好，至于用不用、什么时候用、怎么用，都得靠你自己在工厂模式、配置文件和条件分支里来控制。如果漏掉了这一点，很容易出现在本地开发环境一切正常，一上线就报 Class 'PgsqlDriver' not found 的错误——原因很简单，那个类根本就没有被 Composer 加载进来。
