XmlSerializer 默认将 DateTime 按 ISO 8601 格式序列化，但不保存本地时区偏移；仅支持 DateTimeKind.Utc 或 Unspecified，Local 会被降级为 Unspecified，导致反序列化后时区误判。
XmlSerializer 默认怎么序列化 DateTime
XmlSerializer 会把 DateTime 按照 ISO 8601 格式（如 "2024-05-20T14:30:45.123Z"）输出，且默认使用 DateTimeKind.Utc 或 DateTimeKind.Unspecified —— 它**不会保存本地时区偏移量**，除非你显式设置 DateTimeKind.Local 并启用 XmlSerializer 的时区感知行为（实际不支持）。这意味着：
new DateTime(2024, 5, 20, 14, 30, 45, DateTimeKind.Local)序列化后可能变成
"2024-05-20T14:30:45"（丢掉时区信息），反序列化时会被当作 Unspecified，后续调用 .ToUniversalTime() 可能出错。
想自定义 DateTime 格式？别直接改 XmlSerializer
XmlSerializer 不提供格式化回调或 ToString("yyyy-MM-dd") 类接口。强行用 [XmlAttribute] 或 [XmlElement] 的 DataType 属性（如 DataType = "date"）只影响 XSD 生成，**不改变实际序列化行为**。真正可控的方式只有两个：
- 把
DateTime字段换成string属性，手动控制格式（推荐用于简单场景） - 实现
IXmlSerializable，完全接管序列化逻辑（适合需要精确控制时区或兼容旧系统）
例如，用字符串属性替代：
public class Order
{
[XmlElement("OrderDate")]
public string OrderDateString
{
get => Date?.ToString("yyyy-MM-dd");
set => Date = string.IsNullOrEmpty(value) ? null : DateTime.ParseExact(value, "yyyy-MM-dd", null);
}
[XmlIgnore]
public DateTime? Date { get; set; }
}
处理时区：Local vs Utc vs Unspecified 的坑
最常见错误是把 DateTime.Now 直接序列化，然后在另一台机器反序列化后调用 .ToLocalTime() —— 因为原始值被存为 Unspecified，.NET 会按当前系统时区解释，结果偏差可能达数小时。安全做法：
- 统一用
DateTime.UtcNow存储和传输，业务层再转本地时间 - 如果必须传带偏移的 DateTime，改用
DateTimeOffset类型（XmlSerializer原生支持，序列化为"2024-05-20T14:30:45.123+08:00"） - 避免依赖
DateTime.Kind == Local，它在跨时区服务间不可靠
反序列化失败常见原因
遇到 InvalidOperationException 提示“字符串未被识别为有效的 DateTime”，大概率是输入格式不匹配。XmlSerializer 只认标准 ISO 格式（含可选毫秒、时区），不支持 "2024/05/20" 或 "20-05-2024"。解决方法：
- 预处理 XML 字符串，用正则替换非标日期为 ISO 格式（慎用）
- 改用
XmlConvert.ToDateTime(string, XmlDateTimeSerializationMode)手动解析，再赋值给对象 - 更稳妥：用
System.Text.Json或Newtonsoft.Json替代 XML，它们对日期格式宽容得多
真正麻烦的不是怎么写序列化逻辑，而是团队里有人悄悄用了 DateTime.Now.ToString("MM/dd/yyyy") 再塞进 XML 字段——这种隐式格式一旦上线，排查成本远高于早期约定好用 DateTimeOffset 或 ISO 字符串。
