AutoMigrate 不适合动态建表，因其仅支持编译期已知结构体的静态表名同步，无法处理运行时变量表名、租户分表等场景；动态建表须用原生 SQL 手动执行并严格校验表名、权限与连接配置。
不能靠 AutoMigrate 实现“运行时按需建表”，它只做结构同步，不支持动态命名或条件建表。 真正的动态建表必须绕过 GORM 的模型绑定机制，直接执行原生 SQL，并自行管理表名、字段定义与 DSN 绑定关系。
为什么 AutoMigrate 不适合动态建表
AutoMigrate 的设计目标是开发期结构对齐：它根据 Go 结构体生成固定表名（如 User{} → users），且要求结构体在编译期已知。一旦你试图用变量控制表名（比如 tableName := "logs_" + tenantID），GORM 就无法将结构体映射到该表——因为 TableName() 方法只能返回常量或基于接收者字段的静态计算，不能依赖运行时上下文。
- 调用
db.AutoMigrate(&Log{})永远只会操作logs表（或你硬编码的单个表名），不会生成logs_shanghai、logs_beijing - 即使你用
func (l *Log) TableName() string { return "logs_" + l.TenantID }，l.TenantID在AutoMigrate阶段为空或未初始化，结果仍是无效表名 -
AutoMigrate不校验表是否存在再建；它只对比当前结构体字段和已有表结构，缺失字段才 ADD COLUMN，绝不会 CREATE TABLE IF NOT EXISTS 动态表
用原生 SQL + Exec 手动建表的实操要点
动态建表本质是元数据操作，应脱离 ORM 模型层，在 DAO 或 Migration 工具层完成。核心是拼出合法 SQL 并确保权限、字符集、引擎等参数可控。
- 表名必须经安全校验：禁止直接拼接用户输入。用白名单或正则过滤（如
^[a-z][a-z0-9_]{2,63}$），避免注入或语法错误 - MySQL 示例语句：
CREATE TABLE IF NOT EXISTS `logs_shanghai` (id BIGINT PRIMARY KEY AUTO_INCREMENT, content TEXT, created_at DATETIME)—— 注意反引号包裹表名，防止关键字冲突 - 执行时用对应库的
*gorm.DB实例调用：err := db.Exec(sqlStr).Error，而非db.Table("xxx").Create()（后者是数据插入） - PostgreSQL 需额外处理 schema：若租户表分散在不同 schema，先
CREATE SCHEMA IF NOT EXISTS shanghai，再建表时写shanghai.logs - 建表后可选执行
db.Migrator().CurrentDatabase() == "target_db"验证是否在正确库上操作，避免跨库误写
动态表对应的 CRUD 必须绕过模型自动映射
建完 logs_shanghai 表后，你不能再用 db.Create(&Log{...})，因为 GORM 仍会往默认 logs 表插数据。所有读写都得显式指定表名并用 map 或 raw SQL。
- 插入数据：
db.Table("logs_shanghai").Create(map[string]interface{}{"content": "xxx", "created_at": time.Now()}) - 查询数据：
var rows []map[string]interface{}; db.Table("logs_shanghai").Find(&rows)，或更安全的db.Raw("SELECT * FROM logs_shanghai WHERE ...").Scan(&results) - 避免用结构体绑定：若坚持用结构体，必须为每个动态表定义独立类型（如
type LogShanghai struct{...}），但不可行——租户数不确定，无法预定义类型 - 字段变更需单独维护：新增字段不能靠
AutoMigrate，得发ALTER TABLE logs_shanghai ADD COLUMN xxx VARCHAR(255)
容易被忽略的权限与连接池问题
动态建表不是纯代码逻辑，它强依赖数据库账号权限和连接状态。这两点在线上环境最容易出故障。
- MySQL 账号必须有
CREATE TABLE权限，且不能是localhost限定——如果应用部署在容器内，host 往往是网段 IP，需授权类似GRANT CREATE ON `logs_%`.* TO 'app'@'10.0.0.%' - 建表语句执行失败时，
err可能是"ERROR 1050 (42S01): Table 'xxx' already exists"，这属于预期情况，应检查err是否含"1050"而非直接 panic - 高频建表（如每秒多次）会快速耗尽连接池，建议加锁或限流；更合理的方式是预热建表（启动时批量创建已知租户表），而非完全运行时触发
- PostgreSQL 密码含特殊字符（如
/）时，DSN 中未用url.QueryEscape编码会导致建表前连接就失败，错误信息模糊（"pq: password authentication failed"）
