受控模式指组件核心状态完全由父组件通过props控制，自身不维护独立状态；它只渲染传入的props值，用户交互时通过onChange等回调通知父组件，由父组件决定是否更新及如何更新。
组件的“受控模式”是指该组件的**核心状态（如输入值、展开/收起、选中态等）完全由父组件通过 props 控制，自身不维护独立状态**。它不自己决定“现在显示什么”，而是忠实地渲染传入的 props 值，并在用户交互时通过回调（如 onChange）把变化通知给父组件——由父组件决定是否更新、如何更新、甚至是否允许这次更新。
受控模式的关键特征
它不是一种“开关”，而是一种设计契约：
-
value 是只读镜像：组件接收
value，但不会自己改它；用户输入触发onChange，但输入框本身不会自动更新显示——除非父组件同步调用setState并再次传入新value -
无内部 state 管理相关逻辑：不使用
useState或this.state存储 value、open、checked 等主状态；所有行为都基于当前 props + 回调 - 可预测、可拦截、可派生：父组件能随时重置值、做格式化（比如输入时自动加千分位）、校验（禁止输入字母）、联动（A 改变时 B 自动清空）
为什么 Element UI 级别必须支持受控？
专业组件库面向的是复杂业务系统，不是单页小工具。真实场景需要：
- 表单统一管控：Form 组件要收集所有子字段值、触发表单级校验、批量重置，就必须每个 Input、Select、Switch 都能被外部驱动
- 状态跨层级同步：一个搜索框的值，可能同时影响表格筛选、图表维度、URL 参数；靠内部 state 无法穿透多层组件树
- 服务端回填与编辑一致性：编辑已有数据时，初始值来自接口，后续所有变更需明确提交；非受控组件容易因 DOM 本地状态和 props 不一致导致“改了但没生效”
- 可测试性与可调试性：受控组件的状态流是单向的（props → render → onChange → props），便于快照比对、状态回放、自动化测试
架构层面如何落地？不止于 Input
真正专业的组件库，会把“受控能力”作为底层设计原则，贯穿整个架构：
-
API 对齐设计：每个可交互组件提供成对 API，例如
v-model（Vue）或value + onChange（React），同时兼容defaultValue/defaultOpen实现非受控降级 -
状态抽象层：不直接写
useState(value)，而是封装useControlledState({ value, defaultValue, onChange })Hook，内部自动判断模式并返回安全的[stateValue, setState] -
事件标准化：所有状态变更统一走
onChange（或onSelect、onToggle），避免onClick+ref这类非声明式操作，保证数据流清晰 -
文档与类型强约束：TypeScript 接口中明确区分
value?: string（受控必需）与defaultValue?: string（非受控入口），IDE 能实时提示缺失 props
避开常见陷阱
很多团队尝试支持受控，却在细节上翻车：
- 不要混合使用 value 和 defaultValue：React 会警告“Uncontrolled to controlled”，Vue 会报“v-model conflict”。二者只能择一，不能“初始用 default，后面切到 value”
-
不要在受控组件里偷偷 useState：比如为了过渡动画存个
isOpening，这没问题；但若用useState存value就破坏了受控契约 -
受控不等于“更难用”：Element UI 的
:value="xxx" @input="xxx = $event"——本质就是受控
