ThinkPHP 8.0 不支持原生分库分表，需手动实现路由、校验与扩容逻辑，且存在事务跨库静默失败、关联查询失效、SQL注入风险等隐患。
ThinkPHP 8.0 本身不支持运行时动态分库分表，database.php 中的 connections 是静态配置，无法根据 user_id 或时间自动切换数据库实例或物理表名。所谓“Sharding 中间件”，实际是应用层模拟或依赖外部代理，不是框架原生能力。
ThinkPHP 8.0 没有内置 sharding 能力，别指望 Db::connect() 动态切库
TP8 的 Db::connect() 和模型 $this->connection('xxx') 只能指定预定义的连接标识（如 'db_0'、'db_1'），这些标识必须在 database.php 里提前写死。框架不会帮你解析 user_id % 4 然后选库——你得自己算、自己传、自己兜底。
- 错误写法：
Db::connect('db_' . ($uid % 4))—— 如果database.php里没配db_0到db_3，直接抛出Connection not found - 隐患：事务仅限单库，
Db::transaction()跨db_0和db_1会静默失败，不报错但数据不一致 - 关联查询失效：
UserModel::with('orders')->find(123)中的orders若分库，with()无法跨库 JOIN，只会查空或报错
分表必须手动拼接表名，且严禁用户输入参与构造
TP8 的 Db::name() 和模型 $this->table() 支持运行时设置，但这是纯字符串替换，无 SQL 注入防护。你必须自己做校验、自己控制生成逻辑。
- 安全写法：用业务字段时间戳生成分表后缀，例如
$table = 'order_' . date('Ym', $order['created_at'])；$order['created_at']必须是 int 型时间戳 - 禁止硬编码：
date('Ym')在 Swoole/Workerman 长进程里会卡死在启动月，永远不更新 - 白名单校验：若从 URL 获取月份（如
$_GET['month']），必须先preg_match('/^\d{6}$/', $month)，再检查是否在01–12范围内 - 高危操作示例：
Db::name('log_' . input('month'))—— 等于把表名交给攻击者控制，PDO 不参数化表名
扩容时取模分片要命，一致性哈希或嵌入式分片键更可控
如果现在用 user_id % 4 分 4 库，将来扩到 5 库，96% 的历史数据要重哈希迁移。TP8 层面无法自动触发双写或数据校验，全靠你手写迁移脚本和路由开关。
立即学习“PHP免费学习笔记（深入）”；
- 推荐做法：把分片信息“藏进”主键，比如
user_id设计为123456780203（末两位02表示库号，03表示表号），路由时直接substr($uid, -4, 2)提取库索引 - 好处：扩容只需新增库/表，旧数据不动；路由逻辑不变，不改业务代码
- 代价：主键变长、插入前需封装生成逻辑（如
UserHelper::genId()），不能用自增 ID - TP8 不提供分片键注入点，所有生成、解析、路由都得你自己在基类或服务层实现
别用 PDO 模拟预处理连 ShardingSphere-Proxy
如果你选了 ShardingSphere-Proxy 作为中间件（推荐），TP8 的 PDO 连接必须关掉模拟预处理，否则分片键（如 WHERE user_id = ?）无法被 Proxy 解析，所有请求都打到默认库。
- 正确配置：
'options' => [PDO::ATTR_EMULATE_PREPARES => false]，写在database.php对应连接项里 - 错误现象：查询返回空结果，但日志显示 Proxy 收到语句却没路由，
sql.show: true开启后可确认是否识别到分片键 - Proxy 端配置必须与 TP8 传入的分片键字段名严格一致（大小写、下划线），例如 TP8 写
user_id，Proxy 规则就不能写成userId
真正麻烦的不是怎么写路由函数，而是事务边界、关联失效、跨分片统计这些隐性约束——它们不会报错，但会让业务逻辑在某次高峰后悄悄崩掉。
