GORM连接PolarDB与标准MySQL完全一致，复用gorm.io/driver/mysql即可；因PolarDB是MySQL协议的完全兼容实现，无需独立驱动或特殊配置，DSN需校验parseTime、loc、timeout等参数，并严格调优连接池。
GORM 连接 PolarDB 和连接标准 MySQL 完全一致，PolarDB（MySQL 兼容版）本身不提供独立驱动，直接复用 gorm.io/driver/mysql 即可。官方文档和阿里云实测均确认：只要 PolarDB 实例开启 MySQL 协议（默认即开启），GORM 就能无缝接入，无需任何适配层或特殊配置。
为什么用 mysql.Open() 而不是单独的 polarDB.Open()
因为 PolarDB（MySQL 兼容版）是 MySQL 协议的完全兼容实现，不是新数据库类型。GORM V2 的驱动模型只按协议区分，不按厂商区分：
• gorm.io/driver/mysql 对应 MySQL 协议（含 Aurora、PolarDB、TiDB 等兼容实例）
• 没有也**不需要** gorm.io/driver/polardb 这类包
• 若错误引入非 MySQL 协议驱动（如 postgres），会直接 panic 报错 "unsupported driver: polardb"
DSN 连接字符串关键参数必须校验
PolarDB 常见连接失败，90% 出在 DSN 配置细节。务必检查以下几项：
-
parseTime=true：必须启用，否则time.Time字段解析失败（报错类似"sql: Scan error on column index 2, name \"created_at\": unsupported Scan, storing driver.Value type []uint8 into type *time.Time"） -
loc=Asia/Shanghai或loc=Local：避免时区偏移导致时间字段写入/查询错位（PolarDB 默认 UTC，但应用常跑在东八区） -
timeout=5s&readTimeout=10s&writeTimeout=10s：显式设超时，防止连接卡死阻塞整个连接池 - 用户名密码不能含特殊字符：若密码含
@、/、:，必须用url.PathEscape()编码，否则 DSN 解析失败
连接池与生产环境必须设置的三项
直连 PolarDB 时，GORM 默认连接池参数极宽松（MaxOpenConns=0 即不限制），极易打爆 PolarDB 的 max_connections 限制（默认通常 200–400）。必须显式调优：
-
DB.DB().SetMaxIdleConns(10)：空闲连接数，建议设为MaxOpenConns的 1/3～1/2 -
DB.DB().SetMaxOpenConns(50)：最大打开连接数，需根据 PolarDB 规格调整（例如 2C4G 实例建议 ≤30；4C16G 可设 60） -
DB.DB().SetConnMaxLifetime(1h)：强制连接 1 小时后重建，避免 PolarDB 后端因长连接空闲被主动 kill 导致"invalid connection"错误
容易忽略的兼容性陷阱
PolarDB MySQL 版虽兼容，但部分高级特性 GORM 默认不启用，需手动干预：
- JSON 字段：PolarDB 支持
JSON类型，但 GORM V2 默认映射为string。若要使用原生 JSON 查询（如WHERE data->'$.name' = 'foo'），结构体字段需声明为json.RawMessage或自定义Scanner/Valuer - 隐式主键策略：PolarDB 允许无主键表，但 GORM 强依赖主键做 CRUD。若表无
id或PRIMARY KEY，必须用gorm.Model{}或gorm.PrimaryKey显式指定 - 自动迁移慎用：PolarDB 不支持某些 DDL（如
ALTER TABLE ... DROP COLUMN在早期版本受限），AutoMigrate可能静默失败。生产环境建议禁用，改用 SQL 文件 + Flyway/Liquibase 管理 schema
真正麻烦的从来不是“能不能连”，而是连接之后的连接池水位、时区一致性、以及 DSN 中一个未转义的 @ 符号——这些细节在本地 MySQL 上可能不暴露问题，一上 PolarDB 就立刻触发超时或解析异常。
