必须使用database/sql参数化查询、html/template模板和32字节gorilla/csrf密钥，否则易引发sql注入、xss或csrf漏洞；sql注入防范关键在于禁用字符串拼接而用?或$1占位符；xss防护重点在输出上下文，须用html/template自动转义。
database/sql 的参数化查询必须用，html/template 不能换成 text/template，gorilla/csrf 的密钥长度必须是 32 字节——这三件事做错任何一件，都可能直接导致 SQL 注入、XSS 或 CSRF 漏洞上线。
SQL 注入：别让 fmt.Sprintf 碰数据库查询字符串
错误不是“没写验证”，而是把用户输入拼进 SQL 字符串里。哪怕加了正则校验，只要最终用了字符串拼接，攻击者就能绕过。
常见错误现象：db.Query("SELECT * FROM users WHERE name = '" + name + "'") 这类代码在日志里一搜一个准。
- 使用
database/sql时，所有查询必须走Query、QueryRow或Exec的变参形式，占位符统一用?（MySQL/SQLite）或$1（PostgreSQL） - ORM 如 GORM 或 Ent，必须用
Where("name = ?", name)这类带问号的语法，禁用Where("name = '" + name + "'") - 如果必须动态拼表名或字段名（极少数场景），只能白名单校验，不能靠过滤字符——比如只允许
map[string]bool{"users": true, "orders": true}中的值
XSS 防护：输出阶段比输入阶段更关键
很多人花大力气过滤输入，却在模板里直接 string 拼 HTML，结果白忙活。XSS 的核心是“不可信数据被当代码执行”，所以重点在输出上下文。
常见错误现象：用 text/template 渲染用户昵称，或手动 html.EscapeString 后再塞进 html/template——后者反而会二次转义，破坏正常显示。
- 所有 HTML 响应必须用
html/template，它会在{{.Name}}插值时自动转义、<code>&、"等字符 - 富文本场景（如文章编辑器）必须用
bluemonday白名单净化，而不是简单替换<script></script>标签——事件属性如onerror同样危险 - JSON API 返回敏感字段（如密码、token）必须用
json:"-"忽略，或提前从结构体中移除，不能依赖前端不读
CSRF 防护：Token 不只是加个 hidden 字段
只在表单里塞 <input type="hidden" name="csrf_token" value="..."> 没用，后端不验证等于没设。
常见错误现象：用 gorilla/csrf 但密钥是短字符串（如 "abc"），或没给 Cookie 设置 HttpOnly 和 Secure 标志。
-
gorilla/csrf.Protect的密钥必须是 32 字节随机值，硬编码字符串要先sha256.Sum256处理再截取，否则易被暴力破解 - 必须显式调用
csrf.Token(r)传给模板，且前端 JS 提交时需通过Cookie或Header（非 URL 参数）携带 token - API 场景若不用 Cookie 认证（如 JWT），CSRF 本身不适用，但需确认是否误启了
SameSite=None却没配Secure
加密与密钥：AES-GCM 的 nonce 绝对不能复用
加密逻辑写对一半，比完全不加更危险——比如用了 AES-GCM 却固定 nonce，攻击者拿到两个密文就能恢复明文。
常见错误现象：用 make([]byte, gcm.NonceSize()) 初始化全零 nonce，或从时间戳生成 nonce 导致碰撞。
- 每次加密必须用
crypto/rand.Read生成随机nonce，长度严格等于gcm.NonceSize() - 密钥绝不能硬编码，生产环境必须从 KMS 或环境变量注入；本地开发可用
.env，但要加进.gitignore - 敏感数据落库前，优先用
bcrypt或argon2哈希密码，而非对称加密——后者密钥管理成本高，且无必要
最常被忽略的是：错误处理本身会泄露信息。比如 http.Error(w, err.Error(), http.StatusInternalServerError) 把数据库连接失败详情直接打给前端，等于告诉攻击者你用的是 PostgreSQL 还是 MySQL。所有错误响应必须抽象为通用提示，详细日志只写进服务端。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
