Gin项目连不上SQL Server主因是驱动或DSN配置错误：DSN须为URL格式且含encrypt=disable，用户名密码需URL编码，驱动注册名应为"sqlserver"，推荐先用sql.Open+db.Ping验证连接。
Gin 项目里连不上 SQL Server，八成是驱动或 DSN 配置错了。Gin 本身不关心数据库类型，真正起作用的是 gorm.Open 或 sql.Open 调用的底层驱动。SQL Server 在 Go 生态中支持不如 MySQL 成熟，容易卡在连接初始化、认证方式、端口默认值这几个点上。
为什么用 gorm.Open("sqlserver", dsn) 总报错 invalid connection
常见错误是直接复制 MySQL 的写法，但 SQL Server 驱动（github.com/denisenkom/go-mssqldb）对 DSN 格式要求更严格，且不接受 user:pass@tcp(host:port)/db 这种类 MySQL 表达式。
-
dsn必须是 URL 形式，例如：sqlserver://sa:your_password@localhost:1433?database=master&encrypt=disable -
encrypt=disable是开发环境最常漏掉的参数——SQL Server 默认强制加密，而本地未配证书时必须显式关掉，否则连接直接被拒绝 - 用户名密码里含特殊字符（如
@、/）必须用url.PathEscape编码，否则解析失败 - 驱动注册名不是
"sqlserver"，而是"mssql"（旧版）或"sqlserver"（新版），取决于你import _ "github.com/denisenkom/go-mssqldb"后实际注册的名称；建议用go-mssqldbv1.4+，它注册为"sqlserver"
sql.Open 和 gorm.Open 的 DSN 差异很关键
用原生 database/sql 时，sql.Open("sqlserver", dsn) 只校验 DSN 语法，不真正连库；而 gorm.Open 默认会立即执行 Ping()，所以失败更早、报错更明确。
- 推荐先用
sql.Open+db.Ping()单独验证连接通不通，再接入 Gin/GORM - GORM 初始化时加
&gorm.Config{SkipDefaultTransaction: true}，避免 SQL Server 对隐式事务的兼容性问题 - 如果用 Windows 身份认证（integrated security），DSN 要写成：
sqlserver://localhost\SQLEXPRESS?database=yourdb&encrypt=disable&trusted_connection=yes，注意双反斜杠转义
字段类型映射和 NULL 处理容易翻车
SQL Server 的 datetime2、uniqueidentifier、bit 等类型，在 Go struct 中若没配对好，查出来就是零值或 panic。
-
datetime2→ Go 的time.Time，但必须在 DSN 加parseTime=true（sqlserver://...?parseTime=true） -
uniqueidentifier→ 推荐用string存，或uuid.UUID（需额外 importgithub.com/google/uuid并实现Scanner/Valuer） -
bit→ 映射为bool，但空值（NULL）会导致 scan 失败；必须用*bool或sql.NullBool - GORM 迁移（
AutoMigrate）对 SQL Server 支持有限：不生成主键约束、不处理IDENTITY列自动递增，得手写CREATE TABLE或用db.Exec补充
真正麻烦的不是连上，而是连上之后的时区、空值、标识列、存储过程调用这些细节——它们不会在 gorm.Open 报错里体现，只会在第一次 Find 或 Create 时崩给你看。
