TRPC项目中日期类型在PostgreSQL与客户端间的序列化问题

概述

在TRPC与Prisma集成的项目中，开发者经常遇到数据库日期类型与客户端类型不匹配的问题。本文将以PostgreSQL数据库为例，深入分析DateTime类型在前后端传输过程中的类型转换机制。

问题本质

当使用Prisma定义包含DateTime类型的模型时，例如消息记录中的时间戳字段，PostgreSQL会将其存储为"timestamp without time zone"类型。然而在数据传输过程中，这个类型会经历以下转换：

1. 数据库层面：PostgreSQL原生存储为timestamp类型
2. Prisma层：转换为JavaScript的Date对象
3. 序列化层：通过JSON传输时被转换为ISO格式字符串

技术原理

问题的核心在于JSON规范本身不支持Date对象。当使用JSON.stringify()序列化包含Date对象的数据时，会自动转换为ISO 8601格式的字符串。例如：

JSON.stringify({ date: new Date() })
// 输出：'{"date":"2024-08-30T18:33:39.990Z"}'

TRPC为了保持与JSON规范的一致性，默认也会采用相同的类型转换行为，导致客户端接收到的类型是string而非Date。

解决方案

对于需要保留Date类型的场景，推荐使用数据转换器(data transformer)。TRPC提供了多种转换器选项：

1. SuperJSON转换器：能够智能地处理Date、Map、Set等复杂类型
2. 自定义转换器：开发者可以自行实现符合业务需求的序列化逻辑

实现方式是在TRPC客户端和服务端配置相同的转换器，确保序列化和反序列化的对称性。这种方案既保持了类型安全，又无需开发者维护多套类型定义。

最佳实践

1. 对于简单场景，可以直接使用ISO字符串格式，在前端需要时再转换为Date对象
2. 对于复杂应用，建议统一配置SuperJSON转换器，减少类型转换的认知负担
3. 在类型定义时，明确区分传输类型(Transport Type)和业务类型(Domain Type)

总结

TRPC与Prisma集成时遇到的日期类型问题，本质上是JSON序列化的限制所致。通过理解数据在各层的转换过程，开发者可以选择最适合项目需求的解决方案。对于重视类型安全的项目，采用数据转换器是最为稳健的方案。