时间参数校验不能只用time.Parse，因会忽略时区、空值、非法格式等边界问题；需用time.ParseInLocation统一时区，手动校验区间合法性并返回明确错误。
时间参数校验为什么不能只用 time.Parse
直接用 time.Parse 解析时间字符串再比较，看似可行，但会漏掉大量边界问题：比如 "2024-01-01" 和 "2024-01-01T00:00:00Z" 格式不同、时区未显式处理、空值或非法格式导致 panic。Gin 的 BindQuery 或 ShouldBind 默认不校验时间语义（只做结构绑定），必须手动介入。
用 time.ParseInLocation 统一时区再比对
Gin 接收的查询参数通常是字符串，比如 start=2024-01-01&end=2024-01-31。关键不是“能不能转”，而是“转成什么时间点”——本地时间？UTC？业务要求是“当天 00:00:00 到 23:59:59”还是“精确到秒的闭区间”？
- 始终指定
*time.Location，推荐用time.UTC或time.Local，避免隐式依赖服务器时区 - 解析失败必须返回明确错误（如
400 Bad Request），不能忽略err != nil - 闭区间校验要小心：若业务要求“包含起止日”，需将
end向后延一天再减一秒，或用Before/After配合AddDate(0,0,1)
示例片段：
loc := time.UTC
start, err := time.ParseInLocation("2006-01-02", c.Query("start"), loc)
if err != nil {
c.AbortWithStatusJSON(400, gin.H{"error": "invalid start date"})
return
}
end, err := time.ParseInLocation("2006-01-02", c.Query("end"), loc)
if err != nil {
c.AbortWithStatusJSON(400, gin.H{"error": "invalid end date"})
return
}
if start.After(end) {
c.AbortWithStatusJSON(400, gin.H{"error": "start must be before or equal to end"})
return
}
// 若需包含整日，end 范围应为 end.Add(24*time.Hour).Add(-time.Second)
用自定义 binding 实现复用校验逻辑
每次写重复解析逻辑容易出错，Gin 支持为结构体字段注册自定义 UnmarshalText 方法，配合 binding:"required,datetime=2006-01-02" 标签即可自动触发。
立即学习“go语言免费学习笔记（深入）”；
- 定义类型如
type DateRange struct { Start Date `form:"start" binding:"required"` } -
Date类型实现UnmarshalText，内部调用time.ParseInLocation并缓存err - 注意：Gin 的 binding 不会传播时区信息，必须在
UnmarshalText里硬编码time.UTC或从上下文传入 - 无法在 binding 层完成“区间合法性”判断（比如 start > end），这部分仍需在 handler 中单独校验
警惕 time.Now() 在测试和部署环境中的表现差异
开发时本地时区可能是 CST，CI 环境或 Docker 容器默认是 UTC，time.Now().Format("2006-01-02") 输出结果不同。如果校验逻辑里混用了 time.Now() 与用户传入的 UTC 时间，会导致白天请求被误判为“超出今日范围”。
- 所有涉及“当前时间”的比较，统一转成同一时区（推荐全链路用
time.UTC） - 单元测试中不要依赖真实
time.Now()，用func() time.Time注入或github.com/jonboulle/clockwork替换 - 线上排查时，打印出解析后的
start.Unix()和end.Unix()，比对数值而非格式化字符串
时间区间校验真正麻烦的从来不是语法，而是时区、精度、边界语义这三者的组合爆炸——少一个条件，就可能让“今天的数据”查不到，或者“昨天的订单”被误删。
