📚 课程目录第1章支付页面简介与需求分析

支付页面简介与需求分析

各位好，今天我们开始聊支付页面。我做了这么多年UI，坦白讲，支付页面是那种“看起来简单，做起来全是坑”的场景。你想想看，用户掏钱的动作就那么几步，但每一步都藏着大量细节。

这一章我们先把地基打牢。搞清楚支付页面的功能需求、用户流程，以及为什么我坚持选择Jetpack Compose来构建它。

说白了，一个支付页面要解决的核心问题就是：让用户安全、顺畅地完成付款。听起来简单，但落实到功能上，至少得涵盖下面这些点：

我习惯把支付流程拆成几个大块。你想想看，用户的操作路径其实很固定：

关键点：整个流程中，状态管理是最容易出问题的。我曾经在项目中因为没处理好“支付中”状态，用户连续点两下支付按钮，结果扣了两次款。切记，支付按钮的点击事件必须做防重复处理。

可能有朋友会问，用传统的XML布局不也能做吗？为什么非要用Compose？我个人的理由有这么几个：

声明式UI天然适合状态管理：支付页面的状态变化特别频繁——加载中、成功、失败、表单校验、输入格式化。Compose的State-Driven模型可以让我少写大量模板代码。
动画支持更优雅：支付成功后的打勾动画、支付中的loading动画，在Compose里实现起来非常流畅。
组件化思路更清晰：每个输入框、每个按钮都可以拆成独立的Composable，配合状态提升，逻辑非常干净。
和Kotlin协程无缝配合：支付SDK的异步调用，用LaunchedEffect和rememberCoroutineScope处理起来极其顺手。

小提示：如果你的项目已经用了Compose，那支付页面是你实践状态提升的最佳场景。如果没有，嗯，这一章之后你可能就会想迁移了。

这里我必须重点提一下状态提升（State Hoisting）。我个人认为这是Compose里最重要的设计模式，没有之一。

简单说，就是把Composable内部的状态“提升”到上一级去管理。这样做的好处很明显：

拿支付页面举例：支付方式的选择状态、金额的展示状态、表单的校验状态，这些都不应该分散在各个组件里。我习惯把它们全部提升到ViewModel中，然后通过StateFlow暴露给UI层。

注意：千万别把所有状态都塞到一个ViewModel里。我见过有的项目把卡号、有效期、CVV、支付方式、订单金额全都放在一个data class里，结果改一个字段要刷新整个页面。合理的拆分才是关键，这个我们后面章节会细讲。

为了让你更直观地理解支付页面的整体结构和状态提升的关系，我画了一张流程图。这张图也是我们整个课程的核心脉络：

说到这里，我想强调一件事： 很多新手工程师容易把状态提升理解成“把所有状态都扔到ViewModel里”。其实不是的。真正好的做法是，每个Composable只保留最必要的内部状态（比如输入框的焦点状态），其余的都从外部传入。这样你的组件才是真正可复用的。

好了，这一章我们就先聊这么多。记住三个关键点：