目录
- 前言
- [一、 核心设计思想：数据流做桥梁，状态机控视图](#一、 核心设计思想：数据流做桥梁，状态机控视图)
- [二、 视图层与状态配置](#二、 视图层与状态配置)
-
- [1. 创建页面](#1. 创建页面)
- [2. 定义页面状态](#2. 定义页面状态)
- [3. 页面组件布局](#3. 页面组件布局)
- [三、 逻辑层实战：双表表单的无缝串联](#三、 逻辑层实战：双表表单的无缝串联)
-
- [步骤一：主表提交成功，捕获 ID 并推进状态](#步骤一：主表提交成功，捕获 ID 并推进状态)
- 步骤二：扩展表自动填充，完成闭环写入
- 本篇小结
前言
在上一篇中，我们确立了底层的 1+N（统一主表 fit_users + 动态角色扩展表 fit_trainer_profiles）数据模型。当用户在欢迎页选择了"我是教练"后，系统会将其引导至专属的教练注册流程。
但在低代码开发中，我们马上会面临一个非常实际的工程问题：低代码平台内置的"表单容器（Form）"通常只能绑定单张数据表。而教练注册既要写主表，又要写扩展表，且扩展表强依赖主表生成的新用户 ID。
如果强行写复杂的后端自定义 API 去做多表写入和异常回滚，不仅开发量大，还白白浪费了低代码平台自带的表单校验和提交能力。今天这篇，我们换个优雅的思路：利用低代码的原生能力，通过"分步表单 + 页面状态机"来实现双表的无缝串联和自动关联。
一、 核心设计思想：数据流做桥梁，状态机控视图
既然一张表单无法同时提交两张表，那我们就把注册动作拆解为"两步走"：
- 第一步：主表信息采集 。使用"表单容器 A"绑定主表
fit_users。用户提交后，平台会自动创建记录，并在成功回调中返回刚生成的记录 ID。 - 状态桥接：将返回的 ID 存入页面局部变量。
- 第二步：扩展信息采集 。视图自动切换到"表单容器 B"，绑定扩展表
fit_trainer_profiles。此时，表单中的"关联用户 ID"字段自动绑定刚才暂存的页面变量。用户填完专业资质点击提交，注册彻底闭环。
通过这种"数据流作为桥梁、状态机控制显示"的设计，我们完全不用写任何后端回滚代码，全凭低代码原生组件就能跑通复杂的业务流。
二、 视图层与状态配置
1. 创建页面
点击创建页面的图标，创建教练注册页面
2. 定义页面状态
在页面的状态管理中，我们需要定义两个核心变量来驱动视图和数据流：
activeTab(字符串，默认值"1")：控制当前激活的选项卡，newUserId(字符串，默认值"")：用于暂存第一步生成的主表用户 ID。
在代码去点击新增图标，创建自定义变量
3. 页面组件布局
添加顶部选项卡组件
配置选项信息，配置为基本信息和专业资质
打开切换标签时显示不同组件的配置
在基本信息下添加表单容器，数据模型选择用户表
在专业资质下边添加表单容器，数据模型选择教练扩展表
三、 逻辑层实战：双表表单的无缝串联
整个方案的灵魂在于"第一步提交成功后"与"第二步表单初始化"的事件联动。
步骤一：主表提交成功，捕获 ID 并推进状态
在第一个表单容器的调用数据源方法的出参位置，绑定我们的newUserId
在新增的变量赋值方法里，将变量值改为event.detail.id
在赋值成功后增加一个顶部选项卡设置选项值事件，配置为2
步骤二：扩展表自动填充，完成闭环写入
当视图切换到第二步后，Form2（绑定 fit_trainer_profiles 表）显现。
选择用户ID，设置选中值，绑定我们的newUserId变量
本篇小结
在低代码开发的实践中，"顺应平台特性"往往比"手写底层架构"更具性价比。
通过本章的改造，我们没有动用哪怕一行复杂的后端数据库事务代码，仅仅通过"Form1 成功回调 -> 写入 Page State -> Form2 默认值注入"的前端状态流转，就优雅地破解了 1+N 模型在低代码单表限制下的写入难题。这种分步向导式的注册设计，也带给用户更好的交互体验。
至此，系统的多角色身份注册闭环已经牢不可破。下一篇，我们将正式挺进健身房系统的核心业务深水区：如何设计和实现一套支撑"教练发布排班-学员在线预约-时段冲突防御"的【核心排课引擎】。 欢迎持续关注。