3. 槽位布局与其他布局模式对比：Slot模式 vs 参数化布局 vs 继承布局
3.1 三种模式的边界定义
在Compose架构设计中，UI组件的可扩展性通常通过三种模式实现：Slot（槽位）模式、参数化布局和继承布局。理解它们的边界、适用场景与权衡，是架构选型的关键前提。
| 对比维度 | Slot模式 | 参数化布局 | 继承布局（传统View） |
|---|---|---|---|
| 核心思想 | 通过@Composable lambda暴露插槽 |
通过枚举/配置参数控制子组件渲染 | 通过基类方法重写扩展行为 |
| 组件职责 | 定义骨架与插槽位置，不关心插槽内容 | 完全控制所有子组件类型与顺序 | 父类定义生命周期，子类注入逻辑 |
| 依赖方向 | 容器 → 插槽（内容由调用方注入） | 容器 → 子组件（容器决定渲染） | 子类 → 父类（强耦合） |
| 测试成本 | 低（可独立测试骨架） | 低（参数驱动） | 高（需要构建完整继承链） |
3.2 分层与组件职责
从架构分层角度来看，三种模式在组件树中的位置与职责完全不同：
- Slot模式：位于容器层，提供“占位符”而非具体UI。职责是只关心布局结构，不负责内容的具体渲染。
- 参数化布局：位于组合层，通过配置参数决定子组件的数量、类型和顺序。职责是完全控制子组件，适用于业务逻辑固定的场景。
- 继承布局：位于View体系基类层，通过重写
onDraw、onLayout等方法实现行为扩展。职责是扩展基类能力，但导致子类与父类高度耦合。
⚠️ 风险提示：继承布局在Compose中已不推荐使用。传统View系统的继承模式与Compose的声明式范式冲突，容易引发重组边界模糊、状态泄漏等问题。
3.3 数据流 / 控制流对比
- Slot模式：数据流从外部注入插槽lambda，容器不持有子组件状态。控制流由调用方完全掌握，插槽内的UI可以随时替换。
- 参数化布局：数据流由容器统一分发，子组件完全由参数控制。控制流单一且可预测，但扩展性受限——新增子组件类型需要修改容器代码。
- 继承布局：数据流通过父类方法传递，子类通过覆写改变行为。控制流分散在继承链各处，维护困难且难以追踪。
💡 建议：当需要构建可替换的UI区域时，优先选择Slot模式；当子组件类型固定且不常变化时，参数化布局更简单可控。
3.4 选型权衡分析
| 决策场景 | 推荐模式 | 理由 |
|---|---|---|
| 通用容器（如Dialog、Card、List） | Slot模式 | 最大灵活度，调用方可任意组合内容 |
| 业务组件（如用户卡片、商品项） | 参数化布局 | 字段固定，参数化更简单，测试友好 |
| 跨平台UI基础组件（传统View库） | 继承布局（过渡方案） | 逐步迁移到Compose可用，但不推荐新开发 |
| 需要高复用、低耦合的UI片段 | Slot模式 | 组件职责清晰，插槽可独立演进 |
3.5 风险点与落地步骤
常见风险：
- 过度参数化：参数过多导致复杂度和测试成本上升，应拆分为多个子组件。
- Slot滥用：在单一用途组件中使用Slot模式，反而增加不必要的间接层。
- 继承污染：Compose中继承布局导致重组边界混乱，应使用组合替代继承。
落地步骤建议：
- 识别组件用途：明确组件是通用容器还是业务组件。
- 选择模式：通用容器→Slot模式；业务组件→参数化布局；遗留View体系→封装为Compose包装器。
- 定义插槽契约：若采用Slot模式，明确插槽的数量、命名与类型。
- 隔离测试：对骨架和插槽分别编写测试用例，确保独立可测。
3.6 验收标准
- 组件职责单一，不混用多种模式。
- Slot模式的插槽数量不超过3个，避免嵌套过深。
- 参数化布局的参数数量不超过5个，否则考虑拆分子组件。
- 继承布局仅在封装遗留View库时使用，并有明确的Compose替换计划。
❖ 核心原则：Slot模式是Compose架构中实现高内聚低耦合的首选方式。参数化布局适合固定业务，继承布局应作为过渡方案尽快替换。