在LINQ的Select方法中，构造函数与对象初始化器的选择及性能对比

先看两种写法的示例：

使用对象初始化器：

var list = ApplicationContext.Employees
    .Select(x => new Employee()
    {
        FirstName = x.FirstName,
        LastName = x.LastName
    });

使用构造函数：

var list = ApplicationContext.Employees
    .Select(x => new Employee(
        x.FirstName,
        x.LastName
    ));

一、可空类型场景下的实用性对比 #

• 构造函数更适配可空类型规范：启用可空引用类型后，构造函数可以强制要求所有必填字段在对象创建时就完成赋值，从根源上避免可空警告——你没法跳过构造参数直接创建属性不完整的对象。这能保证DTO的完整性，减少后续空引用异常的风险。
• 对象初始化器的局限性：如果DTO的属性标记为非空引用类型或不可空值类型，使用初始化器时若漏写属性赋值，编译器会直接抛出可空警告。虽然可以用!抑制警告或给属性设默认值，但这两种方式都不够严谨，容易埋下隐患。

二、性能差异分析 #

• 常规业务场景下无明显差异：不管是构造函数还是初始化器，最终编译后的IL代码逻辑基本一致——都是先调用构造函数（即使是无参构造），再完成属性赋值。JIT编译阶段还会做进一步优化，实际运行时的性能差距可以忽略不计。
• 极端大规模场景下的微弱差距：理论上构造函数略占优势，因为它能在构造阶段直接完成参数赋值，减少一次属性赋值的步骤。但这种差异只有在创建百万级以上对象时才可能被检测到，绝大多数业务场景下完全无需纠结这点性能。

三、其他考量因素 #

• 代码可读性与维护性：
  • 若DTO必填字段较少，初始化器的写法更直观，能一眼看到每个属性对应的数据源；
  • 若字段较多，构造函数的参数顺序容易出错，可搭配命名参数（new Employee(FirstName: x.FirstName, LastName: x.LastName)）来提升可读性。
• 扩展性：如果后续给DTO新增必填字段，构造函数会让所有调用处直接编译报错，强制开发者修改，不容易遗漏；而初始化器只会抛出可空警告，可能被忽略，导致创建出不完整的对象。
• ORM兼容性：部分ORM框架（如EF Core）对构造函数的支持更友好，甚至允许使用私有构造函数封装DTO的创建逻辑，而初始化器则依赖公共属性的可访问性。

总结 #

在启用可空引用类型的项目中，优先选择构造函数——它能保证对象完整性、规避可空警告，在扩展性和安全性上更有优势。如果是简单DTO或追求代码直观性，初始化器也可以使用，但需注意严谨处理可空警告。性能差异在绝大多数场景下可以忽略，不用作为核心决策依据。

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