Julia中struct、mutable struct、Dict、named tuple、DataFrame的使用时机

不可变 struct #

• 核心属性：完全不可变，实例创建后所有字段无法修改；只要字段类型可被编译期推导，性能为所有自定义类型里的最高水平，无额外内存开销、无动态派发损耗。
• 适配场景：
  • 无状态的领域实体建模，比如几何点、向量、常量配置、纯计算中间值，需要跨函数传递且全程不需要修改内部字段的场景
  • 需要作为字典键、集合元素的场景，天然满足哈希一致性要求
  • 核心数值计算模块的自定义数据载体，最大化利用Julia的编译期性能优化能力

mutable struct #

• 核心属性：完全可变，实例创建后所有字段可任意修改；如果给每个字段加了明确的类型标注，性能和不可变struct几乎无差异；未标注类型时会引入动态类型开销，性能明显下降。
• 适配场景：
  • 需要维护连续可变状态的实体，比如数值仿真的过程状态、机器学习模型的训练参数、带生命周期的资源句柄
  • 需要在函数内通过引用修改实例字段、避免值传递带来的整对象拷贝开销的场景
  • 字段集合固定、但字段值需要在运行时动态更新的业务逻辑

具名元组（named tuple） #

• 核心属性：完全不可变，支持通过字段名快速访问元素；不需要提前声明类型，编译期可完全推导所有元素类型，访问性能和不可变struct基本持平。
• 适配场景：
  • 函数多返回值、临时参数组传递等轻量聚合场景，不需要为了临时几个值专门定义struct类型
  • 原型开发阶段的快速数据载体，省去struct定义的样板代码成本
  • 需要字段名可读性、同时要求高访问性能的不可变小体量数据存储

Dict #

• 核心属性：完全可变，键值对可任意增删改；属于动态哈希查找结构，每次键值访问都需要完成哈希计算、查找流程，编译期无法确定键的固定类型，整体访问性能远低于struct、具名元组这类静态结构。
• 适配场景：
  • 键集合在运行时动态变化、无法提前确定固定字段的场景，比如用户自定义扩展属性、动态加载的配置映射
  • 对应结构本身schema不固定的数据源，比如非结构化的爬取结果JSON、用户动态提交的表单数据
  • 非核心计算路径的逻辑，优先追求灵活性而非极致性能的场景

DataFrame #

• 核心属性：完全可变，支持列、行的任意增删改，可存储异构类型的列数据；单元素逐点访问的性能远低于上述结构化类型，但面向整列的批量向量化操作做了专门优化。
• 适配场景：
  • 二维表格类数据集的存储与处理，比如实验结果统计、结构化数据清洗、报表类数据分析流程
  • 需要对整列做批量变换、聚合、多表连接的分析场景，不适合逐行单元素遍历的高性能计算需求
  • 数据分析全流程的通用中间载体，衔接数据加载、特征工程、结果可视化等环节

选型核心判断逻辑：优先选择编译期可完全推导类型的静态结构，仅当确实需要动态灵活度时，才选择性能更低的动态结构；可变性需求越强、schema灵活性要求越高，对应的结构性能损耗通常越大。

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