Flutter for OpenHarmony发起组队表单实现与校验方案-代码聚汇网

Flutter for OpenHarmony发起组队表单实现与校验方案

写小说的闲鱼牧云·2026-09-04·阅读 21 GEO检测（免费）

FlutterOpenHarmony表单实现

|难度：普通|阅读约 50 分钟

做剧本杀组队App的人都知道，列表页只是把用户拉进门，真正的撮合动作发生在“发起组队”那一屏。这里一旦出现输入项残缺、时间选不了、人数填了却提示格式错之类的问题，用户在冷启动阶段会直接流失。特别是当我在这套方案里用了Flutter for OpenHarmony这套组合后，更发现表单这类交互密集的场景，不能照着Android或iOS的惯性去写，必须单独梳理一套设计逻辑。

这篇是这个系列实战的第四篇，聚焦“发起组队表单实现”。我会把字段设计、校验规则、三个选择器的兼容处理、提交前的数据组装和草稿保存逐个讲清楚。如果你也在做OpenHarmony设备上的Flutter应用，或者正在做剧本杀、桌游、密室类组队工具，这篇可以直接当成落地清单来参考。

1. 项目背景与需求拆解

1.1 剧本杀组队场景里的表单，到底在收集什么

回到真实使用场景去理解这个页面：一个玩家想开一车剧本杀，通常心里已经有一个大概的本子，缺的无非是“什么时候开、在哪开、还差几个人、剧情氛围有什么要求”。所以发起组队这张表单，并不是普通App里的注册信息收集，它本质上是在生成一个“组队公告卡片”。

基于这个定位，我拆解出的核心字段有这几类。

车型与剧本信息：剧本名称、剧本类型（欢乐、硬核、情感、机制阵营、恐怖还原）、是否整车。
时间与地点信息：开本时间、城市/店铺/线上语音房间。
人员与条件信息：需要人数、性别比例要求、对队友的期望描述。
联系方式与备注：发起人的微信号或手机号、自定义补充说明。

真正写进模型的时候，不需要一上来就定义十几个字符串。先把用户要填的内容分类成输入型、选择型、时间型、开关型，后续UI布局和校验逻辑会清晰很多。

另外要提前想清楚：发起人自己的头像昵称一般由登录态提供，不需要让用户重复填写。下面所有登录信息可以从上一级页面传入，表单只承载“这一车怎么组”的动态数据。这一点看似废话，但我在初版设计时把玩家昵称也放在了表单里，结果提交时好几次和登录信息对不上，属于典型的没有做职责分离。

1.2 为什么是Flutter for OpenHarmony，而不是ArkUI

有人可能会问，既然跑在OpenHarmony设备上，为什么不用ArkUI加ArkTS去写，非要绕一层Flutter？这里要交代清楚背景：我们这个横跨多端的项目，底座原本就是Flutter，服务端接口、状态管理和页面组件都复用在Android、iOS等平台。OpenHarmony只是新增的目标平台之一，不是唯一平台，所以我优先考虑的是Flutter for OpenHarmony的适配方案，而不是为OpenHarmony单独维护一套代码。

Flutter for OpenHarmony本质上是一个OpenHarmony适配的Flutter SDK，它会生成带有OpenHarmony平台目录的工程，开发时仍然写Dart，但编译产物能跑在OpenHarmony设备上。这对团队意义很大：表单页的80%代码可以直接复用，所有用Dart写的校验工具类也能平滑迁移，不需要再用ArkTS重新实现一遍。当然代价也存在，例如OpenHarmony的SDK不能直接使用所有pub.dev上的插件，很多纯Dart包没问题，但依赖原生通道的插件需要确认是否支持OpenHarmony。

选择这套方案时，我给自己定的原则是：UI层可以适当地为OpenHarmony做定制，但业务逻辑层必须尽量保持平台无关。所以在表单实现中，我不会引入和OpenHarmony强绑定的原生控件，所有选择器优先用Flutter自绘或者跨端兼容度高的组件，实在不行才考虑平台分支处理。

1.3 从页面框架到表单提交的设计层级

整个发起组队功能会拆成三层去看，和Flutter的组件层级一一对应。

页面层：_GroupFormPage，负责接收上一页传过来的用户信息，管理一堆Controller和FocusNode。
数据层：GroupTeamModel，把页面上分散的字段集中为一个模型对象，方便提交时转JSON。
交互层：表单校验与按钮状态，通过FormState.validate()判断是否可以提交。

这个分层的好处是后续加“保存草稿”或“编辑再发布”，不需要重构页面组件，只要把数据层抽象出序列化和反序列化方法即可。表单页里最容易犯的错误就是所有字段在build方法里直接裸用TextFormField，一旦字段数量超过8个，保存、回显、重置会变成一场灾难。

因此强烈建议先把模型类写好，再做页面UI。文章下面会先给出数据模型，再进入页面细节，这个顺序和我在实际编码时的顺序一致。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 表单数据模型与校验规则设计

2.1 数据模型字段怎么定，才不会被后续需求打脸

先看我最后沉淀的GroupTeamModel。这个模型没有把所有属性都设置成String，而是把时间、人数单独拆成类型，避免后续提交接口时还要到处parse。

dart复制enum ScriptType {
  happy,      // 欢乐
  hardcore,   // 硬核
  emotion,    // 情感
  mechanism,  // 机制阵营
  horror,     // 恐怖还原
  other,      // 其他
}

class GroupTeamModel {
  final String scriptName;
  final ScriptType scriptType;
  final DateTime startTime;
  final String address;
  final int needPlayers;
  final bool isWholeCar;
  final String contact;
  final String remark;

  const GroupTeamModel({
    required this.scriptName,
    required this.scriptType,
    required this.startTime,
    required this.address,
    required this.needPlayers,
    required this.isWholeCar,
    required this.contact,
    required this.remark,
  });
}

关于人数，我在初版用了String类型，后来发现回显和上报都很麻烦，因为下拉选择器选完后拿到的是字符串，必须再int.parse一次，中途还容易FormatException。更合理的方式是在表单页维护一个String _needPlayersText用于输入框显示，真正提交时再转成int。这种“输入态”和“业务态”分离的思路，后面写校验逻辑时也会用到。

剧本类型我用了枚举而不是硬编码汉字，好处是整个App后续有用例列表、筛选页时可以直接复用。如果设计成只存字符串，列表筛选时还得再做词典映射，枚举加label扩展方法会是更好的方案。

2.2 前端校验规则的分层策略

表单校验不能只依赖Flutter自带的validator，一套完整规则需要横跨三层。

第一层是格式化约束，比如手机号或微信号的正则、备注最大长度；第二层是业务逻辑约束，比如开本时间不能是过去时间、整车模式下人数需要预留车位；第三层是服务端约束，这部分写在后端，前端主要做友好提示。在Flutter里能做的就是第一层和第二层，第三层只能通过接口错误返回去展示。

按照这个策略，我不会把所有validator写成一个大方法。项目里单独建了一个PublishValidators文件，集中管理可复用规则。下面是我用的几个核心校验。

dart复制class PublishValidators {
  static String? validateScriptName(String? value) {
    final text = value?.trim() ?? '';
    if (text.isEmpty) {
      return '请填写剧本名称';
    }
    if (text.length > 20) {
      return '剧本名称不能超过20字';
    }
    return null;
  }

  static String? validateTime(DateTime? value) {
    if (value == null) {
      return '请选择开本时间';
    }
    final now = DateTime.now();
    if (value.isBefore(now.subtract(const Duration(minutes: 5)))) {
      return '开本时间不能早于当前时间';
    }
    return null;
  }

  static String? validatePlayers(String? value) {
    final text = value?.trim() ?? '';
    if (text.isEmpty) {
      return '请输入需要人数';
    }
    final number = int.tryParse(text);
    if (number == null) {
      return '人数必须为数字';
    }
    if (number < 1 || number > 12) {
      return '人数需在1到12之间';
    }
    return null;
  }

  static String? validateContact(String? value) {
    final text = value?.trim() ?? '';
    if (text.isEmpty) {
      return '请留下联系方式';
    }
    final mobileReg = RegExp(r'^1[3-9]\d{9}$');
    final wechatReg = RegExp(r'^[a-zA-Z][a-zA-Z0-9_-]{5,19}$');
    if (mobileReg.hasMatch(text) || wechatReg.hasMatch(text)) {
      return null;
    }
    return '请输入正确的手机号或微信号';
  }
}

这里需要注意一个细节：在校验的写法上，我会保留一层“Trim再判断”的操作，因为实际用户输入很容易带前后空格。如果不做处理，用户明明填了内容，却因为一个空格被提示“必填”，很影响体验。

2.3 可复用的校验状态：不要用一堆bool散落各处

在表单交互里，除了每个字段的validator，还需要一个控制提交按钮能否点击的状态。我看到很多新手实现是每个字段变化时设置一个_hasError布尔值，结果字段多了根本管不过来。

更稳的做法是让提交按钮始终可点击，点击时统一执行_formKey.currentState?.validate()，校验通过才走下一步，不通过就利用返回的错误信息提示。这样用户在清理错误的过程中，重新点击一次提交自然就会重新校验，不会出现按钮永远置灰的尴尬，也不需要在每个TextField的onChanged里做复杂的联动逻辑。

如果确实需要做成实时更新按钮状态，可以把TextFormField的onChanged统一集中到一个回调，每次触发后执行一次轻量级检查，但轻量级检查务必要复用那些validator方法，而不是另写一套逻辑。两条校验逻辑同步维护，修起来会让你怀疑人生。

3. 发起组队表单的核心实现

3.1 页面骨架与Form容器布局

页面整体采用Scaffold加AppBar的结构，AppBar上放一个“发布”按钮，表单内容放在ListView里，最底部留出足够的安全边距。这里用ListView而不是Column，原因很简单：当键盘弹出时，输入框多的页面必须能够滚动，否则底部几个字段会被键盘完全遮住。

基础骨架代码如下。

dart复制class PublishTeamPage extends StatefulWidget {
  final String userNickname;
  const PublishTeamPage({Key? key, required this.userNickname}) : super(key: key);

  @override
  State<PublishTeamPage> createState() => _PublishTeamPageState();
}

class _PublishTeamPageState extends State<PublishTeamPage> {
  final _formKey = GlobalKey<FormState>();
  final _scriptNameController = TextEditingController();
  final _playersController = TextEditingController();
  final _contactController = TextEditingController();
  final _remarkController = TextEditingController();

  ScriptType _scriptType = ScriptType.happy;
  DateTime? _startTime;
  String _address = '';
  bool _isWholeCar = false;

  @override
  void dispose() {
    _scriptNameController.dispose();
    _playersController.dispose();
    _contactController.dispose();
    _remarkController.dispose();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: const Text('发起组队'),
        actions: [
          TextButton(
            onPressed: _submitForm,
            child: const Text('发布'),
          )
        ],
      ),
      body: Form(
        key: _formKey,
        child: ListView(
          padding: const EdgeInsets.fromLTRB(16, 8, 16, 32),
          children: [
            _buildScriptNameField(),
            _buildScriptTypeSelector(),
            _buildTimeField(),
            _buildAddressField(),
            _buildPlayersField(),
            _buildWholeCarSwitch(),
            _buildContactField(),
            _buildRemarkField(),
          ],
        ),
      ),
    );
  }
}

Controller的dispose务必要写，Flutter for OpenHarmony上虽然没有Android那么明显的内存告警，但页面频繁进出，不释放Controller会造成内存泄漏。这个问题在列表页不明显，在表单页会被放大，因为每次进入页面都new了一批Controller。

这些构建方法没有全部在build里平铺，而是拆分成了_buildXxx系列私有方法，每个方法负责一段输入区域。后面文章会挑其中几个重点说明，而不是把每个方法完整贴一遍，否则页面会显得冗余。

3.2 输入类字段：剧本名、人数、联系方式、备注

输入类字段最好处理，直接用TextFormField加上InputDecoration。这里面藏着不少实际测试出来的体验细节。

先看剧本名称字段。

dart复制Widget _buildScriptNameField() {
  return TextFormField(
    controller: _scriptNameController,
    maxLength: 20,
    decoration: const InputDecoration(
      labelText: '剧本名称',
      hintText: '比如：年轮、持斧奥夫',
    ),
    validator: PublishValidators.validateScriptName,
  );
}

maxLength用于控制字数，如果不额外处理，Flutter会在右下角显示一个“5/20”的计数。这个计数器有人觉得碍眼。你可以把decoration.counterText设为空字符串来隐藏，但不能因此放弃长度限制。因为用户从输入法粘贴一大段内容时，没有maxLength会被直接塞进去，给后面的UI渲染带来压力。

人数和联系方式字段相对特殊，需要设置keyboardType。

dart复制TextFormField(
  controller: _playersController,
  keyboardType: TextInputType.number,
  decoration: const InputDecoration(
    labelText: '需要人数',
    hintText: '比如：5',
  ),
  validator: PublishValidators.validatePlayers,
)

这里要提醒一点：TextInputType.number只是改变软键盘布局，并不能阻止用户在部分硬件键盘或输入法里输入非数字字符。所以服务端或者Form提交前必须用int.tryParse做兜底，不要以为键盘类型是number就不需要校验了。我拿OpenHarmony设备测试时，外接键盘仍然能输入字母，所以validatePlayers里int.tryParse的判断是必不可少的安全底线。

备注字段可以设置maxLines: 3，让用户有更多区域展开写，用textInputAction: TextInputAction.newline来保证回车是换行而不是“完成”。除非你希望用户输入完备注直接触发提交，否则不建议把它设成done。

3.3 下拉与选择类字段的两种实现

剧本类型和开本地点这类选项，我用了两种不同实现来解决在OpenHarmony上的一些显示问题。

剧本类型适合用DropdownButtonFormField，因为在同一屏内直接下拉选择的效率比跳转到另一页更高，而且这个组件自带Form校验集成的能力。

dart复制DropdownButtonFormField<ScriptType>(
  initialValue: _scriptType, // 注意：新版本Flutter里必须用initialValue
  decoration: const InputDecoration(labelText: '剧本类型'),
  items: ScriptType.values.map((type) {
    return DropdownMenuItem<ScriptType>(
      value: type,
      child: Text(_scriptTypeLabel(type)),
    );
  }).toList(),
  onChanged: (value) {
    setState(() {
      _scriptType = value ?? ScriptType.happy;
    });
  },
)

一个小小的坑：Flutter 3.x新版本已经弃用了value参数，改成了initialValue。如果你在Flutter for OpenHarmony上跑的是3.7以上或对应新版本，依旧用value会看到一个Deprecation警告。警告不是错误，但每次构建刷屏很烦，改成initialValue之后就清爽了。

地点字段我不用TextField，因为剧本杀组队地点可能是“某个城市的某个店铺”，也可能是“线上语音频道”，用普通文本输入反而不容易规范化。我建议使用底部弹层选择，以showModalBottomSheet来承载一份常用场地列表，用户也可以选择“手动输入”跳到输入框。好处是以后运营要维护推荐店铺时，改动成本很低，只需改场地数据源即可。

3.4 时间选择器：为OpenHarmony准备的三个兼容方案

时间字段是这个表单里最复杂的一个选择项。在Android原生Flutter里，最常规的做法是调用showDatePicker加showTimePicker，但在Flutter for OpenHarmony上需要测试组件表现。根据我在rk3566/rk3568类设备上的实测经验，MaterialDatePicker在某些版本OpenHarmony上打开时会卡在初始化阶段，至今没有找到统一结论，所以我会给三套方案，并按照优先级使用。

第一套方案，自绘日历弹层。这不是从零造轮子，而是用showModalBottomSheet加CalendarDatePicker组合，比直接调用showDatePicker更可控。因为CalendarDatePicker本质上是纯Flutter渲染的日历组件，不依赖平台原生的日期选择器，OpenHarmony上兼容度更高。选择日期后放入一个临时变量，再弹一层CupertinoTimerPicker或者简单的时间滚轮组件选择具体小时分钟。

第二套方案，直接用CupertinoDatePicker放在BottomSheet里。这个组件在Flutter for OpenHarmony上的适配比Material版本的DatePicker要好，底层绘制逻辑和平台通道关联少，适合当成一个轻量的日期时间选择器。缺点是风格偏iOS，如果App整体是Material风格，底部突然冒出一个iOS滚轮会有些跳戏，但对于工具型页面来说，用户更在意是否能选到正确时间。

第三套方案，如果以上组件在你的SDK版本里都有莫名其妙的渲染问题，就退化成两个输入框：一个填日期，一个填时间，用TextInputType.datetime加输入格式提示。这种方案不再依赖任何DatePicker，体验虽朴素但至少在所有设备上都能工作。实际开发中，我建议第一天就把三套方案都调通，然后在路由层封装一个showGroupDateTimePicker方法，里面根据平台和版本决定用哪套，后续遇到设备兼容问题只需要改这一个方法。

封装接口的示意如下。

dart复制Future<DateTime?> showGroupDateTimePicker({
  required BuildContext context,
  DateTime? initialDate,
}) {
  // 优先日历加时间滚轮，出现异常或指定场景可回退到输入模式
}

3.5 整车模式与条件提示

剧本杀组队还有一个特色字段：这车是否整车。如果是整车，意味着队伍人已经齐了，只是等着约定时间一起玩，这时候需要在展示和文案上提醒发起人“整车不需要贴招人信息，但依然需要预约房间和DM”。这个字段我用一个SwitchListTile实现，UI上比较直观。

dart复制SwitchListTile(
  title: const Text('整车预约'),
  subtitle: const Text('开启后表示已有人数基础，只约时间场地'),
  value: _isWholeCar,
  onChanged: (value) {
    setState(() {
      _isWholeCar = value;
    });
  },
)

整车模式下，期望人数可以继续填写，但它的意义变成了“本车总人数”，而不是“还需要几个人”。这一层语义差异虽小，但在后端做匹配逻辑时会涉及展示完全不同的文案，所以模型里用一个bool字段标记即可，不要在提交时才根据人数去猜。

3.6 提交按钮与整体交互逻辑

表单页的提交入口放在AppBar右上角，点击后先收起键盘，再执行校验，校验全部通过后弹确认框或直接pop返回结果。我在项目里选择用Navigator.pop返回一个组装好的GroupTeamModel，由上一级页面继续处理网络请求，这样表单页本身不关心请求是否成功，始终保持单一职责。

dart复制void _submitForm() {
  FocusScope.of(context).unfocus();
  if (!(_formKey.currentState?.validate() ?? false)) {
    return;
  }
  final model = GroupTeamModel(
    scriptName: _scriptNameController.text.trim(),
    scriptType: _scriptType,
    startTime: _startTime ?? DateTime.now(),
    address: _address,
    needPlayers: int.parse(_playersController.text.trim()),
    isWholeCar: _isWholeCar,
    contact: _contactController.text.trim(),
    remark: _remarkController.text.trim(),
  );
  Navigator.pop(context, model);
}

这里刻意把表单页和网络调用解耦。因为发起组队后通常会出现一个“正在创建房间”的loading状态，还有可能因为服务端错误需要返回用户重新编辑，如果都把逻辑塞在页面里，页面代码会快速膨胀。表单页只负责收集数据并返回模型，列表页收到模型后走ApiService，清晰且好调试。

4. 实操中的细节问题与排查记录

4.1 键盘遮挡输入框的标准解法

在OpenHarmony设备上跑Flutter，键盘遮挡问题是表单页第一个要处理的。常规方案是把Scaffold的resizeToAvoidBottomInset保持默认true，同时保证外层是一个可滚动组件。只要Form外层是ListView，键盘弹出时系统会把可视区域缩小，用户手指滑动就能滚到被遮住的字段。

还有一种更主动的交互是监听FocusNode的焦点变化，当底部字段获得焦点时，使用Scrollable.ensureVisible把当前输入框滚动到可见区域。实际测试下来，这种方法在弹窗表单中比较必要，在主页面Form表单中不是必需，因为ListView已经提供了滚动能力。为了不引入额外的复杂度，我的主页面表单没有自定义滚动监听。

4.2 校验触发时机：autovalidateMode怎么选

TextFormField的校验触发时机由AutovalidateMode控制。默认情况下是disabled，意思就是只在提交时才调用FormState.validate()。但很多用户期望的效果是：填写出错后，一旦开始修改错误，错误提示应该自动消失，而不是等下一次提交才更新。

这就涉及到autovalidateMode的选择。我的建议是全部使用AutovalidateMode.onUserInteraction，也就是用户和某个字段交互过后才触发该字段的校验。初期几版我尝试让所有字段在页面打开时就显示错误，结果用户还没开始填就看到满屏红字，体验非常暴躁。后来改成用户交互后自动校验，错误提示只在真实输入之后出现，立刻友好很多。

如果你在Flutter for OpenHarmony的某个SDK版本里发现autovalidateMode字段名变化，可以查一下SDK版本对应的API文档，通常是AutovalidateMode.disabled和autovalidateMode属性，没有本质区别。

4.3 校验失败时的滚动定位

调用_formKey.currentState?.validate()之后，Flutter会把焦点定位到第一个校验失败的字段，但页面不会自动滚动到那个字段。如果校验失败的是屏幕外很下面的字段，用户会看到错误提示但没有明显变化，还会奇怪为什么发布按钮没反应。

一个比较省事的解决思路是给每个需要滚动的表单字段包一个Key，在validate返回false时通过Scrollable.ensureVisible滚动到当前聚焦的Context。不过这个方案对Context的生命周期比较敏感，如果在builder里没法拿到Element，建议用一个更简单的方案：直接调整ListView的reverse或在外层加一个“滚动到顶部”的提示。但该方法不够通用，我的最终做法是把所有字段从顶部一直排到底部，一般最常见的问题都集中在上半部分，出现校验失败的概率被人为降下来了。

4.4 输入框主题色与字重被全局主题覆盖

Flutter for OpenHarmony上跑的App如果设置了ThemeData，常常会遇到输入框获取焦点后颜色不对的问题。具体表现为labelText的颜色和Material 3主题冲突，或者InputDecoration的enabledBorder颜色怎么设都不生效。这种问题在搜索热词里也被很多人提到，连showLicensePage的主题颜色、复选框间距这些细节都会因为全局主题默认值不一致而出错。

我的处理方法是给所有输入框统一定义一个InputDecorationTheme，并把它们放在页面级Theme或Scaffold主题中。不要在每一个TextFormField里去复制同样的focusedBorder。这里贴一段统一主题配置。

dart复制InputDecorationTheme groupFormDecorationTheme() {
  return const InputDecorationTheme(
    border: OutlineInputBorder(),
    focusedBorder: OutlineInputBorder(
      borderSide: BorderSide(color: Color(0xFF4338CA), width: 1.5),
    ),
    enabledBorder: OutlineInputBorder(
      borderSide: BorderSide(color: Color(0xFFD1D5DB)),
    ),
    errorBorder: OutlineInputBorder(
      borderSide: BorderSide(color: Color(0xFFDC2626)),
    ),
    focusedErrorBorder: OutlineInputBorder(
      borderSide: BorderSide(color: Color(0xFFDC2626), width: 1.5),
    ),
  );
}

把errorBorder和focusedErrorBorder都配置出来，是避免出现“输入框有error却仍然显示蓝色边框”的关键。你们可以自己试一下，不配置focusedErrorBorder时，有错误焦点后的边框颜色往往还是主题primary色，用户看到蓝框但下面红字，会很困惑。

4.5 OpenHarmony设备上插件不兼容的排查思路

在实现表单的过程中，我一度希望通过第三方包来做城市选择器和图片上传，结果发现很多在Android上正常工作的插件在OpenHarmony里要么无法编译，要么运行时报缺失实现。

先说排查链路：第一步检查插件是否纯Dart，如果pubspec里带有android或ios原生代码，就需要看它有没有对应的OpenHarmony实现。社区里通常会把适配过的包放在特定仓库下，需要手动添加依赖而不是直接从默认pub.dev拉取。第二步是看运行时是否报MissingPluginException，这个异常说明插件的平台通道在OpenHarmony侧没有注册。最后一步是隔离问题组件，找一个最小可复现的页面逐个测试，不要在表单大页面中排查，否则根本定位不到问题。

城市选择器这类功能，我把数据源本地化，使用纯Dart的搜索筛选，用BottomSheet实现，上传图片则优先使用标准文件选择加原生适配，不依赖小而美的第三方插件。很多时候第三方包确实方便，但多一个原生依赖，OpenHarmony上的构建成本就会多一分。能纯Dart解决的就不要动用平台通道，这是这套技术组合里最核心的取舍。

5. 表单之后：数据提交、草稿与后续扩展

5.1 上一级页面拿到模型后做什么

当表单页Navigator.pop之后，上一级页面会拿到一个GroupTeamModel。后续一般会进入一个确认预览页面，或者直接发起网络请求。我在项目里做了一个轻量的“预览卡”页面，因为用户填完表单后，如果立刻提交，看到的是列表页自己“刷”的一条记录，确认感不强。而预览页可以把填写的剧本名、人数、时间、地点渲染成一张标准卡片，既能让用户确认信息无误，也为后续列表页复用了同一套卡片组件提供了机会。

预览页确认后点击提交，才会走到ApiService.createGroupTeam(model)。这样做还有一个好处：如果服务端要求存储结构里某些字段必须从用户昵称和时间戳计算，可以在确认提交前把派生字段拼好，保持表单模型纯净。

5.2 用缓存实现一份本地草稿

表单场景里，用户可能在填了一半时退出。如果没有任何提示，下次再进入又得全部重填，体验很差。我的处理方案是在dispose时把当前所有Controller的文本值存入页面级缓存，下次进入页面时回填。

缓存不一定要引入数据库。纯本地草稿用SharedPreferences就够了，Flutter for OpenHarmony也有对应兼容实现，如果暂时没有适配版，可以先用文件写入一个JSON。所以我在项目里封装了一个TeamDraftStore类，负责保存和读取草稿，与表单页解耦。

dart复制class TeamDraftStore {
  static const _draftKey = 'publish_team_draft';

  static Future<void> saveDraft(Map<String, dynamic> draft) async {
    final prefs = await SharedPreferences.getInstance();
    await prefs.setString(_draftKey, jsonEncode(draft));
  }

  static Future<Map<String, dynamic>?> loadDraft() async {
    final prefs = await SharedPreferences.getInstance();
    final content = prefs.getString(_draftKey);
    if (content == null || content.isEmpty) {
      return null;
    }
    return jsonDecode(content) as Map<String, dynamic>;
  }
}

在每次字段变化或者按钮退出时，调用一次saveDraft即可。有一个细节要提醒：这里不要每次都new出一个Map，而是每次都从Controller直接取value，否则草稿里的数据可能和当前显示的不一致。保存草稿的最佳时机是dispose或页面切后台时，而不是每次键盘弹起都写，那样完全没有必要。

5.3 我在多台设备上反复测试后的设计心得

整个表单页面做完之后，我在手机形态和rk3568类开发板上分别跑了几轮，收获了几个值得分享的点。

第一，Form相关的组件虽然都是Flutter自绘，但在OpenHarmony形态中仍然需要关注中文字体渲染。相同字号在Android和OpenHarmony下视觉大小不完全一致，建议用逻辑像素做布局，不要写死物理宽度。

第二，时间字段的三个方案不要一开始就扎进细枝末节的样式调整。先确定功能是否能弹出、是否能回调值，再去处理样式的统一。如果一开始就纠结颜色和圆角，后面发现组件在当前设备上根本不能弹，浪费的时间是很可惜的。

第三，把校验规则抽象成独立文件是这几篇实战写下来最值得的一次重构。一开始我把validator写在Widget内部，字段少的时候没问题，一旦增加车型联动校验或者服务端错误回显，Widget代码就变得极其臃肿。抽成PublishValidators和GroupTeamModel后，我在表单页、预览页、草稿回显三个地方都复用了同一套模型和校验规则，维护起来轻松很多。

这个页面做完后，我又重新检查了一遍用户从首页进入、填写、退出、再进来、草稿回显、重新提交的整个链路。流程顺了之后，才真正感受到表单页并不是一个简单的“收集用户输入”的界面，它更像是一个把用户意图结构化的小型编辑器。字段多且杂的场景里，数据模型先行、校验规则统一抽象、选择器做好兼容备选，这些基础不扎实，后续的扩展都会变成打补丁式的痛苦维护。