绝对不能参数化的部分是order by、group by、limit、offset、表名、字段名、数据库名等sql标识符；必须通过白名单精确校验后拼接，因数据库协议和go驱动不支持对标识符使用?或$1占位符。
动态拼接 SQL 字符串时，哪些部分绝对不能参数化
ORDER BY、GROUP BY、LIMIT、OFFSET、表名、字段名、数据库名——这些都属于 SQL 标识符（identifier），不是值（value），标准协议和 Go 驱动层根本不支持用 ? 或 $1 替换。试图写 db.Query("SELECT * FROM ? WHERE id = ?", tableName, id) 会直接 panic：sql: expected 0 arguments, got 1 或更隐蔽的语法错误。
常见错误现象：本地 SQLite 可能“凑巧”不报错（因驱动宽松），但部署到 PostgreSQL 就崩；或排序字段传入 created_at ASC; DROP TABLE users，拼进去后语句变成 ORDER BY created_at ASC; DROP TABLE users，触发多语句执行（若未禁用 multiStatements）。
- 必须白名单校验排序字段：只允许
map[string]bool{"name": true, "email": true, "created_at": true}中的 key - 排序方向（
ASC/DESC）也得白名单，不能靠fmt.Sprintf("ORDER BY %s %s", field, dir)直接拼 - 表名拼接前，先查
INFORMATION_SCHEMA.TABLES或硬编码映射（如switch input { case "user": return "users_prod" }），别信正则过滤
白名单校验怎么写才不被绕过
字符串替换（strings.ReplaceAll(s, "'", "''")）、正则匹配（regexp.MustCompile(`^[a-zA-Z0-9_]+$`)）、甚至 Unicode 归一化，都防不住攻击者用零宽空格（\u200b）、注释符（/**/）、或换行符绕过。真正有效的白名单是“枚举 + 精确比对”，不是“过滤 + 放行”。
示例场景：用户请求按 sort=score DESC 查询，你解析出 field="score"、dir="DESC"：
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- ✅ 安全写法：
if !validFields[field] || !validDirs[dir] { return errors.New("invalid sort param") } - ❌ 危险写法：
if !regexp.MustCompile(`^[a-zA-Z_]+$`).MatchString(field) { ... }——score\u200b仍能通过 - ❌ 更危险：
field = strings.TrimSpace(field); field = strings.ReplaceAll(field, "'", "")——score/**/不受影响
用 sqlx.In 或 GORM 的 IN 查询时，参数展开容易踩什么坑
sqlx.In 和 GORM 的 IN ? 看似自动处理 slice，但底层仍是占位符展开，不是字符串拼接。问题出在“怎么传”和“传什么”：
- ❌ 错误：
sqlx.In("SELECT * FROM users WHERE id IN (?)", ids)——?只代表一个参数，ids是 slice，驱动无法展开 - ✅ 正确：
query, args, _ := sqlx.In("SELECT * FROM users WHERE id IN (?)", ids); query = sqlx.Rebind(query); db.Select(&users, query, args...) - ⚠️ GORM 注意：
db.Where("id IN ?", []uint{1,2,3}).Find(&users)安全，但db.Where("id IN (" + strings.Join(strIds, ",") + ")").Find(&users)就裸奔了 - 性能影响：大量 ID（> 1000）时，MySQL 有 max_allowed_packet 限制，PostgreSQL 有参数数量上限（默认 65535），需分批查询
日志里打印 SQL 时，怎么避免把注入入口暴露出去
很多人以为“SQL 已参数化就安全了”，但在日志中写 log.Printf("query: %s, args: %+v", rawSQL, args)，等于把原始拼接逻辑和敏感参数一起发到日志系统——如果 rawSQL 是手拼的，攻击者从日志就能还原 payload；如果 args 包含密码、token，更是灾难。
- ✅ 安全做法：日志中只打预编译后的语句模板（如
"SELECT * FROM users WHERE status = ? AND age > ?"），不打运行时拼出的完整 SQL - ✅ 参数值脱敏：
log.Printf("query: %s, args: [%d, %s]", template, len(args), "REDACTED") - ❌ 危险习惯：
log.Printf("executing: %s", query)—— 如果query来自fmt.Sprintf("SELECT * FROM %s", table)，日志就是注入证据链 - 特别注意：
sql.NullString或sql.RawBytes不是“安全包装”，它们只是扫描类型；往日志塞sql.NullString{String: userInp, Valid: true}依然等于裸奔
真正的难点不在“会不会写 ?”，而在于识别哪些地方根本不能靠参数化——比如你要支持按租户动态查表，那白名单校验逻辑就得嵌进业务路由里，而不是塞进 DAO 层当个装饰。漏掉一个 ORDER BY 字段校验，或把 JSON 配置里的 SQL 模板当“可信数据”直接拼，防护就形同虚设。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
