ServiceStack JsonServiceClient 请求中DateTime序列化行为不一致原因排查

首先，你的问题核心出在ServiceStack.Text（ServiceStack默认的JSON序列化库）的全局DateTime序列化配置上，以及它的静态特性带来的影响：

为什么会出现时而正常、时而异常的序列化行为？ #

ServiceStack.Text通过静态类JsConfig来全局控制序列化行为，其中JsConfig.DateHandler属性决定了DateTime类型的序列化方式，常见的选项有：

• DateHandler.ISO8601（默认）：将DateTime序列化为yyyy-MM-dd（日期）或带时间的ISO格式字符串
• DateHandler.UnixTime：将DateTime序列化为Unix时间戳（long类型数字）
• DateHandler.RFC1123：序列化为RFC1123格式的字符串

之所以会出现时而正常、时而异常的情况，大概率是你的项目中有某处动态修改了这个全局静态配置，但没有恢复。比如：

• 某个初始化方法、第三方库、或者特定请求的处理代码中，临时设置了JsConfig.DateHandler = DateHandler.UnixTime;
• 由于JsConfig是全局静态的，这个修改会影响所有后续的JSON序列化操作，直到被改回原来的配置
• 当配置是默认的ISO8601时，你的Date属性会序列化为yyyy-MM-dd字符串（请求正常）；当配置被改成UnixTime时，就会序列化为long类型的时间戳（请求失败）

为什么将DateTime改为string能解决问题？ #

当你把Date属性的类型从DateTime改为string后，ServiceStack的序列化器会直接输出你预先格式化好的字符串值，不再触发DateTime类型的特殊序列化逻辑，也就不受全局JsConfig.DateHandler配置变化的影响了。无论全局配置怎么改，输出的始终是你构造函数中指定的yyyy-MM-dd格式字符串，自然就不会出现请求失败的情况。

额外建议 #

如果你想继续使用DateTime类型而不改成string，可以在请求类的属性上添加特性指定局部序列化方式，覆盖全局配置：

[DataMember(Name = "date")]
[JsonConverter(typeof(DateTimeConverter))] // 强制使用ISO8601格式序列化
public DateTime Date { get; init; }

或者在项目启动时显式固定全局配置，避免后续被意外修改：

JsConfig.DateHandler = DateHandler.ISO8601;

内容的提问来源于stack exchange，提问作者LorneCash