gin 不参与分表逻辑，因其仅为 http 路由框架，不感知数据库结构；分表须在 gorm 或业务层显式控制，通过 table() 动态指定表名，并确保查询条件与分表字段对齐。
为什么 Gin 本身不参与分表逻辑
Gin 是 HTTP 路由框架，只负责接收请求、解析参数、调用业务函数；它不感知数据库结构，更不会自动帮你路由到 orders_2024_w12 或 logs_q3_2024 这类表。分表必须在 GORM 层或业务层显式控制——Gin 只是把 year=2024&quarter=3 这样的参数传进来，剩下的全得你写代码决定查哪张表。
如何用 GORM 动态指定表名（核心操作）
GORM v2 不再支持全局 TableName 回调动态改名，必须对每个查询单独设置。最可靠的方式是：先构造带时间信息的表名，再用 Table() 方法绑定：
// 按周分表：orders_2024_w12
year, week := 2024, 12
tableName := fmt.Sprintf("orders_%d_w%d", year, week)
db.Table(tableName).Where("status = ?", "paid").Find(&list)
<p>// 按季度分表：logs_2024<em>q3
quarter := 3
tableName := fmt.Sprintf("logs</em>%d_q%d", year, quarter)
db.Table(tableName).Create(&log)</p>
- 必须确保目标表已存在，GORM 不会自动建表，需提前用 migration 或脚本生成
-
Table()只影响当前链式调用，下一次db.First()仍会回到默认表名，不能设成全局状态 - 如果用了 GORM 的软删除（
DeletedAt），记得手动加Unscoped()，否则Table().Where()可能漏掉已逻辑删除的数据
分表字段和查询条件怎么对齐
按周/季度分表后，原始时间字段（如 created_at）仍是主键依据，但不能再依赖数据库分区裁剪——因为 GORM 不知道你把数据存到了哪张物理表。所以必须做到两点：
- 所有写入前，用
time.Now().ISOWeek()或(month-1)/3 + 1算出对应周/季度，并写入记录的week_id/quarter_id字段（冗余存储，避免运行时计算） - 查询时，必须同时带上分表标识条件，例如：
db.Table(tableName).Where("week_id = ? AND status = ?", 12, "paid")，否则可能跨表查到错误时间范围的数据 - 禁止直接对“总表名”做
SELECT * FROM orders类查询——那张总表根本不存在，GORM 会报ERROR: relation "orders" does not exist
迁移与上线时最容易被忽略的点
开发时本地跑得通，上线后查不到数据？大概率卡在这几个地方：
- 表名大小写敏感：PostgreSQL 默认小写，MySQL 在 Windows 下不敏感、Linux 下敏感，
Orders_2024_Q3和orders_2024_q3可能不是同一张表 - 时区陷阱：用
time.Now().Year()算年份没问题，但time.Now().ISOWeek()返回的是 ISO 周（周一为起点），而有些业务按自然周（周日为起点）分表，结果差一天就写错表 - GORM 的
Preload()无法跨表关联：比如Order分表了，User没分，db.Preload("User")仍会去查users表，但如果你在Order结构体里硬编码了TableName() string { return "orders_2024_w12" }，会导致 Preload 失败——因为 GORM 会尝试从orders_2024_w12表里 JOINusers，语法报错
真正麻烦的不是写代码，而是让所有写入路径、所有查询路径、所有定时任务、所有离线导出脚本，全部同步使用同一套分表规则——少一个地方没对齐，数据就散了。
