题目重点：Frontend VO 题目描述按 mockup 写含 input、button、validation message 的 card；以可访问的表单状态机组织实现。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练版单输入字段，非空校验，提交由注入的 async onSubmit(value) 完成；题目未说字段必须非空，此规则仅示例。
- 状态为 idle/editing/invalid/submitting/success/serverError；具体文案、颜色和布局以现场 mockup 与需求为准。
- 使用语义化 form、label、button 和错误提示关联；移动端适配和键盘操作作为通用工程质量要求。
解题路线
- 先逐条把现场 requirement 变成验收清单：输入限制、何时校验、错误文案、按钮 disabled 条件、提交成功动作与 extension；没有信息时主动问。
- 把 input 做受控状态，submit 事件 preventDefault；先跑客户端校验，失败进入 invalid 并聚焦/描述错误，成功转 submitting 并禁重复提交。
- 提交 promise 成功/失败分别切 success/serverError；服务器也要校验，客户端校验只提供即时反馈，不能当安全边界。输入变更后错误是否清空需按 UX 契约。
- 错误文本用 aria-describedby 与 input 关联、aria-invalid 标记，异步结果用 aria-live 适度播报；点击与 Enter 提交行为一致。
- extension 作为独立功能添加，避免在基本输入/校验未通过前改结构；测试空值、快速双击、请求失败、键盘与重试。
手动走一遍
训练流程：初始 idle；用户只输入空格并提交，trim 后为空，显示 validation message 且不调用 onSubmit；输入有效值后提交进入 submitting，第二次点击不再发请求；若 API 拒绝，显示 serverError 并可修改重试。题目没有该非空规则。
规模与取舍
单字段状态更新 O(1)；请求耗时取决于 API。若有多个字段，校验 O(字段数)；UI 的 DOM 规模由实际 mockup 决定。
易错点与追问
容易失分的边界
- 把训练示例校验文案当成原题要求。
- 只按像素画卡片，不支持 label/键盘/错误关联。
- 提交时按钮仍可多次触发请求。
- 客户端校验通过就认为服务端一定接受。
- 未完成基本 requirements 就优先写 extension。
继续深挖
- 如果要求异步唯一性校验，如何防旧响应覆盖新输入？
- 多个输入字段如何组织错误？
- 提交重复请求如何幂等？
- 如何按现场 mockup 做响应式布局？
