Flutter TextField 从入门到实战：取值、焦点、表单校验与格式化

如果你跟我一样，是在 Flutter 里从“显示界面”过渡到“用户交互”这个阶段，那 TextField 一定是你绕不开的组件。登录注册、搜索、个人信息编辑、后台表单，几乎所有需要用户输入的业务场景，最终都会落在一根输入框上。可怪就怪在，很多教程里照抄出来的输入框，键盘敲得飞快，界面文字也有了，回头却拿不到用户到底输入了什么——这个困惑不搞明白，表单与用户输入相关的开发基本是寸步难行。这篇就专门把 TextField 相关的用法和坑一次理清楚，包括最常用的参数、多输入框之间的焦点协作、表单校验、输入格式化，最后会分享几个真实项目里踩过的坑。

1. 输入框的第一课：先搞清楚 TextField 到底帮你做了什么

1.1 TextField 不是“一个框”，而是一套编辑状态管理器

很多零基础同学会把 TextField 当成一个带了边框的 Text 组件，觉得它不过是个显示文字的地方。这个误解是后面一系列问题的根源。

在 Flutter 内部，TextField 实际上是EditableText的一层包装。所谓“可编辑文本”，意味着它自带一整套编辑状态：当前文本内容、光标位置、选中范围、输入法连接信息，甚至包括一部分撤销操作的历史。你界面上看它是个框，但在 Flutter 的观念里，它更像一个“文本编辑器协议”的客户端。

这意味着 TextField 的显示内容不是直接从你的业务变量里读的，而是来自一套独立的内部状态。如果你不主动给这套状态建立连接，那它就只活在输入框自己的世界里：界面能显示、用户能输入，可你这个开发者反而什么都拿不到。这是新手最容易懵的地方——明明什么都对了，就是不知道怎么把输入的内容“取出来”。

1.2 取输入值的正确姿势：TextEditingController

Flutter 给输入框准备的桥梁，叫TextEditingController。你可以把它理解为输入框的“数据总闸”：用户每敲一个字，文本会进入这个 controller；你修改这个 controller 的 text，界面上的输入框也会跟着变化。两者是双向绑定的。

一个最小可运行的示例大概是这样的：

class LoginPage extends StatefulWidget { const LoginPage({super.key}); @override State<LoginPage> createState() => _LoginPageState(); } class _LoginPageState extends State<LoginPage> { final TextEditingController _accountController = TextEditingController(); final TextEditingController _passwordController = TextEditingController(); @override void dispose() { _accountController.dispose(); _passwordController.dispose(); super.dispose(); } void _login() { final account = _accountController.text.trim(); final password = _passwordController.text; debugPrint('account: $account, password: $password'); } @override Widget build(BuildContext context) { return Scaffold( body: Column( children: [ TextField(controller: _accountController), TextField( controller: _passwordController, obscureText: true, ), ElevatedButton(onPressed: _login, child: const Text('登录')), ], ), ); } }

注意几个细节：controller 必须声明成 State 的成员变量，不能放在build方法里。如果你在 build 里临时TextEditingController()，每次页面刷新都会重建一个 controller，输入框会错乱，而且老的 controller 没人释放。

在点击登录按钮时读取controller.text，才是拿输入值的最终手段。这里没有用onChanged，也不需要。因为你的目的不是在每次按键时都做点什么，而是提交时一次性取值。记住就好：只要用了 controller，提交时从 controller.text 里读，永远是最直接、最不容易出错的方式。

1.3 TextField 和 TextFormField 怎么选

除了 TextField，你还一定会遇到TextFormField。它俩长得像，输入体验也完全一样，很多人就不明白为什么要有两个。

TextFormField 是FormField家族的成员，它多了一层“表单字段”的身份，可以配合Form组件做统一的保存、校验、重置。TextFormField 底层依赖的还是 TextField 那套机制，只是外面包了一个 FormFieldState，用来管理这个字段的“值”和“错误状态”。

我的建议很直接：单独的搜索框、聊天输入框、验证码输入框，用 TextField 就够；一旦进入有多个输入项、需要校验、需要整体提交的表单页，直接用 TextFormField，后面做表单校验会省太多事。

2. 常用参数速查：写一个像样的输入框需要知道这些

TextField 的参数非常多，官方文档翻起来能看半天。这里我按实际写表单的维度，把这些参数分成几组，每一组解决一类问题。

2.1 外观与样式相关参数

大部分外观调整都在decoration里完成。它能配置 labelText（悬浮标签）、hintText（占位提示）、prefixIcon（左侧图标）、suffixIcon（右侧图标）、filled/fillColor（填充色）、border（边框）等。

TextField( decoration: InputDecoration( labelText: '账号', hintText: '请输入手机号或邮箱', prefixIcon: const Icon(Icons.person_outline), suffixIcon: IconButton( icon: const Icon(Icons.close), onPressed: _clearAccount, ), filled: true, fillColor: Colors.grey.shade100, border: OutlineInputBorder( borderRadius: BorderRadius.circular(8), borderSide: BorderSide.none, ), ), )

这里有个容易被忽略的点：如果你想在输入内容后显示“清空按钮”，那么清空的时机要根据controller.text是否为空来判断。但 controller.text 变化不会自动触发 rebuild，所以你需要监听onChanged再setState一次，否则按钮的显示状态不会更新。

2.2 输入行为和控制相关参数

这一组参数直接决定输入框的交互逻辑，也是新手最容易理解偏差的地方。

举个最常见的例子：keyboardType: TextInputType.number只能让键盘变成数字键盘，用户仍然可以通过粘贴把你只想收数字的输入框塞进一串字母。要真正限制输入，必须用inputFormatters，这个放到第 5 节详细说。

obscureText的坑则是：它要求必须单行显示。如果你在密码框里同时设置了maxLines: 6，运行时会直接抛异常，因为掩码状态没法正确渲染多行。

2.3 监听与回调相关参数

onChanged是每次输入内容变化时触发，适合做“输入中”的实时反馈，比如搜索联想、显示字数、清空按钮的显隐。

onSubmitted是键盘上的提交按钮被按下时触发，比如搜索键盘上的“搜索”按钮，或者单行输入框右下角“完成”按钮。

onTap是被点击时的回调，比如记录用户开始编辑的时间，或者统计埋点。

这三个回调要区分清楚：onChanged 管的是“正在输入”，onSubmitted 管的是“输入结束并提交”，onTap 只管“点击那一刻”。

2.4 一个完整的登录输入框示例

把它们合起来，一个比较规范的登录页输入框长这样：

TextField( controller: _accountController, focusNode: _accountFocusNode, keyboardType: TextInputType.emailAddress, textInputAction: TextInputAction.next, autocorrect: false, enableSuggestions: false, inputFormatters: [ LengthLimitingTextInputFormatter(32), ], decoration: InputDecoration( labelText: '账号', hintText: '手机号 / 邮箱', prefixIcon: const Icon(Icons.person_outline), border: const OutlineInputBorder(), ), onSubmitted: (_) { FocusScope.of(context).requestFocus(_passwordFocusNode); }, )

如果在登录场景里，账号框传入的 controller 与密码框传入的 controller 分别持有各自的值，提交时直接读两个 controller.text 就行，不需要在回调里维护一套临时状态。这个习惯越早建立越好，否则后期表单字段一多，代码会被 onChanged 撑得很难看。

3. 多输入框之间的协作：焦点、键盘和页面滚动的组合拳

单个输入框学会了，多输入框才是真考验。一个注册页往往有三四个输入框，再加上键盘弹起，整个页面高度会骤变。这一部分集中处理两件事：焦点怎么切换，键盘怎么不挡输入框。

3.1 FocusNode 与“回车跳到下一个输入框”

FocusNode是 Flutter 管理焦点的一套机制。每个输入框可以绑定一个 FocusNode，就像给它一个“焦点编号”。

典型场景：用户输入完手机号，按下键盘右下角的“下一步”，焦点自动跳到密码框。实现方式就是给两个输入框各自绑一个 FocusNode，然后在第一个输入框的onSubmitted里把焦点请求给第二个。

class _RegisterPageState extends State<RegisterPage> { final _phoneFocus = FocusNode(); final _passwordFocus = FocusNode(); final _confirmFocus = FocusNode(); final _phoneController = TextEditingController(); final _passwordController = TextEditingController(); final _confirmController = TextEditingController(); @override void dispose() { _phoneFocus.dispose(); _passwordFocus.dispose(); _confirmFocus.dispose(); _phoneController.dispose(); _passwordController.dispose(); _confirmController.dispose(); super.dispose(); } @override Widget build(BuildContext context) { return Column( children: [ TextField( controller: _phoneController, focusNode: _phoneFocus, keyboardType: TextInputType.phone, textInputAction: TextInputAction.next, onSubmitted: (_) { FocusScope.of(context).requestFocus(_passwordFocus); }, ), TextField( controller: _passwordController, focusNode: _passwordFocus, obscureText: true, textInputAction: TextInputAction.next, onSubmitted: (_) { FocusScope.of(context).requestFocus(_confirmFocus); }, ), TextField( controller: _confirmController, focusNode: _confirmFocus, obscureText: true, textInputAction: TextInputAction.done, ), ], ); } }

FocusScope.of(context).requestFocus是一种比较标准的写法。FocusScope 负责管理当前焦点区域，它的 requestFocus 比直接操作旧的 focusNode 更稳妥，因为 Flutter 的焦点树和组件树一样，是有层级关系的。

3.2 键盘弹起把输入框顶没了，问题多半在布局

很多人遇到的场景是：页面下方有个输入框，一点击，键盘弹起来，输入框被盖住，甚至整个页面被顶得乱七八糟。

首先要确认一个前提：Scaffold 的resizeToAvoidBottomInset默认是 true。它保证键盘弹起时，页面可用区域会压缩，相当于给键盘腾位置。大多数人不是在 Scafold 层弄坏的，而是在自己的布局里没考虑“压缩后页面还能不能滚动”这件事。

如果页面内容本身不能滚动，键盘压缩后，底部的输入框自然就没法完整显示。解决办法很简单：给主体包一层SingleChildScrollView或ListView。

Scaffold( resizeToAvoidBottomInset: true, // 默认是 true，别手滑关掉 body: SafeArea( child: SingleChildScrollView( padding: const EdgeInsets.all(16), child: Column( children: [ _buildPhoneField(), _buildPasswordField(), _buildConfirmField(), const SizedBox(height: 24), SizedBox( width: double.infinity, child: ElevatedButton( onPressed: _submit, child: const Text('注册'), ), ), ], ), ), ), )

还有一个容易忽略的细节：当页面滚动时，输入框可能能滚到键盘上方，但滚动位置不够，输入框贴着键盘边缘，焦点虽然存在，用户却看不到光标。经验做法是给 ScrollView 的底部留出足够空间，比如padding: EdgeInsets.only(bottom: 120)，或者在输入框拿到焦点后主动调用Scrollable.ensureVisible(context, duration: Duration(milliseconds: 200))把输入框拉进可视区。

3.3 键盘弹起后滚动到底部的惯性问题

一个我在真实项目里遇到的问题：表单内容比较长，键盘弹起后用户滚到了底部，收起键盘时，页面底部会出现一块空白的“惯性区域”，再往下拉又拉不动。其实这是resizeToAvoidBottomInset带来的合理行为：键盘收起，页面可视区域变高，SingleChildScrollView 的滚动范围也跟着变大，用户视觉上会有“页面白了一块”的突兀感。

解决办法没有标准答案，但我建议优先接受这个行为，而不是强行关闭 resizeToAvoidBottomInset。关闭它虽然让键盘弹出前后视觉不跳变，但代价是所有被键盘遮挡的输入框都需要手动滚动，这个 pain 更大。实际测试下来，绝大多数主流 App 用的都是默认行为，用户早就习惯了。

4. 表单校验的正确姿势：从手动 if-else 到 Form + TextFormField

4.1 手动校验的痛点

最常见的入门写法，是在提交按钮的回调里读一堆 controller，然后写一长串 if-else：

void _submit() { final phone = _phoneController.text.trim(); final password = _passwordController.text; if (phone.isEmpty) { setState(() { _phoneError = '请输入手机号'; }); return; } if (!RegExp(r'^1[3-9]\d{9}$').hasMatch(phone)) { setState(() { _phoneError = '手机号格式不正确'; }); return; } if (password.isEmpty) { setState(() { _passwordError = '请输入密码'; }); return; } // ... }

这个写法不是不能用，三个字段以内勉强能撑。但字段一旦超过五个，校验规则之间开始耦合：错误提示什么时候显示、用户修改后错误提示要不要消失、多个字段同时错误时焦点先给谁、提示完要不要自动滚动到对应位置……每一条都要自己管理。代码很快会变成一坨没人敢改的逻辑。

4.2 Form + TextFormField 的运作方式

Flutter 提供了一套专门解决这类问题的组合：Form+TextFormField。

Form用一个GlobalKey<FormState>来管理内部所有 FormField 的状态。TextFormField的validator属性接收一个函数，函数的返回值有两种情况：

• 返回null，表示这个字段校验通过；
• 返回一个字符串，这个字符串会直接显示在输入框下方的 errorText 上。

当调用formKey.currentState.validate()时，Form 会遍历所有子 FormField，逐个执行它们的 validator，并把校验结果反映到界面上。这样做的好处是：校验逻辑跟着字段走，而不是堆在提交按钮里一锅乱炖。

final _formKey = GlobalKey<FormState>(); Form( key: _formKey, child: Column( children: [ TextFormField( decoration: const InputDecoration(labelText: '手机号'), validator: (value) { if (value == null || value.trim().isEmpty) { return '请输入手机号'; } if (!RegExp(r'^1[3-9]\d{9}$').hasMatch(value.trim())) { return '手机号格式不正确'; } return null; }, ), TextFormField( decoration: const InputDecoration(labelText: '密码'), validator: (value) { if (value == null || value.isEmpty) { return '请输入密码'; } if (value.length < 6) { return '密码至少 6 位'; } return null; }, ), ], ), )

4.3 常见校验规则与代码示例

不同业务里的校验规则五花八门，但最基础、最常碰到的就那么几种：

两次密码一致的校验，是新手容易卡住的点。实现起来其实很简单：第二个输入框的 validator 里，直接读取第一个输入框绑定的 controller 就可以了。

TextFormField( controller: _confirmController, obscureText: true, decoration: const InputDecoration(labelText: '确认密码'), validator: (value) { if (value == null || value.isEmpty) { return '请再次输入密码'; } if (value != _passwordController.text) { return '两次输入的密码不一致'; } return null; }, )

这个写法能工作，是因为_confirmController和_passwordController都是 State 成员变量，在整个校验过程中它们的 text 一定是最新的。注意 validator 的value参数是当前字段自己的值，不要把它和 controller.text 弄混了。

4.4 提交校验与自动聚焦第一个错误项

调用_formKey.currentState!.validate()会返回布尔值：true 表示全部通过，false 表示至少有一个字段有问题。但它不会帮你把焦点移到失败的字段上。用户点了提交，看到页面上某个输入框下面冒出一行红字，自己去找是哪一个，体验很差。

自动聚焦第一个错误字段时，我见过有人尝试在 validator 里直接 requestFocus。这个思路对了一半，但实现上有风险：validator 在每次校验时都调用，页面重建、输入变化都可能触发，会导致焦点被反复抢占，用户都还没开始改错误项，焦点又被抢走了。

我推荐一个务实且零基础能看懂的办法：提交时先 validate 展示错误，再用一份“字段顺序 + 错误判断”的列表，找到第一个错误项并聚焦：

void _submit() { if (!_formKey.currentState!.validate()) { _focusFirstError(); return; } // 校验通过，继续提交 } void _focusFirstError() { final checks = [ (_phoneController.text.trim().isEmpty, _phoneFocusNode), (_codeController.text.trim().isEmpty, _codeFocusNode), (_passwordController.text.isEmpty, _passwordFocusNode), ]; for (final check in checks) { if (check.$1) { check.$2.requestFocus(); return; } } }

这个方案虽然看起来是把 validator 的逻辑重复了一遍，但胜在简单可靠、没有副作用。等以后规则复杂了，可以再考虑把这些校验规则抽成独立的数据校验层，统一复用。零基础阶段，先保证不出 bug，比追求架构优雅更重要。

另外有个和错误提示体验强相关的参数：AutovalidateMode。如果设置为onUserInteraction，用户正在输入的内容一旦非法，输入框会立刻显示错误，不用等提交。这个模式在用户重复修改同一个字段时非常友好，但要注意别在表单刚打开时就用always，否则页面一进入就看到一片红字，很劝退。

5. 输入格式化与限制：让用户只能输入你需要的内容

5.1 keyboardType 只是提示，不是限制

这是我在真实项目中反复跟新人强调的点：keyboardType改的是软键盘布局，不是输入内容的拦截器。把keyboardType设成 number，弹出的确实是小键盘，但用户把“abc”粘贴进输入框，Flutter 不会拦你，业务代码也不会收到任何异常提示。

所以，“用户只能输入数字”这种需求，不能靠 keyboardType 实现。真正的实现入口是inputFormatters。

5.2 inputFormatters 内置格式化器的用法

TextField和TextFormField都有inputFormatters参数，它接收一个List<TextInputFormatter>，按顺序处理用户输入的内容。

Flutter 自带了几个实用的 formatter：

• FilteringTextInputFormatter.allow(RegExp)：只保留匹配正则的字符。
• FilteringTextInputFormatter.deny(RegExp)：禁止匹配正则的字符。
• LengthLimitingTextInputFormatter(maxLength)：限制长度，比手动截断更优雅。

最常见的就是手机号限制：

TextField( controller: _phoneController, keyboardType: TextInputType.phone, inputFormatters: [ FilteringTextInputFormatter.digitsOnly, LengthLimitingTextInputFormatter(11), ], )

FilteringTextInputFormatter.digitsOnly相当于 allow 一个“只保留数字”的正则，再加一个 11 位长度限制，手机号输入的基本诉求就解决了。这里要提醒一句：LengthLimitingTextInputFormatter和maxLength参数是两套机制。maxLength 会显示计数器并限制输入，而 formatter 这层是直接作用于文本编辑流程的，行为上更接近“输入法层面就拦住了”。

5.3 自定义格式化器：手机号分段和金额校验

内置 formatter 能解决大部分简单需求，但业务里总有特殊格式要求，比如手机号要 3-4-4 分段显示，比如金额最多两位小数。

手机号分段最朴素的做法，是在TextInputFormatter.withFunction里做文本转换：

class PhoneInputFormatter extends TextInputFormatter { @override TextEditingValue formatEditUpdate( TextEditingValue oldValue, TextEditingValue newValue, ) { // 先去掉所有非数字字符 final digits = newValue.text.replaceAll(RegExp(r'\D'), ''); if (digits.isEmpty) { return TextEditingValue.empty; } // 最多 11 位 final trimmed = digits.length > 11 ? digits.substring(0, 11) : digits; // 按 3-4-4 插入空格 final buffer = StringBuffer(); for (var i = 0; i < trimmed.length; i++) { if (i == 3 || i == 7) { buffer.write(' '); } buffer.write(trimmed[i]); } final formatted = buffer.toString(); return TextEditingValue( text: formatted, selection: TextSelection.collapsed(offset: formatted.length), ); } }

这个版本是“光标永远在结尾”的简化实现。输入没问题，但如果用户把光标移到中间去删一个数字，格式化之后光标又会跳到末尾，体验有点别扭。完整的版本需要根据原光标位置计算它前面有多少个数字，再映射到格式化后的字符串中。这个逻辑本身不难，但写起来要细心，我建议是：入门阶段先理解透这段简化版，真实项目里如果确实需要光标保护，可以去看一下成熟开源库的实现思路，或者在业务允许的情况下取消分段展示。

金额输入是另一个典型场景。用户输入 100.50，系统应该在输入阶段就拦掉那些非法的中间状态。常见的做法是用正则校验每一步的输入是否符合金额格式：

TextField( controller: _amountController, keyboardType: TextInputType.numberWithOptions(decimal: true), inputFormatters: [ FilteringTextInputFormatter.allow(RegExp(r'^\d{0,7}(\.\d{0,2})?$')), ], )

关键点是正则里的\d{0,7}而不是\d+，以及(\.\d{0,2})?用 ? 表示小数部分可以不存在。这样用户输入“12.”这个中间状态时不会被拦掉，还能继续输入“5”补成“12.5”。如果写成^\d+(\.\d{0,2})?$，输入“12.”的一瞬间就会被拒绝，体验很糟糕。

关于 inputFormatters，最后提一个真实踩过的坑：只要用户使用输入法进行组合输入（比如中文输入法打拼音），formatter 的触发时机就会比预想的要频繁，中间态文本可能包含正在组合的拼音字母。如果你的限制是“只能输入纯数字”，组合输入阶段会把拼音字母也拦掉，导致用户中文输入失效。所以对纯中文输入框，不要随手加一个FilteringTextInputFormatter.allow(RegExp('[a-zA-Z]'))之类的限制，除非你能明确接受输入法组合态被破坏的后果。

6. 避坑实录：controller、页面切换与动态表单

6.1 忘记 dispose controller 会怎样

controller 是一个资源对象，需要手动释放。用完后不 dispose，短时间看不出问题，但页面频繁进出后，内存会一点点累积，尤其是 controller 还持有输入内容时，会对长期进入该页面的用户造成性能损耗。

这个问题的解决方案很无脑，但也最容易漏：凡是final TextEditingController _xxxController = TextEditingController();这样写的，在对应的 State dispose 方法里补一行对应释放。如果你每次写表单页都是这套模板，就不容易漏。

@override void dispose() { _phoneController.dispose(); _passwordController.dispose(); _confirmController.dispose(); _phoneFocus.dispose(); _passwordFocus.dispose(); _confirmFocus.dispose(); super.dispose(); }

6.2 Navigator 切换页面后输入内容还在吗

这个问题是无数人问过的。分两种情况说清楚：

第一种，从 A 页面Navigator.push到 B 页面，再返回 A 页面。此时 A 页面并没有被销毁，它只是暂时脱离了屏幕。A 页面的 State 还活着，里面的 TextEditingController 还在内存中，所以输入内容不会丢。你回到 A，看到的就是你离开时的样子。

第二种，使用Navigator.pushAndRemoveUntil或者pushReplacement这类方法，把原页面从路由栈里移除掉。这时候原页面的 State 会被销毁，controller 也会被释放，你回来时输入内容自然就没了。

还有一种比较容易误判的情况，是在 Tab 切换场景。如果 Tab 内容是用IndexedStack保持的，所有页面 State 都存活，输入内容不会丢。如果直接用body: _currentWidget这种写法，当 tab 切换时旧页面的 State 会被销毁，除非它在外层有其他缓存的机制，否则输入内容必然丢失。

所以结论是：输入内容能不能保留，取决于承载 controller 的页面 State 是否还活着。重要的业务数据不要依赖“页面状态刚好还活着”这种巧合，应该在输入完成或者页面退出时，把数据同步到更上层的业务对象里。

6.3 清空表单与重置校验状态

业务流程里经常要“提交成功之后清空表单”，或者“编辑框初始值变回默认值”。这里要区分两件事：清空输入内容，和重置 Form 的校验状态。

清空输入内容最直接的方式是逐个 controller.clear()。

_phoneController.clear(); _passwordController.clear(); _confirmController.clear();

如果你用的是 Form + TextFormField，还需要把校验状态也清掉。_formKey.currentState!.reset()会把每个 FormField 的值重置为 initialValue，同时清掉错误提示。但注意一个容易踩坑的细节：reset() 管的是 FormField 自己维护的字段值，它不一定去动你传入的 TextEditingController 里的 text。所以我的习惯是：提交成功后先挨个 controller.clear()，再调用一次 formKey.currentState.reset()，两件事分开做，避免在行为边缘问题上猜框架意图。

6.4 动态增删表单行的状态管理

热词里提到的动态表单配置，在实际项目里通常表现为“用户可以点添加按钮，动态增加一行商品编号输入框”。这种需求用 TextField 时，最需要小心的是 controller 的存储结构。

很多人第一反应是用List<TextEditingController>，按 index 去读值。这个方案在只追加不删除时没问题，但如果中间删掉一行，后面所有行的 index 都会前移，你读到的一行号对应的可能是另一行的值，数据整体错位。

我推荐用Map<String, TextEditingController>，key 是每一行独有的标识（比如时间戳或自增 id）。增删行时去掉对应的 key 即可，删除时也要记得把被删除的 controller dispose 掉，否则又会回到内存泄漏的老问题上。

final Map<String, TextEditingController> _itemControllers = {}; void _addItem() { final id = DateTime.now().millisecondsSinceEpoch.toString(); _itemControllers[id] = TextEditingController(); setState(() {}); } void _removeItem(String id) { _itemControllers.remove(id)?.dispose(); setState(() {}); } void _collectItems() { for (final entry in _itemControllers.entries) { final value = entry.value.text; // entry.key 是行的唯一标识，不会因为删行而错位 } }

动态表单的场景里，单一的 controller 已经不够用了，你管理的不只是一两个输入框的状态，而是一整套输入框集合的一致性。这种时候一定要记住核心原则：controller 是输入框的数据源头，谁销毁页面谁负责释放它，谁管理列表谁负责维护它的映射关系。

再回到开头那个困惑：为什么输入框写出来了，却拿不到用户输入的内容。只要养成一个习惯就好：输入框的“数据权”只交给 controller，不从临时回调里抓取，不在 build 里创建，也不在动态列表里裸奔。表单与用户输入这件事的 80% 问题，基本都出在这三个坏习惯上。等你把 controller 用熟了，后面再去做动态表单、复杂校验、跨页面回填，都会顺很多。