go json.marshal 默认输出纳秒级rfc3339时间，需自定义类型实现json.marshaler接口以控制格式，标准库不支持time_format tag。
Go json.Marshal 输出时间不是 RFC3339？
默认情况下，json.Marshal 会把 time.Time 序列化成带纳秒精度的 RFC3339 字符串（如 "2024-05-20T14:23:18.123456789+08:00"），但多数 API 不需要纳秒、也不想要时区偏移里的冒号。这不是 bug，是 Go 的设计选择——它优先保证可逆性，而非“好看”。
常见错误现象：
前端解析失败、数据库入库报错、日志里时间字段太长难读、和 Python/Java 服务对接时格式不一致。
- 别试图用
fmt.Sprintf预先转成字符串再塞进 struct —— 这会让反序列化失效，且破坏类型安全 - 别在每次 Marshal 前手动调用
.Format()—— 失去结构体统一控制，容易漏改 - 真正该做的是让
time.Time自己知道怎么序列化
自定义 Time 类型实现 json.Marshaler 接口
最稳妥的做法是定义一个新类型，嵌入 time.Time，然后实现 MarshalJSON() 和 UnmarshalJSON()。这样既复用原生能力，又完全掌控序列化行为。
典型使用场景：API 响应中的 created_at、updated_at 字段必须为 "2006-01-02 15:04:05" 格式（MySQL 默认 datetime 格式）。
立即学习“go语言免费学习笔记（深入）”；
示例：
type JSONTime time.Time
<p>func (t JSONTime) MarshalJSON() ([]byte, error) {
st := time.Time(t).Format("2006-01-02 15:04:05")
return []byte(<code>"</code> + st + <code>"</code>), nil
}</p><p>func (t <em>JSONTime) UnmarshalJSON(data []byte) error {
s := strings.Trim(string(data), <code>"</code>)
tt, err := time.Parse("2006-01-02 15:04:05", s)
if err != nil {
return err
}
</em>t = JSONTime(tt)
return nil
}- 注意：
UnmarshalJSON必须是指针接收者，否则修改不了原值 - 格式字符串必须是 Go 的固定基准时间
"2006-01-02 15:04:05"，写错会 panic - 如果要支持 UTC 或固定时区，
time.Time(t).In(time.UTC).Format(...)更安全
struct tag 里加 time_format 不起作用？
Go 原生 encoding/json **不识别** time_format 这类 tag（那是 github.com/goccy/go-json 或某些 ORM 才支持的）。写 json:"created_at,time_format:\"2006-01-02\"" 完全无效，字段照样按默认 RFC3339 输出。
容易踩的坑：
- 误以为加了 tag 就能控制格式，结果上线才发现时间字段还是带纳秒
- 混用多个 JSON 库（比如同时引入
go-json和标准库），导致行为不一致 - 依赖第三方库的 tag 支持，却没确认其是否真参与了 Marshal 流程
结论：tag 控制格式只在特定生态内有效；标准库路径下，唯一可靠方式仍是自定义类型 + 接口实现。
要不要全局替换 time.Time？
不建议。全局替换意味着所有地方（包括日志、DB 驱动、HTTP header 时间头）都受你定义的格式影响，而这些地方往往要求 RFC3339 或 Unix 时间戳。
更合理的做法是按需封装：
- 给 HTTP 响应结构体用
JSONTime - 给数据库模型（如 GORM）用原生
time.Time，靠 driver 处理 - 跨服务通信字段明确标注格式要求，避免“我以为你懂”
性能上，自定义类型几乎没有开销；但如果你在高并发接口中频繁创建临时 JSONTime 实例，要注意 GC 压力 —— 此时可考虑复用格式化后的字符串缓存（不过大多数场景没必要）。
真正容易被忽略的是时区：time.Time 本身带时区信息，但 Format 只输出本地表现。如果数据来自不同时区的服务，光改格式不够，得统一入库/传输前的时区归一化逻辑。
