企业官网建设流程全解析

说实话，HarmonyOS 应用开发做到第六篇，前面把布局、状态管理、列表和滚动都摸过之后，真正碰到的第一道“有点麻烦”的坎，就是表单。TextInput、Toggle、Slider、Picker这四个组件，单看哪个都不复杂，可一旦组合成一个完整的录入页面，牵涉到状态同步、校验时机、键盘避让、用户误触——问题就开始冒头了。

这篇文章想解决的，就是这个“单组件简单，综合起来乱”的痛点。我不打算给你一份复制粘贴的API文档，而是以“做一个能用的用户资料录入页”为线索，把这四个表单控件从属性、事件到踩坑点，一条条捋清楚。适合刚把ArkUI基础过完、准备开始写真实业务页面的开发者，也适合那些已经写了几个页面但总被表单细节绊一下的朋友。

1. 表单页到底难在哪：组件选型背后的思路

1.1 为什么表单要单独拆出来讲

很多同学学ArkUI组件时，习惯照着官方文档敲一遍demo，然后觉得“不就这几个组件嘛”，结果一到真实项目里就傻眼。原因很简单：文档里的demo都是孤立的，一个页面只有一个TextInput，旁边没有别的干扰因素。但真实表单页是“组件集群作战”——多个输入框、开关、滑块、选择器同时在一个页面里，各自持有状态，还要响应校验、回显、重置，这就不单单是组件API的问题了。

以我这几年做客户端的体会，表单页是数据校验逻辑最密集的区域。列表页、详情页最多就是“拉数据—渲染”，表单页却要处理“用户输入—即时反馈—提交前最终校验”这个闭环。任何一环做得不顺手，用户就能感觉到页面“很涩”。所以在动手写代码之前，第一件事不是打开IDE新建文件，而是想清楚这几个组件各自该承担什么职责。

我通常会把表单组件按“输入型”和“选择型”做分类。TextInput是典型的输入型，它接受用户自由键入，你控制的是“允许什么、限制多长、怎么校验”；Toggle、Slider、Picker属于选择型，它们不依赖键盘，核心价值是“用更少的点击成本，把用户的意图表达出来”。分类清楚之后，状态的归属也就顺理成章——输入型的值偏向字符串或自定义格式，选择型的值偏向布尔、数值、枚举。这样在写ViewModel时，脑子里的数据结构会清晰很多。

1.2 四个组件在页面里的分工边界

拿一个常见的“个人资料编辑页”举例：姓名用TextInput，是不是接收消息推送用Toggle，亮度或者音量偏好用Slider，出生日期用Picker。这里头有个很容易踩的误区：很多人习惯把Slider当成TextInput的替代品来用，比如让用户用滑块填一个数字范围，这就很反直觉。Slider更适合表达“连续程度”而不是“精确取值”，真正需要精确数字的场景，或者数值范围跨度太大（比如1到10000）时，Slider的步进操作成本会高得离谱。

我的选型经验是：

组件选型速查表

这张表不能死记，要当成一种思维习惯。后面实际写代码之前，先把每个字段的交互形态在脑子里过一遍，选型对了，代码写起来才顺。接下来四个部分，我们一个一个组件地拆。

2. TextInput：表单的“门面担当”

2.1 先从最常用的属性和状态绑定聊起

TextInput可能是开发者第一个接触的表单组件，也是表单页里出现频次最高的组件。ArkUI里TextInput最基本的构造方式有两种：直接传placeholder，或者在构造参数里同时塞初始值。

@Entry @Component struct UserFormPage { @State userName: string = '' @State userDesc: string = '' build() { Column({ space: 12 }) { TextInput({ placeholder: '请输入姓名', text: this.userName }) .onChange((value: string) => { this.userName = value }) TextInput({ placeholder: '请输入个人简介', text: this.userDesc }) .onChange((value: string) => { this.userDesc = value }) } .padding(16) .width('100%') } }

注意这里的text参数，很多人刚开始写的时候会漏掉它，结果发现输入的内容在页面刷新之后就丢了。因为TextInput内部虽然有输入框自己的“草稿状态”，但这个状态仅限组件内部，一旦它所在的自定义组件发生了状态刷新，而没有通过@State保存值，那用户输入的东西就会消失。所以我的习惯是：但凡用了TextInput，一定同步配一个@State变量和一个onChange回调，把它们绑起来。

不过这里也有个细节要留意：onChange回调的触发时机是指输入内容变化的每一刻，不是失焦时。也就是说，用户每敲一个字符，这个回调都会执行。如果你的页面规模较大，或者后续要在回调里做复杂的校验逻辑，就需要注意性能问题。简单场景下直接赋值没问题，复杂场景里可以适当做一些防抖处理，这个我们放到后面问题排查部分细说。

2.2 输入类型与键盘联动：别让用户按错键盘

TextInput想做好，第一条就是要让弹出的键盘和输入内容匹配。ArkUI通过keyboardType参数控制键盘类型。常见的几种：

TextInput({ placeholder: '请输入手机号' }) .keyboardType(KeyboardType.Number) .maxLength(11)

这里强调一下：keyboardType(KeyboardType.Number)只是把你的键盘换成数字键盘，它并不限制用户输入的内容类型。如果用户从其它地方粘贴进来一段带字母的文本，你照样会收到。所以真正做输入类型校验，还是要靠onChange时自己过滤，或者用inputFilter属性。inputFilter是一个比较好用的东西，可以直接用正则限制输入。比如我只允许输入数字和字母：

TextInput({ placeholder: '请输入编号' }) .inputFilter('[a-zA-Z0-9]', (err) => { // 当输入不匹配时触发的回调 console.info('filter err: ' + JSON.stringify(err)) })

inputFilter配合正则，能很大程度上减少脏数据的入库。我有一次做的活动报名页，用户在优惠码输入框里贴了一整段带换行的文字，因为没加过滤，后面后端接口直接报了参数格式错误。后来开发的时候养成了习惯：所有输入的字段，能枚举类型的尽量枚举，不能枚举的起码也要用inputFilter限制一下字符集合。这是成本最低的防脏数据手段之一。

2.3 常见样式调整和状态反馈

TextInput的样式调优，我一般关注三处：背景、圆角、边框色。

TextInput({ placeholder: '请输入姓名' }) .height(48) .backgroundColor('#F5F5F5') .borderRadius(8) .fontSize(16) .placeholderColor('#999999') .padding({ left: 16 })

这里有个小细节：当你用了backgroundColor之后，TextInput默认的下划线样式就不明显了，所以要么你自定义一个border，要么就别用默认的下划线风格。比如我想要一个圆角白底带边框的输入框，可以这么写：

TextInput({ placeholder: '请输入邮箱' }) .height(48) .border({ width: 1, color: '#E5E5E5' }) .borderRadius(10) .backgroundColor(Color.White) .padding({ left: 12 })

还有disabled状态。在表单未通过校验、或者表单整体处于只读模式时，把输入框置灰很重要，用户一看就知道当前不能编辑。ArkUI里给TextInput加disabled条件后就无法聚焦和输入，但要注意：disabled的样式变化可能需要你手动调透明度或背景色，否则看起来变化不够明显。

2.4 小结一个TextInput自查清单

我每次写完一个TextInput，都会快速过一遍这几项：

• 是否有placeholder提示，文案用户能不能看懂
• 键盘类型是否匹配，数字、邮箱、URL分清楚
• 是否限制最大长度，放置无限制输入拖垮布局
• 是否使用inputFilter限制非法字符
• 值是否同步到@State变量，防止刷新丢数据
• 是否设置圆角、边框、背景，保证视觉风格统一

能过完这一遍，这个输入框基本就不会在项目联调时返工了。

3. Toggle：开关虽小，状态表达要准确

3.1 Toggle的三种形态和适用场景

Toggle在表单里的角色很单纯：一个二选一的开关。ArkUI里Toggle有Switch、Checkbox、Button三种形态。实际开发中最常用的是ToggleType.Switch，就是那个长条形的滑动开关。但你得知道其它两种的存在，因为有些场景Checkbox确实更合适，比如你已经有一列偏好选项的清单列表，逐个列出复选框显然比放一排开关更整齐。

写法上，开关形态的Toggle是最好写的：

Toggle({ type: ToggleType.Switch, isOn: this.allowPush }) .selectedColor('#007DFF') .onChange((isOn: boolean) => { this.allowPush = isOn })

最常用的属性就三个：isOn（当前的开关状态）、selectedColor（开启时的颜色）、onChange（状态变化的回调）。isOn参数必然要和@State变量绑定，否则你在onChange里改了值，下次刷新还是旧值，用户就会发现开关怎么拨都拨不动——这是很典型的“状态丢失”问题。

3.2 Checkbox形态：慎用但会用就是加分项

Checkbox形态的写法也不复杂：

Toggle({ type: ToggleType.Checkbox, isOn: this.agreement }) .selectedColor('#007DFF') .onChange((isOn: boolean) => { this.agreement = isOn })

Checkbox和Switch的核心区别在交互语义。Switch是“即时生效”，拨过去状态马上变了，适合通知开关、亮色模式这种不需要二次确认的设置项。Checkbox经常和一组选项一起出现，表示“多选”，适合在表单里做偏好选择。如果你只是要一个“是否同意用户协议”的勾选框，直接用Toggle的Checkbox形态就好，不用额外引入单独的组件。

3.3 Toggle的注意事项：默认值要谨慎设置

Toggle有个容易被忽略的点：创建时的isOn默认值，应该和业务状态的初始值保持一致。比如新建用户时，默认不接收推送，那isOn就应该初始为false；但编辑用户时，要根据用户之前保存的偏好设置去初始化isOn。也就是说，isOn的初始值要从数据模型中来，而不是硬编码true或者false。

我踩过一次坑：一个设置页的开关初始isOn写的true，但用户数据里其实是false，结果一进页面，开关显示是打开的，用户点了取消之后又变成关的，数据看似没变，但体验上非常诡异。所以后来我拿到需求后就养成了习惯，任何开关的初始状态都从数据源读取，绝不在代码里写死。

3.4 如何让Toggle和文字联动更顺手

表单里开关很少单独存在，它一般会配一行标题文字，格式大致是“文字说明居左，开关靠右”。最简单的做法是放在Row里控制justifyContent：

Row() { Text('接收消息推送') .fontSize(16) Blank() Toggle({ type: ToggleType.Switch, isOn: this.allowPush }) .onChange((isOn: boolean) => { this.allowPush = isOn }) } .width('100%') .height(48)

这里Blank()起了关键作用，它会自动撑开左右元素的间距，比手动设置margin更适合各种屏幕宽度。这个小技巧在表单行布局里非常常用，建议养成习惯。

4. Slider：手感靠的是参数微调，不只是拖动

4.1 基础参数：min、max、step、value

Slider在表单里的典型用途是调节数值型偏好，比如音量、进度、亮度、评分。初始接触时只需记清楚四个参数：min最小值、max最大值、step步长、value当前值。

Slider({ value: this.soundVolume, min: 0, max: 100, step: 5 }) .onChange((value: number) => { this.soundVolume = value })

同一套代码，把step改小，滑块手感就会“细腻”很多；step改大，用户在拖动时会感觉到明显的段落感。step这个参数的取舍，取决于业务对数值精确度的要求：表达百分比时step设为1就好；表达等级时step可能需要一个间隔，比如1、2、3、4、5，那就把min设为1，max设为5，step设为1。

4.2 两种事件回调：change和click要分清

Slider的onChange在拖动过程中会持续回调，哪怕你只拖了一点点，中间每一个小步长值都会触发一次。通常这不是问题，但如果Slider背后联动一个发请求的逻辑，就可能把服务端打爆。比如让用户调节亮度并实时保存到云端，每拖一格就发一次请求，这种做法显然不合理。

解决思路就两条：要么在onChange里只更新UI状态，真正保存放到结束动作里触发；要么自己加防抖。但Slider本身没有“结束拖动”这种单独的事件，所以我的做法通常是：onChange里更新本地状态，页面里放一个“保存设置”按钮，让用户确认后再提交。这是最稳的交互设计，又不会把请求打得很碎。

4.3 定制滑块外观：哪些参数值得改

默认滑块其实够用，但有些设计稿对滑块的高度、轨道颜色有要求。常见定制参数：

Slider({ value: this.brightnessValue, min: 1, max: 100, step: 1 }) .trackThickness(6) .trackColor('#EDEDED') .selectedColor('#007DFF') .blockColor(Color.White) .blockSize(20)

这里trackColor是已滑过的轨道颜色，selectedColor是滑块右侧未滑过的轨道颜色。换句话说，这两个颜色组合就是你看到的滑轨的整体配色。在浅色背景下建议把轨道设成浅灰，已滑过区域用主题色，会让视觉重心更集中。

4.4 场景实例：做一个音量调节小模块

我经常拿“音量调节”这个需求练手。一个完整的音量滑块需要展示当前值，并且支持用户拖到某个位置就松手生效附近预览。逻辑上可以这样：

@State volumeLevel: number = 40 build() { Row() { Text('音量调节').fontSize(16) Blank() Text(`${this.volumeLevel}%`).fontSize(16).fontColor('#666666') } .width('100%') Slider({ value: this.volumeLevel, min: 0, max: 100, step: 5 }) .onChange((value: number) => { this.volumeLevel = value }) }

实测下来，这样写的好处是：百分比文本始终和滑块保持同步，用户拖动时能看到实时反馈，但存储时又不必立刻提交，整体逻辑清爽。如果你还想让百分比在拖动过程中更醒目，可以把文字换成动态放大或变色，不过那是后话，初版先保证数据和UI同步就好。

5. Picker：最容易低估的选择器家族

5.1 先认识Picker的四种形态

很多新手以为Picker就是一个“点一下弹个列表”的组件，实际上ArkUI里的Picker是按选择对象区分形态的：TextPicker负责从文本数组里选一个、DatePicker选日期、TimePicker选时间，还有一个用于选区域的RegionPicker。前三个在表单里最常用。

TextPicker比较自由，它的range参数直接接收一个数组，可以是字符串数组，也可以是Resource类型的数组。下面是一个简单的城市选择：

const cityList: string[] = ['北京', '上海', '广州', '深圳'] @State selectedCityIndex: number = 0 TextPicker({ range: cityList, selected: this.selectedCityIndex }) .onChange((index: number) => { this.selectedCityIndex = index })

TextPicker的onChange回调返回的是下标，不是字符串本体。所以如果你需要城市名做提交，得自己维护一个数组，并用下标去取对应值。这是新手最容易犯错的地方，每次都要靠cityList[this.selectedCityIndex]才能拿到真正的城市名。

5.2 DatePicker和TimePicker：别把格式搞混

日期选择器接收的selected参数是Date对象：

DatePicker({ selected: this.selectedDate, start: new Date('1990-1-1'), end: new Date(new Date().getFullYear(), 11, 31) }) .onChange((value: Date) => { this.selectedDate = value })

这里有几个容易踩坑的点。第一，selected必须传Date对象，不能传字符串。我经常看到有人试图把“2000-01-01”直接塞进去，编译不报错但运行结果完全不是预期。第二，start和end建议都设置，否则组件会用默认范围——默认起点在很早以前，终点也很远，用户翻起年份来非常痛苦。第三，setState更新DatePicker时要用新的Date对象，不要在原对象上修改，ArkUI的状态侦测相对严格，修改原对象可能不会触发视图更新。

TimePicker相对简单一点，它可选择“时分”或者“时分秒”，这个需求取决于项目。具体写法：

TimePicker({ selected: this.selectedTime }) .use12Hours(false) .onChange((value: Time) => { this.selectedTime = value })

use12Hours(false)表示24小时制，如果你在面向海外用户且需要对方习惯12小时制，就传true。这个参数也容易漏，漏掉的后果是时间选择器直接显示12小时制，但是你的业务数据可能是24小时制的，两边对不上。

5.3 Picker的展示形态：默认是内嵌组件，不是弹窗

我需要强调一个容易产生的误解：Picker默认不是“弹窗”，而是直接嵌在页面里的一个滚动选择区域。它占用的高度比较大，通常不适合直接放在一个小表单单元格里。

如果你希望“点击一个框，然后弹出选择器”，需要自己配合bindSheet或者自定义弹窗来实现。在HarmonyOS的ArkUI里，你可以用bindSheet把一个自定义Panel绑到某个Button或Text上，点击后从底部弹出面板，面板里放Picker。这是目前比较主流的交互方案，也是我推荐的做法。

@State showDatePicker: boolean = false Button('选择出生日期') .onClick(() => { this.showDatePicker = true }) .bindSheet(this.showDatePicker, this.datePickerSheet()) @Builder datePickerSheet() { Column() { DatePicker({ selected: this.selectedDate }) Button('确定') .onClick(() => { this.showDatePicker = false }) } }

这样做的目的很明确：页面默认展示的是一个简洁的字段行，用户点击后再展开选择器，选择完成关闭面板，最终只在字段行里显示格式化后的结果。这个模式在真实的业务页面里非常常见，建议直接照抄这个结构去改。

5.4 日期格式化：提交前必须处理

DatePicker给的是Date对象，但很多后端接口要的是“yyyy-MM-dd”字符串，所以选完日期之后，一定要做一次格式化。我一般会封装一个小函数：

formatDate(date: Date): string { const year = date.getFullYear() const month = (date.getMonth() + 1).toString().padStart(2, '0') const day = date.getDate().toString().padStart(2, '0') return `${year}-${month}-${day}` }

这个函数逻辑不复杂，但非常重要。因为如果你直接把Date对象JSON序列化后传给后端，会出现时区问题，也可能出现格式完全不对的情况。在表单提交链路里，前端把好格式关，后端接口对接就会顺畅很多。

6. 组合实战：完成一个“用户资料编辑”表单页

6.1 场景设定与状态设计

光拆开讲组件容易让人觉得零散。现在我们把TextInput、Toggle、Slider、Picker组合到一个真实的表单页里。需求就按最常见的“编辑个人资料页”来：

• 姓名：TextInput，必填，最长10个字符
• 城市：TextPicker，从预设城市列表中选一个
• 出生日期：DatePicker，从底部面板弹出选择
• 推送通知：Toggle，默认关
• 曝光强度：Slider，范围0到10，默认4

按前面几节的思路，我们先定义状态：

@Entry @Component struct UserProfileForm { @State nameValue: string = '' @State cityIndex: number = 0 @State birthDate: Date = new Date('2000-01-01') @State birthShow: boolean = false @State pushEnable: boolean = false @State exposureLevel: number = 4 @State submitResult: string = '' }

这里所有状态都用@State装饰器管理，UI驱动全部走数据绑定。页面里用Column排列字段，每个字段占用一个自定义构建函数，页面的整体结构会清爽很多。

6.2 页面布局代码参考

build() { Column({ space: 0 }) { // 姓名输入 Row() { Text('姓名').fontSize(16).width(80) TextInput({ placeholder: '请输入姓名', text: this.nameValue }) .maxLength(10) .onChange((value: string) => { this.nameValue = value }) } .height(56) // 城市选择 Row() { Text('城市').fontSize(16).width(80) TextPicker({ range: cityList, selected: this.cityIndex }) .onChange((index: number) => { this.cityIndex = index }) } .height(120) // 出生日期 Row() { Text('出生日期').fontSize(16).width(80) Button(this.formatDate(this.birthDate)) .backgroundColor(Color.Transparent) .fontColor('#333333') .onClick(() => { this.birthShow = true }) .bindSheet(this.birthShow, this.dateSheetBuilder()) } .height(56) // 推送开关 Row() { Text('接收推送通知').fontSize(16) Blank() Toggle({ type: ToggleType.Switch, isOn: this.pushEnable }) .selectedColor('#007DFF') .onChange((isOn: boolean) => { this.pushEnable = isOn }) } .height(56) // 曝光强度 Row() { Column({ space: 8 }) { Row() { Text('曝光强度').fontSize(16) Blank() Text(`${this.exposureLevel}`).fontSize(16).fontColor('#666666') } .width('100%') Slider({ value: this.exposureLevel, min: 0, max: 10, step: 1 }) .trackThickness(6) .selectedColor('#007DFF') .onChange((value: number) => { this.exposureLevel = value }) } .width('100%') } .padding({ top: 8, bottom: 8 }) // 提交 Button('提交') .width('100%') .height(44) .margin({ top: 24 }) .onClick(() => { this.handleSubmit() }) Text(this.submitResult) .margin({ top: 12 }) .fontSize(14) .fontColor('#666666') } .padding(16) .width('100%') .height('100%') .backgroundColor('#FFFFFF') }

这段代码已经把前面所有组件的用法串起来了，是标准的“字段行 + 右侧控件”表单布局。有一点要注意：TextFieldPicker在这里占的高度比较多，如果希望它更紧凑，可以把它也改成文本展示 + 底部弹出的样式，这个思路和DatePicker的处理方式一样。

6.3 日期面板Builder和校验逻辑

日期面板在bindSheet里展开，它的Builder写法如下：

@Builder dateSheetBuilder() { Column({ space: 16 }) { DatePicker({ selected: this.birthDate }) Button('确定') .width('100%') .onClick(() => { this.birthShow = false }) } .padding(16) }

提交时的校验逻辑，我一般会先做“必填和非空”，再做“格式和业务规则”。一个简化的示例：

handleSubmit() { if (this.nameValue.trim().length === 0) { this.submitResult = '姓名不能为空' return } const selectedCity = cityList[this.cityIndex] const expLevel = this.exposureLevel // 这里其实可以把所有字段拼一个对象，发给服务端 this.submitResult = `提交成功：${this.nameValue} / ${selectedCity} / ${this.formatDate(this.birthDate)} / ${expLevel}` }

现实中提交数据的逻辑大概率比你想象的复杂，但表单层做校验的思路是一致的：先用最简单的防御性判断挡住空数据，再交给后端做最终校验，不要在前端堆太多复杂校验规则，不然维护起来很痛苦。

6.4 写到这里的体会

每次把这个页面的代码完整跑起来，都会发现“状态同步”这四个字有多重要。四个组件的值全部收拢到@State变量里，页面上任何一处UI变化，最终都反映到数据层；反过来数据层被另外一个页面更新后，UI也能跟着刷新。这种单向数据流的设计，是ArkUI表单交互的底层逻辑。搞懂它，比背一百个API还有用。

7. 表单踩坑实录：常见问题与排查技巧

7.1 输入框一刷新就丢内容

这是最经典的问题。现象是：输入到一半，页面里其它状态的更新导致build重新执行，TextInput里的内容没了。

排查思路第一步，永远先看TextInput有没有绑定text和onChange。如果没有绑定@State变量，那么TextInput的内容完全由组件内部临时状态维护，而内部状态在自定义组件刷新时可能被重置。解决方式就是像第二节写的那样，把输入框的text和onChange和@State变量绑死。绑了之后如果还是丢，那就检查是不是在onChange里做了异步操作，导致赋值被覆盖了。

7.2 键盘把提交按钮顶得看不见

表单页一旦有TextInput，键盘避让的问题就躲不掉。在HarmonyOS的ArkUI里，默认情况下键盘弹出会遮挡底部区域。一般我会通过页面的safeArea调整或者滚动容器配合。比较轻量的方案是把整个表单包在Scroll里，并设置键盘避让相关属性，让Scroll能够在键盘弹出后滚动到底部。

另外一个有助于规避该问题的做法：建议把“提交”按钮不放在键盘弹出区域的底部，而是放在页面底部固定不动，或者在键盘弹出时临时调整位置。这个和对端适配有关系，不同版本的行为略有差异，但总的原则是保证用户在键盘打开的情况下，依然能看到正在输入的框以及必要的操作按钮。

7.3 Slider疯狂回调把接口打爆

正文4.2里已经提过，这里再从排查角度说一遍。如果你发现某个接口在用户拖动滑块时请求不停，不要修改Slider本身，问题大概率出在业务提交策略上。最快的改法是把请求触发从Slider的onChange里移走，换成“松手后”或者“点击保存按钮”时再发请求。这是成本最低的修复手段。

我见过有同学尝试在onChange里做时间戳防抖，效果也行，但会让代码复杂不少。除非需求明确要求“拖动即保存”，否则我还是推荐用“显式保存”这种更明确的交互模型。

7.4 DatePicker选了之后页面不刷新

这也是很普遍的情况。原因是DatePicker的onChange返回的Date对象，未必是新的对象引用。你在处理时直接做this.birthDate = value一般是有效的。但如果页面里其它地方改了同一个Date对象的属性，或者你用了固定的默认值，@State侦测不到，那页面就刷新不了。最稳妥的方式是每次选择后都重新new一个Date：

.onChange((value: Date) => { this.birthDate = new Date(value.getTime()) })

这个小动作能避开很多状态更新的坑，建议当成标准写法。

7.5 Picker放在表单里占位太高

如5.3所说，TextPicker和DatePicker默认嵌入页面后高度不小。如果你觉得页面显得很空，把选择器改成“点击字段行 → 底sheet弹出”的交互就能解决。具体方式就是bindSheet里放Picker，外面用Button或者Text展示当前选中的值，点击后展开面板。这也是我强烈推荐大家参考的设计模式，既能保持页面简洁，又能保证选择器的可用性。

7.6 常见问题速查表

7.7 最后说点心里话

表单交互看起来是“照着文档撸一遍就行”的事，真正做起来才知道水有多深。组件本身的API就是那些，真正的差距在于：你有没有把每一个字段的交互形态想清楚，有没有把状态管理的闭环梳理通，有没有处理用户操作中的边界情况。这几点做到了，哪怕你刚上手ArkUI，写出来的表单页也会比很多号称“做了多年”的开发更稳。

我每写一批表单页，都会拿上面的自查清单过一遍。五个组件、十几个属性、三四个回调，组合起来能做的东西远超你想象。希望这篇内容能帮你把表单交互这块基础打扎实，以后碰到再花哨的需求，也能一眼看穿它背后的组件和交互模型。