c#中[Datamember]特性的使用意义、优势及适用场景

它是.NET原生序列化体系里数据契约标记体系的配套特性，隶属于System.Runtime.Serialization命名空间，核心作用是配合类级别的[DataContract]特性，告诉专用的序列化器（DataContractSerializer）：当前这个类的哪些成员是需要被纳入序列化/反序列化范围的。
最核心的规则反转：只要给类打上了[DataContract]标记，这个类下的所有属性、字段——哪怕是public修饰的——默认全部不会被序列化。你必须手动给需要纳入序列化范围的成员打上[DataMember]，序列化器才会识别它。这和老的[Serializable]特性默认全量序列化公共成员、需要手动排除的逻辑完全相反。

举个简单的使用示例：

// 必须先加类级别的DataContract标记，DataMember才会生效
[DataContract]
public class UserInfo
{
    // 没有标记DataMember，哪怕是public也不会被序列化
    public string InternalTempId;
    // 不会被序列化的敏感字段，从机制上杜绝漏传
    public string PasswordHash { get; set; }

    // 标记需要序列化的成员，还可以自定义序列化规则
    [DataMember(Name = "user_name", IsRequired = true)]
    public string UserName { get; set; }

    [DataMember(EmitDefaultValue = true)]
    public string Remark { get; set; }
}

对比传统的序列化标记，它解决的都是实际开发中踩过的共性问题：

• 从机制上避免敏感信息误序列化：比如类里存了密码哈希、临时计算的中间值，只要没主动打[DataMember]标记，哪怕这些字段是public的，也永远不会被序列化出去，彻底杜绝敏感数据随对象传输漏出的风险
• 天然适配跨版本兼容：它自带的参数可以解决序列化对接的常见痛点：
  • 用Name参数可以实现序列化字段名和类内属性名的解耦，比如类里叫UserName，序列化出去的字段可以叫user_name，不用为了适配外部对接规则修改业务代码
  • 用IsRequired标记字段是否为必填，新增的成员设为非必填后，旧版本的客户端反序列化时不会因为缺字段直接抛错
  • 用EmitDefaultValue控制是否要序列化值为默认值（比如null、0）的成员，避免传输冗余的无效数据
• 跨场景的契约复用：这套标记是微软原生分布式通信栈的通用识别标记，同一份带[DataMember]标记的类，可以直接适配WCF服务通信、SOAP消息序列化、跨进程数据传输等多个场景，不需要为每个场景重复打不同序列化库的专属特性，减少重复配置的维护成本。

• 如果只给成员打[DataMember]，却不给所属的类打[DataContract]，这个标记完全不会生效。此时序列化器会退回默认的全公共成员序列化逻辑，很多人会因此觉得“加不加[DataMember]根本没区别”
• [DataMember]不是JSON序列化的专属特性，它和Newtonsoft.Json、System.Text.Json里的序列化标记是互相独立的，换用第三方JSON序列化库时，不会自动识别[DataMember]的配置

• 开发WCF分布式服务，跨机器/跨进程传输业务对象时，必须用[DataMember]标记要传递的字段，否则客户端无法正确接收数据
• 使用原生DataContractSerializer做对象持久化、SOAP报文生成时，需要靠这个标记明确序列化范围
• 项目里同时用到多个.NET原生序列化场景，需要用一套统一的标记减少重复配置成本时

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