想象一下，你面前有一大箱乐高积木。为什么你能用同一盒积木搭出城堡、飞船、甚至一座城市？因为乐高有一套标准化的“基础件”——2×4 的砖块、4×6 的底板、带凹槽的连接件——它们各自职责清晰、接口统一，可以无限次地拔下来、插上去，组合成全新的造型。如果你把每一块积木都做成独一无二的奇形怪状，那这盒乐高根本没法玩。 前端组件设计，玩的就是同一门“积木艺术”。一个 Button、一个 Card、一个 Table，就是数字世界里的标准砖块；而你在页面上看到的每一个输入框、弹窗、数据列表，都是这些砖块按规则拼插出来的作品。好的组件设计，让团队像乐高工厂一样高效：零件能复用、拼法有文档、接口不打架。反之，组件拆得乱七八糟，就像把乐高零件焊死在一起，改一处就崩一片。 这篇文章将带你走进组件设计的核心世界：如何拆分组件、如何设计 props 接口、如何用 children 做插槽、如何理解受控与非受控、为什么组合优于继承、以及高阶组件和 render props 这两大复用利器。读完它，你就能像资深乐高工程师一样，把任何 UI 拆成优雅的积木，再拼出无限可能。

岗位关联

掌握组件设计，是前端工程师从“能写页面”进阶到“能搭系统”的分水岭。它直接决定你的代码能否被团队复用、能否经得起迭代，是晋升高级前端、走向组件库工程师的核心能力。

目录
  1. 可视化演示
  2. 组件拆分原则
  3. props 接口设计
  4. 插槽与 children
  5. 受控与非受控
  6. 组合复用模式
  7. 文档与组件分类
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示组件组合树结构(App→Hdr/Body/Ftr)，以及Props接口、Slot插槽、Ctrl受控/非受控、HOC高阶组件四大设计原则。

本节配有交互动效（进入视口后自动加载，约 3KB）。

组件设计原则 Props：接口设计清晰可复用；Slot：插槽机制灵活组合子内容 Ctrl：受控/非受控组件模式；HOC：高阶组件增强复用逻辑 组合优于继承：Compose > Inherit

组件拆分原则

乐高工厂里，一块标准的 2×4 砖块为什么能成为万能零件？因为它只做一件事：提供固定尺寸的拼接面。它不会把轮子、车窗、方向盘全做进同一块砖里——那是成品玩具，不是积木。组件拆分的第一课，就是学会辨别“这是标准砖，还是焊死的成品”。

在前端世界，这个辨别标准叫单一职责原则：一个组件只负责一个清晰的功能点。比如 Avatar（头像）只负责展示用户图像，Input（输入框）只负责接收文本输入。如果把头像的裁剪逻辑、上传逻辑、圆形边框全塞进同一个组件，它就变成了“焊死的成品”——别人想用其中一部分，只能连带整块拿走。

拆分粒度的另一把尺子是高内聚低耦合：组件内部的逻辑要紧紧抱团（高内聚），组件之间的依赖要尽量松散（低耦合）。原子设计思想则给出了一条拆分路径：原子（按钮、输入框）→ 分子（搜索框、用户卡片）→ 组织（导航栏、表单区块）。就像乐高从最小砖块开始，逐级拼成更大的结构。

这就好比乐高工厂的质量检测：每一块砖在出厂前都要确认“它是否只干一件事、能否被独立使用”。你在拆分组件时，不妨问自己：如果把这个组件拿到另一个项目里，需要连带搬走多少“非本组件”的东西？搬得越少，拆分越成功。拆分的终极目标，是让每一个组件都成为那块可以乱入任何乐高城堡的 2×4 砖块。

内聚度=组件内部相关元素数组件总元素数,耦合度=依赖外部组件数组件总依赖数\text{内聚度} = \frac{\text{组件内部相关元素数}}{\text{组件总元素数}},\quad \text{耦合度} = \frac{\text{依赖外部组件数}}{\text{组件总依赖数}}
内聚度越高、耦合度越低，组件越“标准”；理想状态是组件内部紧密协作，对外只暴露少量接口。
  1. 内聚度的分子“内部相关元素数”组件内部所有逻辑都围绕同一职责，相关元素就多。比如一个登录表单组件，账号、密码、校验逻辑全都相关。
    N相关=组件的内部相关元素数N_{\text{相关}} = \text{组件的内部相关元素数}
  2. 内聚度的分母“总元素数”总元素包含相关元素和无关元素。若把“记住我”逻辑也硬塞进来，分母变大，内聚度下降。
    N总=N相关+N无关N_{\text{总}} = N_{\text{相关}} + N_{\text{无关}}
  3. 耦合度的表达式组件依赖的外部组件越少，越容易被单独复用到新场景。
    C=外部依赖数总依赖数C = \frac{\text{外部依赖数}}{\text{总依赖数}}

props 接口设计

拿到两块乐高砖，为什么能严丝合缝地拼上？因为它们的凸粒和凹槽尺寸是统一的——这就是“接口规范”。组件也是如此，而 props 就是这个接口规范。设计一个组件的 props，就是在定义它对外承诺的拼接方式。

接口设计的第一原则是命名语义化：isLoading 比 flag1 好，onConfirm 比 fn 好。就像乐高的凸粒不会标注“这是第 3 个凸粒”，而是通过位置告诉你它属于哪块砖——好名字让使用者无需读源码就能猜到用途。第二原则是类型、默认值与校验：给 string 类型的 prop 设默认值、给 number 类型做范围检测，相当于在积木上刻了安全公差带，拼错了会立刻“咔哒”一声弹出来，而不是硬塞进去默默坏掉。

第三原则是单向数据流：父组件通过 props 把数据传给子组件，子组件不能反向修改 props，只能通过 onChange 这类回调通知父组件。这像乐高拼搭中的“自上而下”：上一层的重量压在下层砖上，下层砖不会自己长高去顶动上层。

把 props 想成乐高接口上的“防呆设计”：凸粒的大小告诉你该往哪个凹槽插，颜色告诉你这块砖属于哪个区域。优秀的 props 设计让组件用起来像拼乐高一样“闭着眼都不会拼错”——类型校验挡住错误拼法，语义化命名告诉你拼法含义，单向数据流保证拼好后不会散架。

Component(P)=f(Propsparent→Statechild),Props 变更⇒重新渲染\text{Component}(P) = f(\text{Props}_{parent} \to \text{State}_{child}),\quad \text{Props 变更} \Rightarrow \text{重新渲染}
组件的渲染输出是 props 的纯函数：props 变，视图变；子组件绝不直接写 props。
  1. “Props 从父到子”箭头表达数据只能从父组件流向子组件。父组件通过属性传递，子组件读取属性渲染，绝不反向修改。
    Pparent→PchildP_{parent} \to P_{child}
  2. 渲染函数 f组件本质是一个函数，输入 props，输出 UI。就像乐高图纸：输入砖块型号，输出造型。
    UI=f(props)\text{UI} = f(\text{props})
  3. “Props 变更触发重新渲染”React/Vue 中当父组件传入的 props 值变化时，组件会重新执行渲染逻辑，用户界面随之更新。
    ΔP⇒re-render\Delta P \Rightarrow \text{re-render}

插槽与 children

乐高最迷人的地方在于：一块屋顶砖块留出了凹槽，你可以在凹槽里插旗子、插人仔、插任何兼容的零件。children 就是这个凹槽——容器组件在不破坏自身结构的前提下，为你预留了一个自由填充区域。

默认插槽就是最常见的 children：<Card>{/* 这里放任何东西 */}</Card>。Card 组件只管自己的边框、阴影、圆角，内容区域完全开放给使用者。这就像乐高车厢的载货区：车厢结构固定，但里面装什么货，由你决定。具名插槽则是为了让一个容器有多个凹槽：比如 Card 有 header、footer 两个插槽，分别放标题栏和操作栏，就像一辆乐高卡车，车头和货厢是分开的设计，各自接收对应的零件。

作用域插槽更进一步：容器组件允许插槽内容“回读”容器内部的数据。好比乐高发射台的仪表盘会告诉你“当前发射倒计时：3、2、1”，插槽里的显示屏可以读取发射台的倒计时状态。它的使用场景在表格组件中尤其常见：列的内容需要访问当前行数据。

在搭建页面时，你需要这样想问题：哪些部分是“框架”，必须由组件自己保证一致？（比如弹窗的遮罩、卡片的圆角）哪些部分是“凹槽”，应该交给使用者自由发挥？（比如弹窗里的表单、卡片里的内容）把这两者分清楚，你的容器组件就能像乐高底座一样，同一块底盘插出千变万化的造型。

Card=Frame+children+Footer\text{Card} = \text{Frame} + \boxed{\text{children}} + \text{Footer}
children 是组件设计中的“开放扩展点”：容器负责框架，插槽负责内容灵活性。
  1. Frame（外框）容器组件的固定结构，比如 Card 的边框、背景、圆角。它定义了组件的“骨架”。
    Frame：边框+背景+圆角\text{Frame：边框+背景+圆角}
  2. 被框住的 children 插槽这是开放区域，可以填入任意的其他组件或元素。它就是“凹槽”本身。
    任意子节点\boxed{\text{任意子节点}}
  3. Footer（底部）具名插槽的示例，用于放置操作按钮或附加信息，位置固定但内容自由。
    Footer：底部插槽\text{Footer}：\text{底部插槽}

受控与非受控

乐高有一个经典场景：你用手控制人仔站还是坐——这是“受控”；你把一个弹簧机关放进积木里，弹簧自己会弹——这是“非受控”。受控组件就是“手控人仔”：数据存在父组件里，通过 value + onChange 双向配合，父组件完全掌控状态。非受控组件就是“弹簧机关”：组件自己内部维护数据，父组件不插手，需要用 ref（引用）才能取到值。

受控组件的优点是可预测、易调试：你的手按到哪，人仔就是什么姿势，任何时刻你知道它处在什么状态。缺点是需要写更多代码（每个输入都要配 value + onChange）。非受控组件的优点是代码简洁，适合不需要追踪状态变化的场景，比如搜索框的值只在点提交时才需要；缺点是状态像弹簧一样“自己弹走”了，想监听每一次变化就很麻烦。

选择策略其实很简单：如果这个值会影响组件外部（如提交表单、联动其他组件），用受控；如果值只是组件内部局部使用（如搜索框占位、文件选择），用非受控。

动手写之前先问一个问题：“这个值，如果无人驾驶车上的方向盘——我需要随时知道它在哪、要去哪吗？”需要就做成受控（方向盘连着一个接收器）；不需要就大胆用非受控（方向盘下面是个独立的弹簧），少写一半代码。

受控：value=f(父组件 state),onChange⇒父组件 setState\text{受控}：\text{value} = f(\text{父组件 state}),\quad \text{onChange} \Rightarrow \text{父组件 setState}
  1. 受控的 value 来自父组件父组件用自身状态作为 value 传给子组件，子组件自己手里不存值。
    value=stateparent\text{value} = \text{state}_{parent}
  2. onChange 回调父组件用户输入时，子组件把新值通过事件通知父组件，父组件更新 state，再回传新 value。
    onChange→setState→新 value\text{onChange} \to \text{setState} \to \text{新 value}
  3. 非受控的对比组件内部用自持状态管理值，父组件不参与每一次变化。
    value=stateself\text{value} = \text{state}_{self}

组合复用模式

乐高从不会用“继承”来创造新模型——你不会看到一块砖“继承”了另一块砖的形状然后长成新砖。乐高的方法是组合：两块砖拼在一起，形成新结构。前端组件设计也是一样，组合优于继承。继承让子类绑死父类的全部特性，而组合让组件自由拼装。

但要处理“多个组件共享逻辑”的问题时，直接复制粘贴是噩梦。于是有了两大复用模式：高阶组件（HOC） 和 render props。

高阶组件是一个“工厂函数”：你给它一个组件，它返回一个经过包装的新组件。举个例子，withLoading(Table) 会返回一个自动带加载状态的 Table——就像乐高工厂给普通砖块喷上夜光涂层，生成一块“夜光砖”，你依然能用它原来的拼法，但它多了一个发光的“能力”。

render props 模式则是一个“传函数”的思路：组件把内部状态作为参数，传给渲染函数。比如 <Mouse render={pos => <Cursor pos={pos} />} />——Mouse 组件负责追踪鼠标位置，至于拿到位置后渲染什么，由调用方决定。这就像一块乐高传感器：它把“检测到障碍物”的信号发送出去，至于信号触发什么动作，由连接它的接收器决定。

如果说 props 和 children 是“砖块和凹槽”，那 HOC 和 render props 就是“乐高改装车间”。HOC 给砖块批量加装能力（夜光、防水、磁吸），render props 给砖块装传感器（检测、追踪、回调）。理解这两种模式，你就从“会拼乐高”升级到“会设计改装件”了。

HOC：C′=withFeature(C),render props：R=Component(frender)\text{HOC}：C' = \text{withFeature}(C),\quad \text{render props}：R = \text{Component}(f_{render})
HOC 是“包装”，render props 是“回调”；两者的本质相同——把复用逻辑抽离，把可变部分留给调用方。
  1. HOC 的包装公式withFeature 是一个接收组件、返回新组件的函数。新组件拥有被包装组件的一切，再附加新能力。
    C′=withFeature(C)C' = withFeature(C)
  2. render props 的渲染公式组件的 props 里有一个 render 函数，组件把自己的状态作为参数调用它，渲染内容完全由调用方控制。
    R=Component(render(state))R = Component(render(state))
  3. 两者的联系两种模式都是“倒置控制”——不直接告诉组件“你要做什么”，而是把决策权交给调用方。
    控制倒置=复用逻辑+灵活渲染控制倒置 = 复用逻辑 + 灵活渲染

文档与组件分类

一个优秀的乐高套装出厂时，一定会附带说明书和分类盒：零件按颜色、功能分区，说明书按步骤图示拼法。组件库也一样，文档和分类是组件设计体系的“说明书和分类盒”。

组件的分类方式通常有三种维度：按功能分（展示型、交互型、容器型），按粒度分（基础组件、复合组件、业务组件），按使用范围分（通用组件、局部组件）。就像乐高零件盒里的分区：基础砖、轮子、人仔、装饰件各有各的格子。

设计文档则包含：组件用途、设计规范（尺寸、颜色、间距）、API 说明（props、事件、插槽）、使用示例、注意事项。好的文档让组件变成“不用教学就会拼的乐高”：使用者在文档里找到型号（组件名）、看懂图纸（示例）、查到公差（props 定义），就能立刻上手。

在真实项目里，一个没有文档的组件库，就像一堆混在一起没有分格的乐高零件——你知道它们能拼出东西，但每次都要翻半天、试错半天。建立简单的组件白皮书、维护 Storybook（组件开发工具）文档、按功能分目录存放组件，这三件事能让你的“乐高箱”从凌乱变为专业。组件的价值，一半在代码里，一半在文档里。

文档完整度=已覆盖的 API 项组件实际 API 项+有示例的场景数典型使用场景数\text{文档完整度} = \frac{\text{已覆盖的 API 项}}{\text{组件实际 API 项}} + \frac{\text{有示例的场景数}}{\text{典型使用场景数}}
文档不是代码的附属品，而是组件“可复用性”的一半：没有文档的组件，等于没有说明书的高难度乐高。
  1. API 覆盖度（第一项）文档里写全了 props、事件、插槽的组件，才能让使用者不读源码就拼装。
    Dapi=文档覆盖 API 项总 API 项D_{api} = \frac{\text{文档覆盖 API 项}}{\text{总 API 项}}
  2. 示例覆盖度（第二项）每个典型场景都有代码示例，相当于乐高图纸上的实物图。
    Dsample=有示例场景典型场景D_{sample} = \frac{\text{有示例场景}}{\text{典型场景}}

AI 应用场景

场景 1：低代码平台的可视化拖拽设计器

阶段：前端实现阶段

解决的问题：低代码平台的核心是“拖拽组件 → 生成页面”。如果组件接口混乱、拆分不合粒，拖拽运行时根本无法动态注入 props 和 children。通过标准化的 props 接口 + 插槽设计，AI 搭建引擎可以像乐高机器人一样，自动识别每块“砖”的接口，完成页面的动态组装。

具体案例：某低代码平台的表单搭建模块，预置了 50+ 个遵循统一 props 规范的表单组件。AI 引擎根据用户拖拽的 JSON 描述，自动绑定 value/onChange。用户拖一个“省市区选择器”，引擎自动为它注入数据源 props 并追加到表单的 children 插槽中，整个过程不用写一行代码。

场景 2：AI 辅助组件文档自动生成

阶段：代码分析阶段

解决的问题：组件设计文档需要大量人工撰写、频繁过期。利用 LLM 的代码理解能力，自动扫描组件源码，提取 props 定义、类型、默认值和注释，生成规范的设计文档，就像乐高工厂自动为每块新砖印刷说明书。

具体案例：某前端团队将 40+ 个自研组件输入到 LLM pipeline 中，AI 自动输出包含 API 表格、示例代码、注意事项的 Markdown 文档，直接接入 Storybook。组件文档覆盖率从 30% 提升到 90% 以上，新成员接入组件的上手时间从 2 天缩短到 2 小时。

Python 演示

python64 行
"""组件设计模拟：用积木拼接展示 props 与 children 的核心思想"""from typing import Any  class VNode:    """虚拟 DOM 节点，对应一块乐高积木"""     def __init__(self, tag: str, props: dict, children: list | None = None):        self.tag = tag        self.props = props        self.children = children or []     def render(self) -> str:        props_str = " ".join(f'{k}="{v}"' for k, v in self.props.items())        inner = "".join(            c.render() if isinstance(c, VNode) else str(c) for c in self.children        )        return f"<{self.tag} {props_str}>{inner}</{self.tag}>"  def h(tag: str, props: dict, *children: Any) -> VNode:    """创建虚拟节点，类似 React.createElement"""    return VNode(tag, props, list(children))  def Input(default_value: str = "") -> VNode:    """非受控输入框：自身持有默认值"""    return h("input", {"type": "text", "value": default_value})  def Button(label: str, on_click=None) -> VNode:    """原子组件：只负责渲染按钮"""    return h("button", {"class": "btn", "data-action": on_click or ""}, label)  def UserCard(user_name: str) -> VNode:    """分子组件：组合 Avatar + Input + Button（props 传入）"""    return h(        "div",        {"class": "user-card"},        h("span", {"class": "avatar"}, "O"),        Input(user_name),        Button("保存", "save"),    )  def Card(title: str, *children: Any) -> VNode:    """容器组件：使用 children 作为插槽"""    return h(        "div",        {"class": "card"},        h("div", {"class": "card-header"}, title),        *children,        h("div", {"class": "card-footer"}, "footer"),    )  if __name__ == "__main__":    page = h(        "main",        {"id": "app"},        Card("用户信息", UserCard("张三"), Button("取消", "cancel")),    )    print(page.render())
目的：用 60 行代码模拟了组件设计的核心机制——VNode 相当于乐高积木的“拼接口”，h 函数负责组装，Input/Button 是原子砖块，UserCard 通过 props 拼接它们，Card 则用 children 提供插槽。运行后会输出一段嵌套 HTML，直观展示组件如何逐层拼装成页面。
  1. class VNode:建立虚拟节点类，相当于定义了乐高积木的统一拼接口。每个积木都有 tag（类型）、props（接口参数）、children（凹槽内容）。
  2. def render(self) -> str:积木的“展开动作”，把自己和所有子积木渲染成 HTML 字符串。
  3. Input(default_value="")非受控组件示例：输入框自己持有默认值，不依赖外部传当前值。
  4. Button(label, on_click=None)原子组件示例：职责单一，只负责渲染一个按钮，事件通过 props（on_click）传递。
  5. UserCard(user_name)分子组件示例：通过 props 接收数据（user_name），组合多个原子组件拼成一个新积木。
  6. Card(title, *children)容器组件示例：*children 接收任意数量的子节点，就像 Card 组件的凹槽，里面插什么都行。
  7. "footer"具名插槽的模拟：Card 在底部固定渲染 footer 区，与 children 的开放区互不干扰。

常见误区

误区我之前把每个按钮的每个样式都拆成一个组件，一共拆了上百个小组件，以为这样复用性最强。结果每次用都要同时 import 五六个文件，改动时牵一发动全身。

正解拆分粒度的原则是“高内聚、低耦合”，不是越细越好。就像乐高砖块，2×4 的常用砖是好砖，但如果你把一块砖切成 8 个 1×1 的小颗粒，拼起来反而费劲。当组件细到难以独立使用、或需要大量配套代码才能跑起来的程度，就应该合并。

为何常见：初学者常把“复用”理解为“拆小”，忽略了组件之间的协作成本。每个组件都是一层封装，过多封装会让使用者被细碎 API 淹没。

误区我写组件时 props 名字经常随手起，`a1`、`flag`、`data` 到处用，反正自己看得懂。等同事来用的时候，根本不知道传什么。

正解props 就是组件的公共接口，相当于乐高砖块上凸粒的尺寸标号。命名语义化是组件可用性的底线：isLoading 让人一眼知道是加载状态，onSave 让人知道是保存回调。接口文档的“API 说明”本质上就是给每个 prop 起名字、定规范。

为何常见：在写组件初期，开发者只顾着让功能跑通，没有站在“使用该组件的人”的视角审视接口。等到组件被共享时才暴露问题。

误区受控组件更“高级”，所以我让每一个 input 都用 value + onChange 管理，结果每个字段都要写 setState，代码又长又容易出错。

正解受控与非受控各有用武之地。受控组件适合值会影响组件外部的情况（如表单联动、实时搜索），非受控组件适合值只被局部使用的场景（如提交时才读一次的输入框）。这就像乐高里既有“全手动遥控”的机构，也有“一次上弦自动弹开”的机关，乱用反而让搭建变得繁琐。

为何常见：教程强调受控组件多，初学者形成了“受控=正确”的单一认知，没理解两者的核心区别在于“谁拥有状态”。

误区我学会 HOC 后，把所有复用逻辑都包成高阶组件，一个组件套七八层 `withXxx`，结果调试时根本分不清数据从哪一层进来的。

正解HOC 模式本身没问题，但滥用会增加调试成本。HOC 层层包装会产生“包装地狱”，建议优先用组合、children 插槽解决；HOC 和 render props 只在“抽离跨组件逻辑”时使用，并且 HOC 链条保持 2 层以内。乐高设计也是如此：给砖块加镀层可以，但镀 10 层后砖块的公差就没法保证了。

为何常见：HOC 是“看起来强大”的模式，开发者容易为了用而用，忽略了它带来的调试代价和 props 命名冲突风险。

面试题

Q1. 下列哪个选项最符合“组件单一职责原则”的实践？

单选题 · mid

  • A.一个组件内同时处理数据请求、渲染和样式计算
  • B.一个组件只负责渲染头像，图片裁剪逻辑放到独立工具函数← 正确答案
  • C.一个组件包含下拉框、日期选择器和分页功能
  • D.一个组件通过 props 接收 20 个参数以适配所有场景

答案：B。单一职责原则要求组件只做一件事。B 把渲染头像作为组件职责，裁剪逻辑抽离，符合“高内聚”；A 和 C 把多个职责焊在一起，D 则接口过载。就像乐高标准件只提供固定拼接面，不会集成轮子和车窗。

Q2. 在 React 中，父组件向子组件传数据的机制是：

单选题 · easy

  • A.props 单向数据流← 正确答案
  • B.子组件直接修改父组件 state
  • C.全局变量自由访问
  • D.双向绑定自动同步

答案：A。React 数据流是单向的：父组件通过 props 传给子组件，子组件通过回调通知父组件更新。就像乐高搭积木，上层砖块的重量压下来，下层砖不会反向长高；状态变更永远是自上而下传导的。

Q3. 下列哪个场景最适合使用“具名插槽”？

单选题 · mid

  • A.Card 组件中只需要一个内容区域
  • B.Layout 组件需要同时提供 header、sidebar、footer 多个区域← 正确答案
  • C.Input 组件需要实时回传输入值
  • D.Button 组件需要改变背景颜色

答案：B。具名插槽用于容器组件需要多个开放区域的情况，Layout 需要 header/main/footer 多个凹槽，正好用多个具名插槽对应。A 用默认 children 即可；C、D 根本不涉及插槽。就像乐高车厢需要有车头、货厢、车尾多个独立插接位。

Q4. 关于受控组件的描述，正确的是：

单选题 · mid

  • A.数据存在组件自身 state 中，外部无法访问
  • B.数据由父组件通过 value 控制，变化时通过 onChange 通知父组件← 正确答案
  • C.组件永远不可修改，渲染一次后不再变化
  • D.非受控组件无法在 React 中使用

答案：B。受控组件的值由父组件 state 提供，用户输入触发 onChange 回调，父组件 setState 后回传新 value，形成闭环。它就像“手控人仔”，手（父组件）放在哪里，人仔就是什么姿势。B 是对这个闭环的精确描述。

Q5. 下列哪些属于组件设计文档应包含的内容？

多选题 · mid

  • A.组件用途和适用场景← 正确答案
  • B.props 的命名、类型、默认值说明← 正确答案
  • C.组件内部变量的实现细节
  • D.使用示例和注意事项← 正确答案

答案：ABD。组件文档是给使用者看的“乐高说明书”，应包含用途、API 说明、示例、注意事项；C 是内部实现细节，使用者不必关心。就像乐高说明书只告诉你砖块型号和拼法，不会讲解注塑机参数。

Q6. 高阶组件（HOC）的核心运作方式是：

单选题 · hard

  • A.通过继承父类来扩展组件行为
  • B.接收一个组件，返回一个包装后的新组件← 正确答案
  • C.通过修改原生 DOM 来添加功能
  • D.用 CSS 样式覆盖默认行为

答案：B。HOC 本质是“组件工厂”：入参是组件，返回值是增强后的组件，如 withLoading(Table) 返回带加载状态的 Table。它对应乐高工厂给砖块喷夜光涂层——砖块本体不变，但返回了一块带新能力的新砖。A 是继承思路，C、D 与 HOC 无关。

Q7. 在 React 中，<Card>{content}</Card> 的 content 是通过什么机制渲染的？

单选题 · easy

  • A.具名插槽
  • B.children 属性← 正确答案
  • C.render props
  • D.高阶组件

答案：B。花括号里的内容会被传为 Card 组件的 children，对应“默认插槽”机制。这就像乐高车厢的开放式货厢，车体框架不变，children 就是装进货厢的任何物品。A 是多个具名插槽的场景，C、D 是逻辑复用模式。

Q8. 关于“组合优于继承”的叙述，正确的有：

多选题 · hard

  • A.继承会暴露父类全部方法，增加耦合← 正确答案
  • B.组合通过 props 和 children 自由拼装，灵活度高← 正确答案
  • C.继承完全不可用，任何场景都不能使用
  • D.组合模式更符合“标准积木”的设计哲学← 正确答案

答案：ABD。继承使子类绑死父类全部接口，耦合高，A 正确；组合通过 props/children 拼接零件，B 正确；C 过于绝对，继承偶尔也有用武之地，但组件设计优先组合；D 道出了本质——乐高从不用继承造新砖，而用标准件拼装。

Q9. 以下哪种情况应该优先选择“非受控组件”？

单选题 · mid

  • A.输入值需要实时参与搜索请求
  • B.输入框在表单提交时才读取一次值，且内部状态不影响外部← 正确答案
  • C.输入值需要在多个组件间联动
  • D.输入值需要被路由参数同步更新

答案：B。非受控组件适合状态仅在组件内部、外部不关心每一次变化的值。B 的场景是“提交时读一次”，用 ref 取值即可，省去每个字段配 value/onChange 的繁琐。A、C、D 的状态都需要与外部同步，都应走受控方案。

Q10. 下列哪些是 props 接口设计的良好实践？

多选题 · easy

  • A.使用语义化名称如 isLoading、onConfirm← 正确答案
  • B.为可选项设置合理的默认值← 正确答案
  • C.用 prop-types 或 TypeScript 做类型校验← 正确答案
  • D.子组件直接在 props 上修改传入值

答案：ABC。A 命名语义化让使用者一看就懂，B 默认值降低使用成本，C 类型校验是“接口防呆”；D 违反单向数据流，子组件不能修改 props。前三个就像乐高的凸粒具备了标准尺寸、颜色标识和质量公差，而 D 等于把上下两块砖焊在一起，破坏了可插拔性。