GORM 默认映射不满足业务需求，必须用 gorm:"type:xxx" 显式指定：string→VARCHAR(255)、int→INT、uint64→BIGINT UNSIGNED、time.Time→DATETIME、bool→TINYINT(1)，且 type 与 column 可共存，真正决定列类型的是 type 标签。
GORM 默认按 Go 类型推断 MySQL 字段类型，但推断结果未必符合业务需求——比如 string 默认映射为 VARCHAR(255)，而实际可能需要 TEXT 存长文本；int 映射为 INT，但在 ID 场景下更常需 BIGINT UNSIGNED。必须显式控制，不能依赖默认。
Go 类型 → MySQL 类型的默认映射关系
GORM v2 不会“猜”你的存储意图，它只按类型做最小化、安全的映射。例如：
-
string→VARCHAR(255)（不是TEXT，哪怕字段存 HTML） -
int→INT（有符号，范围 -2147483648 ~ 2147483647） -
uint64→BIGINT UNSIGNED（这是唯一自动带UNSIGNED的整数类型） -
time.Time→DATETIME（不是TIMESTAMP，时区行为不同） -
bool→TINYINT(1)（MySQL 没原生 BOOLEAN，本质是数字）
这些映射写死在 GORM 源码的 dialects/mysql.go 中，改不了，只能覆盖。
用 gorm:"type:xxx" 覆盖默认类型
这是最直接、最可控的方式，尤其在以下场景必须用：
- 需要
TEXT或MEDIUMTEXT存富文本、日志内容：加gorm:"type:TEXT" - ID 字段要
BIGINT UNSIGNED（适配 Snowflake ID）：gorm:"type:BIGINT UNSIGNED" - 金额字段用
DECIMAL(10,2)而非FLOAT：gorm:"type:DECIMAL(10,2)" - JSON 字段明确用 MySQL 5.7+ 的
JSON类型：gorm:"type:JSON"（注意：Go 端需用json.RawMessage或自定义类型）
错误示例：Price float64 gorm:"type:DECIMAL" —— 缺少精度声明，MySQL 会报错或退化为 DECIMAL(10,0)。
字段名与列名不一致时，column 和 type 可共存
别以为加了 column 就没法管类型。两者互不冲突，可同时生效：
type Product struct {
ID uint `gorm:"primaryKey;column:product_id;type:BIGINT UNSIGNED"`
Title string `gorm:"column:name;type:VARCHAR(200)"`
Content string `gorm:"column:body;type:LONGTEXT"`
IsActive bool `gorm:"column:enabled;type:TINYINT(1)"`
}
注意：type 值必须是 MySQL 原生语法，大小写不敏感，但括号、逗号、空格必须准确；column 仅影响列名，不影响类型推导。
容易被忽略的隐式行为
几个坑点常导致建表失败或数据截断：
-
sizetag（如gorm:"size:50"）只对string生效，且仅控制VARCHAR(n)长度，不适用于TEXT类型 -
autoIncrement对非主键字段无效，MySQL 不允许非主键自增 -
uniqueIndex或index不改变字段类型，但会影响建表顺序和性能，需配合type一起评估 - 使用
sql.NullString等 SQL 扫描类型时，GORM 仍按底层 Go 类型（string）推断，需手动加type
真正决定数据库列类型的，永远是 gorm:"type:..."；其他 tag 只是辅助。没加，就按默认走——而默认往往不够用。
