buffalo模板中时间字段需手动格式化，如{{.createdat.format("2006-01-02 15:04:05")}}；数据库迁移需统一postgresql并显式建索引；json序列化应自定义类型实现marshaljson；参数解析须用time.parseinlocation并多格式兼容。
Buffalo模板里显示时间字段总出错？默认不格式化，必须手动转
Buffalo的time.Time字段在模板中直接{{.CreatedAt}}会输出完整Go时间字符串（如2026-09-20 10:26:42.123456789 +0200 CEST），前端无法直接消费，也不符合中文习惯。它不会自动调用.Format()，也不会读取time.RFC3339等预设常量。
实操建议：
- 在模板中显式调用
.CreatedAt.Format("2006-01-02 15:04:05")——注意Go的格式串是唯一固定写法，不能用YYYY-MM-DD这类惯用写法 - 若需时区转换（比如存UTC、展示本地时间），先用
.In(location)，再.Format()；别依赖浏览器JS自动转，服务端统一处理更可靠 - 避免在模板里做计算（如
.AddDate(0,0,-7)），逻辑应前置到handler或model层，模板只负责呈现
数据库迁移里定义datetime字段，PostgreSQL和SQLite行为不一致
Buffalo用pop生成迁移时，time.Time字段在不同数据库后端映射不同：PostgreSQL用t.Timestamp("created_at")生成timestamp with time zone，而SQLite只存为文本（ISO8601字符串）。这会导致跨环境测试时时间比较失效，比如WHERE created_at > ?在SQLite可能走全表扫描。
实操建议：
- 开发阶段统一用PostgreSQL，避免SQLite“看起来能跑”的假象
- 迁移中显式指定精度：
t.Timestamp("created_at", {precision: 6})确保微秒级支持（尤其用于排序或并发写入场景） - 不要依赖
pop.MigrationTimestamps()自动生成字段——它对SQLite不加索引，查询慢；手动为created_at和updated_at加t.Index("idx_created_at")
API JSON响应里时间字段带时区偏移，但前端期望纯ISO字符串
Buffalo默认用json.Marshal序列化time.Time，输出带Z或+0200的RFC3339字符串。某些前端库（如Day.js旧版）解析失败，或Axios拦截器误判为无效日期。
实操建议：
- 全局禁用默认时间序列化：在
app.go初始化前加json.Marshal = func(v interface{}) ([]byte, error) { ... }不推荐——破坏其他包兼容性 - 更稳妥的是在model结构体上加JSON tag：
CreatedAt time.Time `json:"created_at,omitempty,time_rfc3339"`，但time_rfc3339只输出无偏移的2006-01-02T15:04:05Z，仍含Z - 真正可控的做法：定义自定义类型封装
time.Time，实现MarshalJSON()返回"2006-01-02 15:04:05"字符串（无T、无Z、无毫秒）
Handler里解析时间参数容易panic，因为buffalo.Context.QueryParam不校验格式
c.Param("date")或c.QueryParam("from")返回string，直接传给time.Parse()会因格式不匹配panic。Buffalo不提供内置时间参数绑定，不像gin有BindQuery自动转类型。
实操建议：
- 永远用
time.ParseInLocation()而非time.Parse()，显式指定time.Local或time.UTC，避免夏令时歧义 - 接受多种格式（如
"2006-01-02"和"2006-01-02T15:04:05"）时，写个parseTimeAny()函数逐个尝试，别只试一种 - 错误处理必须返回HTTP 400及明确提示，例如
c.Error(400, fmt.Errorf("invalid date format for 'from': %s", from))，不能静默fallback到零值
