槽位布局模式的定义与核心思想

槽位布局模式（Slot Layout Pattern）是 Compose 声明式 UI 体系中用于分离布局结构与内容填充的一种架构设计。其核心主张是：先将界面拆分为若干个固定的“槽位”，再由调用方决定每个槽位中渲染什么内容。这种模式并非 Compose 独有，但在 Compose 的组合式 API 中被提升为第一等公民，直接对应 @Composable 签名的参数化插槽。

槽位概念：从占位符到组合契约

槽位（Slot）本质上是一个声明式的占位参数，接收一个 @Composable lambda 表达式。容器组件只管理插槽的排列顺序、间距、动画和交互区域，不关心插槽内部的具体 UI。典型的槽位声明形式如下：

@Composable
fun CardLayout(
    header: @Composable () -> Unit,
    body: @Composable () -> Unit,
    footer: @Composable () -> Unit
) {
    Column {
        Box(modifier = Modifier.background(Color.LightGray)) { header() }
        Box(modifier = Modifier.weight(1f)) { body() }
        Box(modifier = Modifier.background(Color.Gray)) { footer() }
    }
}

调用方将任意 @Composable 函数传入槽位：

CardLayout(
    header = { Text("Title", fontWeight = FontWeight.Bold) },
    body = { LazyColumn { /* 列表项 */ } },
    footer = { Button(onClick = { /* 操作 */ }) { Text("确认") } }
)

传统 Android ViewGroup 布局中，容器通过 addView 动态添加子视图，子视图需与容器的 LayoutParams 耦合；而 Compose 槽位通过参数化 lambda 彻底解耦了“布局在哪里”与“布局里面有什么”。

布局分离原则：容器与内容的职责边界

槽位布局将 UI 组件划分为两类角色，形成清晰的分层与职责边界：

下图展示了槽位布局的核心结构：容器声明三个插槽（上、中、下），内容组件分别插入，容器完全不知道插槽内具体渲染什么。

组合优于继承：为何槽位模式胜过基类复用

传统 View 体系使用继承复用布局：BaseCardView 定义骨架，子类重写 onFinishInflate 填充内容。这种做法带来三个问题：

1. 继承强耦合：子类必须知晓父类内部结构，修改父类布局可能导致所有子类失效。
2. 菱形继承风险：多维复用（如同时需要 Card 和 Dialog 行为）导致接口爆炸。
3. 运行时类型锁定：父类强制子类持有特定 View 引用，难以组合第三方组件。

槽位模式采用组合替代继承：容器提供槽位参数，调用方将任意 Composable 函数作为参数传入。这种设计天然支持多态、依赖注入和跨模块复用，且 Compose 编译器会对每个槽位进行独立重组优化，只更新变动的插槽内容。

风险点与落地步骤

实施槽位布局模式时需关注以下风险：

• 性能陷阱：槽位内部的 Composable 不应直接读写父容器的状态，否则会导致整个容器重组。应通过状态提升将数据通过插槽参数下发。
• 槽位名称冲突：当多个容器提供相同名称的槽位（如 content）时，开发者需依靠严谨的类型约束或命名空间避免混淆。
• 文档缺失：槽位模式强调“契约”，缺失结构定义易导致滥用。建议为每个容器组件配备显式的槽位类型文档。

团队落地步骤建议：

1. 识别复用场景：在项目现有布局中找出重复的框架结构（如统一卡片、列表页、弹窗）。
2. 提取槽位契约：将容器布局中的可变区域抽象为 @Composable 参数，定义参数名称和默认值。
3. 编写验收用例：用单元测试验证槽位参数的正确性（如使用 ComposeTestRule 检查槽位内容是否按预期显示）。
4. 渐进替换：优先在新页面使用槽位容器，逐步重构旧页面时保持兼容。

验收标准

第 1 章内容完成后，学员应能够：