验证函数须独立于业务逻辑，置于专用包中且无外部依赖，单一职责、返回error、支持组合；正则校验应按场景取舍，避免过度遵循rfc；validator库仅作格式检查，非安全加固；验证失败必须显式中断流程。
验证函数必须独立于业务逻辑调用
验证函数如果直接嵌在 handler 或 service 里，容易被绕过、复用困难、测试成本高。真正能形成“防御链路”的前提是：验证逻辑可拆分、可组合、可提前拦截。
推荐做法是把 Validate 方法或 validateXxx() 函数放在独立包（如 pkg/validator）中，且不依赖任何 HTTP 或数据库上下文：
- 每个验证函数只做一件事，比如
validateEmail()只校验邮箱格式，不查重、不发邮件 - 避免在验证函数里调用
database/sql或http.Client—— 这类操作属于业务层，不是合法性判断 - 对同一字段可叠加多个验证器，例如：
validateNonEmpty()+validateMaxLength(50)+validateEmail() - 返回
error而非布尔值，方便统一收集错误（如用multierror合并）
正则验证要区分场景选模式，别硬套 RFC
用正则校验邮箱、URL 或用户名时，过度追求“完全符合 RFC”反而导致误判和维护负担。实际项目中应按业务接受度取舍。
例如邮箱验证，^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$ 看似严谨，但会拒绝 user+tag@example.com（合法且常用）；而太宽松的 @ 存在检查又形同虚设。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 注册阶段建议用较宽松正则（如允许
+和子域名），再配合 SMTP 验证兜底 - 登录阶段可直接用数据库查存在性，不必重复校验格式
- 用户名避免
.*全匹配，优先白名单：用^[a-zA-Z0-9_]{2,20}$比^.*$+ 黑名单过滤更可靠 - 注意
regexp.MustCompile是编译开销，应提前提前初始化为全局变量，别在每次请求里重复调用
结构体标签 + 自定义 validator 不等于安全
很多人用 github.com/go-playground/validator/v10 加 struct tag 实现一键校验，但这只是便利性工具，不是安全加固手段。
它的默认行为不防 XSS、不清理 HTML、不处理 Unicode 归一化、也不校验长度上限外的截断风险。它只做“格式通不过就报错”，而真正的防御链路需要更多动作：
-
validate:"email"不等于“邮箱真实可用”，它只是字符串模式匹配 -
validate:"min=6,max=128"对密码字段有意义，但对用户名可能漏掉空格、零宽字符等隐形非法输入 - 若字段含富文本（如用户 bio），validator 无法替代
bluemonday这类 HTML 消毒库 - 敏感字段（如手机号、身份证号）需额外加
validate:"required,excludesall=\"&'"防注入，而非仅靠required
验证失败后必须中断流程，不能只打日志
常见错误是验证返回 error 后没做 return，导致后续代码仍执行 —— 这会让整个防御链路失效。
尤其在 Gin/Echo 等框架中，容易误以为中间件已“拦住”请求，其实 handler 内部仍需显式终止：
- 不要写：
if err := validateInput(req); err != nil { log.Printf("invalid input: %v", err) }—— 这之后还继续处理业务 - 正确写法是：
if err := validateInput(req); err != nil { c.JSON(400, map[string]string{"error": err.Error()}); return } - 对结构体批量验证，建议用 early-return 模式，而不是收集所有错误再统一返回（除非明确需要前端展示全部问题）
- HTTP 响应状态码要匹配语义：
400 Bad Request表示客户端数据错，422 Unprocessable Entity更适合表单级语义错误
if，而在于每层验证的职责边界是否清晰、失败路径是否不可绕过、以及错误反馈是否既准确又不泄露内部信息。一个字段校验了三次（前端、中间件、service），不如一次校验到位且执行彻底。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
