为何heightForRowAt属于UITableViewDelegate而非UITableViewDataSource？

这个设计本质上是苹果对两个协议的职责边界做的明确拆分，看似反直觉，实际遵循了UI层架构的解耦原则，核心原因可以分为三类：

• 两个协议的核心职责天生不同 #

  UITableViewDataSource的定位是纯数据供给层，它只需要回答三个核心问题：

  列表有多少个分区？每个分区有多少行？每行对应的数据要绑定到哪个Cell上？
  它的所有方法都围绕「数据是什么」展开，不涉及任何和视图展示、交互相关的逻辑。而UITableViewDelegate的定位是视图表现与交互控制层，负责处理视图的布局、展示样式、用户交互响应等和渲染相关的逻辑，行高是典型的视图布局属性，自然归属于Delegate。

• 行高本质和数据没有强制绑定关系 #

  认为行高和内容挂钩就应该归DataSource是典型的认知误区，混淆了「数据内容」和「数据的展示规则」的边界。实际开发中大量场景下，同一份数据源的行高会随着视图环境变化而变化：
  • 横竖屏切换时，同一行内容的折行长度不同，行高会发生变化
  • 做字号适配、无障碍模式适配时，同一份数据的展示行高可能完全不同
  • 折叠/展开交互中，对应同一条数据的行高会随交互状态切换
    上述场景里数据源没有任何变化，变化的只是视图的展示规则，放在负责视图控制的Delegate中显然更合理。

• 为特殊场景提供更高的灵活性 #

  很多业务场景中行高和数据本身完全无关：比如固定高度的广告位、分隔占位行、自定义插入的装饰性行等，这些行的高度不需要依赖数据计算，放在DataSource中反而会破坏数据供给层的纯粹性。
  另外系统提供的自动行高UITableViewAutomaticDimension是基于Cell的Auto Layout约束自计算的，完全不需要数据源参与，放在Delegate中也符合逻辑。

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