Composer本身不提供数据分片或分库能力，它只是依赖管理工具；所谓“基于Composer库实现高性能分片”，本质是选对、配好、用熟几个关键第三方包，并规避常见集成陷阱。
直接说结论：Composer 本身不提供数据分片或分库能力，它只是依赖管理工具；所谓“基于 Composer 库实现高性能分片”，本质是选对、配好、用熟几个关键第三方包，并规避常见集成陷阱。
composer.json 里该写哪些分片相关依赖
不是所有标着 “shard” 或 “db” 的包都适合生产。真正稳定、可维护的 PHP 分片组件极少，目前主流选择只有两个方向：
-
spatie/laravel-query-builder（仅 Laravel 生态）——如果你用 Laravel，它能帮你按字段/范围做查询路由，但不解决底层连接分发 -
doctrine/dbal+ 自定义Connection路由逻辑 —— 更通用，需自己实现分片键解析、连接池选择、事务协调
注意：laravel/scout、algolia/algoliasearch-client-php 这类搜索分片库不能当数据库分片用；symfony/cache 的 RedisTagAwareAdapter 也不处理 SQL 路由。
为什么 dump-autoload --classmap-authoritative 会影响分片组件性能
分片逻辑常依赖运行时反射（比如读取实体类注解判断分片字段），而 --classmap-authoritative 会禁用 PSR-4 动态查找 —— 如果你的分片路由器用 new $className 或 class_exists($name) 判断类是否存在，它会直接返回 false。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 生产环境开启
--optimize（生成 classmap 提速），但不要加--classmap-authoritative - 若必须用权威模式，把分片相关类显式写进
autoload/classmap数组，例如："src/Sharding/Router.php" - 检查分片组件是否调用
get_declared_classes()—— 这个函数在权威模式下返回空数组
分片键路由逻辑必须避开 Composer 自动加载干扰
典型错误：在 post-autoload-dump 事件里动态生成分片配置文件，结果 vendor/autoload.php 尚未重写完成，新生成的配置被旧 autoloader 加载失败。
正确做法：
- 分片路由逻辑（如根据 user_id % 4 选库）必须放在
vendor/外，且不依赖任何未声明的类 - 避免在
composer.json的scripts里执行数据库连接测试 ——post-autoload-dump触发时，vendor/autoload.php可能还没写完 - 如果要用 Composer 事件初始化分片元数据，改用
post-install-cmd或post-update-cmd，并确保脚本内使用绝对路径加载配置
最易被忽略的点：分片组件往往假设所有分库结构一致，但 Composer 安装不同版本的 doctrine/migrations 可能导致各分库 migration 状态错位 —— 每个分库必须独立运行 php vendor/bin/doctrine-migrations migrations:migrate，不能共用一个 migration table。
