真正影响运行行为的gorm.Config字段有：SkipDefaultTransaction（控制是否自动事务）、PrepareStmt（启用预编译缓存）、Logger（决定日志输出内容与级别）、NamingStrategy（影响表名列名生成）、DryRun（仅生成SQL不执行）；其余如DSN参数、连接池设置等不在Config中。
gorm.Config 里哪些字段真会影响运行行为
不是所有 gorm.Config 字段都参与运行时逻辑，有些只在初始化阶段起作用，有些甚至只是“占位”或被后续调用覆盖。真正影响 SQL 执行、连接复用、日志输出的字段只有几个关键项。
-
SkipDefaultTransaction：设为true后，Create/Save等方法不再自动包裹事务，避免隐式事务开销；但手动调用db.Transaction()仍有效 -
PrepareStmt：设为true会启用预编译缓存，重复执行相同结构的 SQL（如带不同参数的WHERE id = ?）能跳过 SQL 解析阶段；但首次执行略慢，且对 MySQL 8.0+ 更友好，老版本可能有兼容问题 -
Logger：必须传非 nil 实例，否则默认静默（Silent），LogLevel控制输出粒度，SlowThreshold是独立于日志级别的阈值判断，即使LogLevel设为Error，超时 SQL 仍会以 Warn 级别打印 -
NamingStrategy：影响表名、列名生成逻辑，比如TablePrefix会在所有自动推导的表名前加前缀，但它会被结构体上显式的TableName()方法覆盖
DSN 和 Config 的分工边界在哪
DSN（Data Source Name）负责底层连接建立，gorm.Config 负责连接之上的行为控制——两者不能混用，也不能互相替代。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 字符集、时区、超时等连接级参数（如
charset=utf8mb4、loc=Local、timeout=5s）必须写进 DSN，gorm.Config里没有对应字段 - 连接池参数（
SetMaxOpenConns、SetMaxIdleConns）是*gorm.DB对象的方法，不是gorm.Config字段，必须在gorm.Open()返回后立即调用 -
DryRun是gorm.Config字段，开启后所有操作只生成 SQL 不执行，适合调试，但它不改变 DSN 解析或连接建立过程
为什么 PrepareStmt=true 有时反而变慢
预编译不是银弹，它在特定场景下会引入额外开销或触发 MySQL 的 Prepared Statement 限制。
- MySQL 默认最大预编译语句数是 16382（
max_prepared_stmt_count），高频动态 SQL（如拼接字段名、表名）会导致缓存溢出，触发清理或报错SQL error: Too many statements - 使用
Raw()或Exec()执行原生 SQL 时，PrepareStmt不生效，但若误以为它全局生效，可能忽略手动 prepare 的必要性 - 连接断开重连后，预编译句柄失效，GORM 会重新 prepare，若应用频繁重建 DB 连接（如短生命周期服务），反而增加 handshake 开销
Config 初始化后还能改吗
不能。gorm.Config 是传给 gorm.Open() 的一次性参数，初始化完成后的 *gorm.DB 对象不暴露修改 Config 的接口。
- 想临时调整行为，得用链式方法：比如单次查询禁用预编译，用
db.Session(&gorm.Session{PrepareStmt: false}).First(&u) - 全局日志级别变更只能换 Logger 实例，无法 runtime 修改
newLogger.LogLevel，因为 GORM 内部只读取一次 - 连接池参数可随时调用
db.DB().SetMaxOpenConns(n)修改，但要注意并发安全，建议在服务启动初期统一设置
PrepareStmt 和连接池参数不在同一个配置层级，前者属于 gorm.Config，后者属于底层 *sql.DB，漏配连接池可能导致连接耗尽，而误配 PrepareStmt 可能让监控看到大量“慢 SQL”其实是 prepare 阶段延迟。** 
