RHF 的 useFormContext 与 Controller 在组件解耦中的应用是什么？
useFormContext 通过 Context 共享表单实例，深层组件无需传 props 即可访问 form 方法/状态，实现组件解耦。Controller 包装受控组件（第三方 UI 库），把字段值/onChange/ref 桥接到 RHF，处理注册与校验。工程应用：复杂表单组件结构清晰，表单实例通过 context 传递，受控组件用 Controller 接入，解耦数据与 UI。
useFormContext 共享实例、Controller 桥接受控组件，两者共同实现表单组件解耦。
字段级校验与服务端校验如何协作？
字段级校验（客户端，如 zod resolver）在 onChange/blur 即时校验，提供即时反馈；服务端校验在提交时校验业务规则（唯一性、权限）。协作：客户端校验做基础（格式、必填），服务端做权威校验（业务），表单错误合并展示（服务端错误映射到字段）。命中一方优先，避免重复。
客户端即时校验 + 服务端权威校验，错误合并展示，各司其职。
Floating UI (@floating-ui/react) 在 Popper/Anchor 定位中的工程取舍（含 popover）是什么？
Floating UI 是 headless 定位库，提供精确的 popper/anchor 定位，处理碰撞检测（自适应翻转）、箭头、偏移、虚拟元素等。工程取舍：相比旧 Popper.js，Floating UI 更现代、可组合、框架无关；相比内置定位（如 CSS），它处理复杂场景（溢出、滚动、自适应）。适合作 popover、tooltip、dropdown 的定位引擎。
Floating UI 提供健壮的定位与碰撞处理，比旧 Popper 更现代，适合复杂浮层。
React Aria (react-aria-components) 在 Headless UI + i18n + a11y 中的工程价值是什么？
React Aria 提供 headless 组件逻辑（按钮、菜单、对话框、选择器等），内置完整可访问性（键盘导航、ARIA、焦点管理）与国际化（多语言、日期、数字）。工程价值：无样式可自由定制，同时自动获得 a11y 与 i18n，避免自建 UI 的 a11y 坑。react-aria-components 是其实例化组件。
React Aria 把 a11y + i18n 内建到 headless 逻辑，是复杂交互组件的可靠基础。
表单草稿自动保存的存储选择与冲突恢复（本地草稿 vs 服务端最新）如何设计？
草稿存储：简单用 localStorage（同步、小数据），大/复杂用 IndexedDB，跨设备用服务端。冲突恢复：本地草稿 vs 服务端最新，需比较时间戳/版本，提供"最新/草稿/合并"选择。设计：保存时记录时间戳与版本，恢复时比对，冲突时提示用户决策，避免覆盖。存储选型按数据量、跨设备需求、可靠性。
存储按数据量与跨设备选，冲突恢复用版本/时间戳比对并让用户决策。
表单状态与 URL query 同步的工程价值及序列化边界是什么？
表单状态与 URL query 同步：筛选、分页、搜索词写入 URL search，实现可分享、刷新恢复、后退前进恢复。工程价值：状态可寻址、可分享、可恢复。序列化边界：URL 只放可序列化（字符串/数字/布尔）的简单状态，复杂对象、大文本、敏感数据不放入 URL；用 encode/decode 与 schema 校验，避免 URL 过长与非法值。
URL 同步管简单可分享状态，复杂/敏感数据不放入，注意序列化边界。
dirtyFields/touchedFields/errors 的语义差异与保存按钮禁用、错误时机、isDirty 对比的工程应用是什么？
dirtyFields 标记与初始值不同的字段；touchedFields 标记用户交互过的字段；errors 标记校验失败字段。工程应用：保存按钮禁用用 formState.isDirty（或 dirtyFields 非空）；字段错误时机用 touched 后才显示错误（避免未交互就报错）；isDirty 对比初始值判断是否改动。三者语义不同，分别用于"是否改动/是否交互/是否错误"。
dirty=改动、touched=交互、errors=错误，分别驱动按钮禁用、错误时机、校验展示。
表单错误信息展示与可访问性如何实现？
错误信息展示需与输入框关联（aria-describedby 指向错误 id），输入框标记 aria-invalid，错误有颜色/图标/文本（不只颜色）。可访问性：错误出现时焦点移到错误字段或容器，用 aria-live 播报。工程价值：无障碍用户能感知错误，错误信息清晰，符合 WCAG。配合提交失败时焦点管理。
错误展示用 aria-describedby/aria-invalid 关联，焦点管理 + aria-live 提升可访问性。
useFieldArray 在订单/发票中的工程应用是什么？
订单/发票用 useFieldArray 管理动态行（商品、明细），append/remove 增删行，字段名 index 生成。工程应用：行级增删、行内计算（数量×单价）、合计更新、逐行校验。配合 watch 监听行数据计算合计，性能上按行注册避免整表重渲染。是动态表格表单的标准实现。
useFieldArray 管理动态行，结合 watch 计算合计，是订单/发票表单核心。
表单输入的性能优化（防抖/节流/受控）如何选择，大表单的渲染优化怎么做？
输入优化：搜索/远程校验用防抖，滚动/高频用节流；受控 vs 非受控：非受控（RHF ref）减少重渲染，受控需订阅。大表单优化：字段级订阅（RHF 按字段）、拆分组件避免整表重渲染、用 memo 隔离、禁用值变化无关的渲染、字段数组按需。选择按场景：高频输入防抖、性能敏感非受控、大表单细粒度订阅。
防抖/节流管频率，非受控/字段订阅管渲染，大表单综合优化。
Conform（渐进增强）与 React 19 form action 的工程价值是什么？
Conform 面向 Remix 的渐进增强表单（无 JS 用原生 POST），React 19 form action 让表单提交原生支持（action 函数处理，useActionState 管理状态）。工程价值：表单提交符合原生语义、支持渐进增强与服务端处理、状态管理简化。适合全栈/服务端优先场景，与 SPA 客户端表单互补。
Conform 与 React 19 form action 都倾向原生表单语义，支持渐进增强与服务端。
表单无障碍中的 aria-invalid/aria-describedby 关联与提交失败时的错误焦点管理是什么？
输入框校验失败时设 aria-invalid="true"，错误信息用 aria-describedby 关联到输入框 id，读屏能读出错误。提交失败时焦点移到第一个错误字段或错误容器，用 aria-live 播报，帮助用户定位。工程价值：无障碍用户能感知并定位错误，提升表单可用性，符合 WCAG。
aria 关联 + 提交失败焦点管理，让错误对无障碍用户可见可定位。
同页多表单协作的状态隔离与汇总提交如何设计？
同页多表单用独立 useForm 实例隔离状态，各自校验与错误。汇总提交：收集各表单数据合并提交，或用一个统一数据源，各表单写各自字段。协作：表单间联动（如一个表单的字段影响另一个）用共享外部状态或事件。设计：状态隔离 + 汇总提交 + 联动机制，避免相互污染。
多表单独立实例隔离状态，汇总提交合并数据，联动用共享状态/事件。
大型表单的性能优化（按需校验、字段级订阅、避免整表重渲染）如何做？
大型表单优化：按需校验（blur/touched 才校验，避免每次 onChange 全量校验）；字段级订阅（RHF 只重渲染变化的字段）；避免整表重渲染（拆分组件、memo、隔离无关字段）。配合 useFieldArray 动态行局部渲染。这些方法协同减少渲染与校验开销，提升大表单性能。
按需校验 + 字段级订阅 + 组件拆分，是大型表单性能的关键。
表单状态在页面刷新后的恢复与过期草稿的处理策略是什么？
刷新恢复：草稿持久化（localStorage/IndexedDB/服务端），刷新后恢复表单状态。过期草稿处理：记录时间戳，超过阈值标记过期，提示用户"恢复/丢弃"，或服务端比对版本。策略：恢复时校验 schema 兼容，过期草稿引导用户重新填写或清理。避免恢复过期数据与数据损坏。
刷新恢复靠持久化，过期草稿按时间戳/版本判断并提示用户决策。
表单隐式提交：Enter 在单输入框与多输入框的默认行为差异、textarea 换行与多提交按钮的首按钮规则是什么？
表单隐式提交：单输入框 Enter 提交；多输入框按表单默认行为（第一个 submit 按钮触发）。textarea 内 Enter 换行而非提交（默认）。多提交按钮规则：隐式提交触发第一个 submit 按钮（或默认按钮）。需显式控制时加 onKeyDown 处理 Enter 或阻止默认。理解这些默认行为避免误提交。
Enter 隐式提交规则与 textarea 换行、多按钮首按钮，是表单默认行为细节。
RHF 与 Zod resolver 的 schema 单一来源：类型推导、服务端复用与校验逻辑分层的边界是什么？
RHF + zodResolver 用 schema 驱动校验与类型，单一来源（z.infer 推导类型）。边界：客户端 schema 做即时校验，服务端 schema 做权威校验（可能不同，服务端更严格）；共享 schema 需保证两端一致，但服务端不信任客户端校验。分层：基础校验（格式/必填）可共享，业务校验（权限/唯一性）服务端。维护单一来源同时分层。
schema 单一来源驱动类型与校验，但客户端/服务端分层，服务端权威。
表单提交幂等与防重复提交（提交锁、请求去重）的工程实践是什么？
防重复提交：提交时禁用按钮（isSubmitting）、提交锁（状态标志）、请求去重（同一请求忽略重复）。幂等：服务端处理重复提交不产生副作用（幂等键、唯一约束）。工程实践：客户端提交锁 + 禁用按钮，服务端幂等 + 幂等键，双保险，避免重复创建/重复提交。
客户端提交锁 + 服务端幂等，双保险防重复提交。
表单错误消息的国际化：字段名占位、复数规则与 RTL 布局下错误展示的适配是什么？
错误消息国际化：字段名用 i18n key 占位（如 {field} 必填），复数用 Intl.PluralRules/ICU 消息（如"1 个错误/3 个错误"）。RTL 布局：错误图标/文本在 RTL 下镜像，aria 关联不影响。工程价值：错误消息多语言正确、复数正确、RTL 布局适配，提升国际化表单可用性。
错误消息 i18n 用字段名占位、复数规则，RTL 布局镜像适配。
