Kratos 中 protobuf Timestamp 必须用 ts.AsTime() 转 time.Time，反向用 TimestampFromTime(t)；需判空、时区统一处理、DB 存取需显式转换，JSON 传输严格遵循 RFC 3339。
在 Kratos 中，Timestamp 字段（通常来自 protobuf 的 google.protobuf.Timestamp）不能直接当 Go 的 time.Time 用，也不该手动字符串拼接或强转——它必须走标准的 proto 解析路径，否则会在序列化/反序列化、时区、精度（纳秒级）等环节出错。
proto 中的 Timestamp 必须用 proto 库解包
Kratos 的 HTTP 或 gRPC 接口若接收或返回 google.protobuf.Timestamp，底层是二进制 wire 格式，不是 JSON 字符串。你看到的 "2024-01-01T00:00:00Z" 是 JSON 编码后的表现，实际内存里是 seconds + nanos 两个 int64 字段。
- 错误做法：
json.Unmarshal([]byte(`{"created_at":"2024-01-01T00:00:00Z"}`), &req)后直接对req.CreatedAt调用.Format()—— 这会 panic，因为字段类型是*timestamp.Timestamp，不是time.Time - 正确做法：调用
ts.AsTime()转成time.Time，再操作；反向用timestamp.TimestampFromTime(t)构造 - 注意：如果 proto 字段是
optional google.protobuf.Timestamp created_at = 1;，那req.CreatedAt可能为nil，必须判空
JSON 传输时 Timestamp 的格式受 encoder 控制
Kratos 默认用 google.golang.org/protobuf/encoding/protojson（而非旧版 github.com/golang/protobuf/jsonpb），它的行为是：
- 输出时默认用 RFC 3339 格式（如
"2024-01-01T00:00:00.123456789Z"），带纳秒精度 - 输入时严格解析 RFC 3339，不接受
"2024-01-01 00:00:00"这类无 T/Z 的格式，会返回invalid timestamp错误 - 如需兼容更宽松格式（比如前端传的无时区字符串），不能改 encoder，而应在 biz 层做预处理：先按 string 接收，再用
time.ParseInLocation解析成time.Time，最后转timestamp.TimestampFromTime
数据库存取与 time.Time 类型字段对齐
Protobuf 的 Timestamp 和数据库（如 MySQL 的 DATETIME 或 TIMESTAMP）之间没有自动映射。常见错误是把 *timestamp.Timestamp 直接塞进 GORM 的 struct 字段（类型为 time.Time），导致零值或 panic。
- data 层读库后，用
ts.AsTime()赋值给time.Time字段 - 写库前，把
time.Time字段转成*timestamp.Timestamp再塞进 proto 结构体 - 别在 model struct 里混用
*timestamp.Timestamp和time.Time—— 会导致 GORM 无法识别字段，或 JSON 输出变成{"seconds":...,"nanos":...}而非时间字符串 - 如果 DB 存的是 Unix 秒数（int64），不要用
ts.AsTime().Unix()去比对，而应统一用ts.AsTime().UnixMilli()或显式截断纳秒，避免毫秒级误差
最易被忽略的是：proto Timestamp 默认时区是 UTC，但业务常需要本地时区语义（比如“今天 0 点”）。这种需求不能靠改 AsTime() 返回值的 location，而应在 biz 层明确做 time.In(location) 转换，并确保所有日志、缓存、下游接口的时区上下文一致——否则同一时间点在不同环节显示成两个日期，排查起来极难定位。
