支付流程UI组件拆分：状态与事件分离与职责边界

支付页面UI的组件化拆分是State Hoisting落地的基础。如果组件职责不清、状态与事件混在一起，状态提升不仅不能简化逻辑，反而会引入跨层级的数据依赖。本章从支付页面的典型组件出发，明确状态与事件分离的原则，并通过代码示例和对比表格界定各组件的边界。

2.1 支付页面的典型组件层次

一个标准的支付流程页面通常由以下UI组件构成（从外层到内层）：

• PaymentScreen：页面级容器，持有顶层状态，分发事件。
• AmountSection：展示支付金额、货币符号。
• PaymentMethodSelector：选择支付方式（信用卡、支付宝、微信等）。
• CardForm：信用卡号、有效期、CVV输入区域（仅在信用卡方式下显示）。
• PayButton：支付按钮，触发支付请求，显示加载/成功/失败状态。
• StatusBanner：支付结果提示横幅（加载中、成功、错误）。

每个组件只负责自己的一小块UI渲染，不持有全局业务数据。

2.2 状态与事件分离：概念与对比

“状态与事件分离”有两个层面含义：

1. 状态是快照：UI从State对象读取当前数据，不负责计算或校验。
2. 事件是动作意图：用户触摸、系统回调等触发事件（Event），事件携带所需参数，由内部处理函数执行副作用。

分离之后，组件变为纯展示组件（Composable），便于单元测试和重用。

2.3 组件职责边界：具体分配表

2.4 代码实现：组件拆分的Compose示例

以下展示PaymentMethodSelector组件的典型写法：

@Composable
fun PaymentMethodSelector(
    methods: List<PaymentMethod>,
    selectedId: String,
    onMethodSelected: (String) -> Unit
) {
    Column(modifier = Modifier.fillMaxWidth()) {
        methods.forEach { method ->
            Row(
                modifier = Modifier
                    .clickable { onMethodSelected(method.id) }
                    .padding(12.dp),
                verticalAlignment = Alignment.CenterVertically
            ) {
                RadioButton(
                    selected = (method.id == selectedId),
                    onClick = null // 点击事件由Row处理
                )
                Text(text = method.displayName, modifier = Modifier.padding(start = 8.dp))
            }
        }
    }
}

注意：onMethodSelected只是一个事件回调，组件内部不保存任何选择状态。

2.5 状态与事件分离的流程（SVG框架图）

2.6 调试与常见错误

• 错误：组件内部使用mutableStateOf保存支付方式选择 → 违反状态提升，导致事件无法触发后续业务逻辑（如切换卡表）。
• 错误：CardForm直接调用网络验证API → 职责越界，应只做本地格式校验，网络验证由ViewModel完成。
• 调试技巧：在ViewModel中打印事件日志，确认事件是否完整冒泡：

  onPaymentMethodChanged: methodId=credit_card
  onPayClicked: amount=99.00, method=credit_card

2.7 组件拆分清单（部署/整合检查点）