C++成员初始化列表过于臃肿时是否应改用构造函数体内赋值？

确实存在这类场景，不过调整前需要先权衡可读性、性能、功能约束三者的优先级，不能盲目为了可读性改写法。

适合改为构造函数体内赋值的场景 #

• 类似你给出的示例：大量同类成员使用固定常量初始化，全堆在初始化列表里会导致列表超长，查找特定成员的初始化逻辑成本很高。挪到构造函数体内可以按功能分组编写：比如所有三维向量的赋值放一组，资源加载类（文件、模型）的初始化放一组，业务数据相关的赋值放一组，逻辑分层更清晰，可读性提升非常明显。
• 成员初始化需要依赖多步计算、分支判断的场景：如果硬塞到初始化列表里，往往需要写多层嵌套的三元表达式，或者额外封装独立的辅助函数，反而不如直接在构造函数体内写顺序判断、分步计算再赋值的逻辑容易理解。

调整前需要注意的约束 #

• 不是所有成员都能挪：如果成员是const修饰的常量、引用类型，或者本身没有默认构造函数、禁止拷贝赋值，就必须放在初始化列表里完成初始化，没法挪到函数体赋值。
• 要评估性能损耗：先默认构造再赋值的流程，比初始化列表直接构造多了一次赋值的开销，要是成员是你示例里的FileClass、Model、std::vector这类重资源类型，得先确认这部分额外开销是否可接受，如果是性能敏感的核心路径，哪怕初始化列表臃肿也不建议挪动。
• 要确认默认构造的副作用：部分类型的默认构造会自带额外行为（比如文件类默认构造会创建临时文件、打印调试日志），挪到函数体赋值会触发不必要的默认构造逻辑，可能带来非预期的问题。

更折中的优化方案 #

C++11之后支持类内默认初始化，你完全可以不用二选一：把用固定值初始化的成员直接在类定义时给初始值，比如vec3f m_Vec1 = {1.0f, 1.0f, 1.0f};，初始化列表里只需要放需要外部传参初始化的成员（比如示例里的m_Things、m_Size、自定义路径的m_SomeFile、m_Model），既不会让初始化列表过于臃肿，也能兼顾性能和正确性。

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