TP5.1 的 partition() 方法在绝大多数场景下不生效，ORM 查询构建器不会解析该配置；动态分表必须手动计算表名并通过重写 getTable() 或 Db::table() 实现，且需确保写入与查询逻辑严格一致。
TP5.1 的 partition() 方法看似可用，实则在绝大多数场景下不生效——它只在极少数旧驱动路径中被浅层读取，ORM 查询构建器（Query 类）根本不会解析或应用该配置。所谓“动态分表”，必须靠手动计算表名 + 显式切换实现。
model::getTable() 重写是唯一可靠入口
模型的表名最终由 getTable() 方法返回，这是你唯一能稳定拦截并修改表名的位置。不要依赖构造函数传参、protected $table 赋值或配置项，它们在查询执行前就已固化。
-
getTable()在每次查询前都会被调用，包括select()、insert()、update()等所有操作 - 若需按 ID 分表，可在方法内读取待插入/查询数据的
id字段（注意：新增时id可能尚未生成，需结合insertGetId()或预生成逻辑） - 若需按时间分表，应从
$this->data或查询条件（如$this->getOptions('where')）中提取时间字段值，再格式化为后缀，例如：'log_' . date('Ym', strtotime($timeValue)) - 务必校验后缀合法性，避免拼出
log_../etc/passwd类非法表名；建议白名单过滤或正则断言：preg_match('/^\d{6}$/', $suffix)
Db::table() 是最直接的绕过方式
当模型逻辑复杂、或仅某几个接口需要分表时，放弃继承模型，直接用查询构建器更清晰可控。
- 先算出目标表名：
$tableName = 'order_' . date('Ym', strtotime($dateParam)); - 再调用：
Db::table($tableName)->where('user_id', 123)->select(); - 注意：此时无法使用模型的获取器（accessor）、修改器（mutator）、自动时间戳等特性，字段处理需自行补全
- 若仍需模型能力，可临时绑定：
(new OrderModel())->table($tableName)->where(...)->select()，但需确保OrderModel中未硬编码$table
partition() 方法调用后没报错却查错表？这是设计使然
partition() 在 TP5.1 的 Query 类中确实存在，但它只在特定条件下触发：必须同时满足「当前有 where 条件包含分表字段」+「规则匹配成功」+「未开启联合查询 fallback」。多数情况下它静默失败，回退到主表。
- 常见误用：
Model::partition(['id' => 100])->where('status', 1)->select()—— 此处id不在where中，partition()直接忽略 - 即使写成
where('id', 100)->partition(...)，若规则中type为mod且num为 3，则只生成table_1、table_2、table_3，而实际表可能是table_001、table_002，后缀不匹配照样查不到 - 该方法内部不校验目标表是否存在，也不会抛异常，错误表现为“查不到数据”或“查到空结果”，极易误判为业务逻辑问题
真正难的不是算表名，而是保持写入与查询逻辑严格一致——比如按月分表，写入用 date('Ym', $create_time)，查询却用了 date('Ym', time())，跨月时必然漏数据。所有时间计算必须基于同一字段、同一时区、同一格式化逻辑，且不能依赖 PHP 默认时区或数据库时区自动转换。
