C#中构造函数的输入参数多少个算过多？110个参数是否合理？

构造函数参数数量的合理范围 #

通常业务代码中，构造函数参数超过3~5个就建议做结构优化，110个参数的构造函数技术上可以通过编译，但工程层面完全不可行：

• 参数顺序极易传错，一旦传错排查成本极高
• 后续要增删属性时，所有调用构造函数的地方都要同步修改，维护成本爆炸
• 代码可读性极差，其他人根本没法快速理解每个参数的含义

你当前方案的问题 #

你当前的实现逻辑可跑，但完全不适合110个属性的场景，手动传110个参数的出错概率接近100%，后续迭代也无法维护。

适配场景的优化方案 #

1. 替换全参数构造函数，使用对象初始化器 #

首先不要用File作为类名，会和.NET内置的System.IO.File类产生命名冲突，建议改为FileData/FileItem这类命名。类中直接定义自动属性，不需要写全参数构造函数，初始化时通过属性名赋值，顺序不受限制，出错也能快速定位：

public class FileItem
{
    public string Name { get; set; }
    public string Id { get; set; }
    public int Comment { get; set; }
    public string Speed { get; set; }
    // 剩余107个属性直接在此处定义即可
}

// 初始化及集合操作代码
List<FileItem> fileList = new List<FileItem>();
fileList.Add(new FileItem
{
    Name = "name",
    Id = "id",
    Comment = 1,
    Speed = "100kb/s"
    // 剩余属性按需赋值，顺序不影响正确性
});

2. 批量结构化解析文本文件 #

如果你的文本文件是固定格式（比如CSV、每行字段固定分隔、JSON格式），可以直接写统一的解析方法，把每行文本自动映射为FileItem对象，不需要手动给每个属性赋值，3000个文件可以直接批量遍历解析，效率比手动传参高很多。

3. 用记录类型简化数据承载类（C# 9+ 支持） #

如果你的类只用来承载属性、不需要额外的业务方法，可以用C#的记录（Record）类型定义，语法更简洁，还自带值比较能力，适合数据导出场景：

public record FileItem(
    string Name, 
    string Id, 
    int Comment, 
    string Speed
    // 剩余属性继续往后定义
);

4. 批量映射导出Excel #

导出Excel时可以直接用对象映射能力，不需要手动给每个单元格赋值，只要给属性加上对应Excel列的映射标记，就可以直接把整个List<FileItem>批量导出到Excel，进一步减少重复代码。

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