主题
React 高级专题
children、render props 和复合组件分别解决什么问题？
这道题考察的不只是 API 记忆，而是能否解释机制、边界、工程取舍和线上风险。
面试官想考什么
- 你能否先给出明确结论？ 考察是否理解题目的核心问题，而不是只罗列术语。
- 你能否解释内部机制和关键链路？ 考察能否把框架行为落到运行时、网络、浏览器或构建过程。
- 你能否说明适用边界和代价？ 考察技术选型、风险识别和长期维护意识。
- 你能否讲清生产落地？ 考察测试、监控、降级、回滚和问题定位能力。
一句话回答
text
它们都是组合能力；`children` 适合结构插槽，render props 适合把内部状态以行为方式暴露，复合组件适合表达有上下文约束的组件族。面试回答详解
这道题的重点不是背诵一个孤立结论，而是把概念、机制、边界和工程实践串起来。面试现场可以先给出上面的核心回答，再按以下层次展开。
1. 先明确问题边界
它们都是组合能力；children 适合结构插槽，render props 适合把内部状态以行为方式暴露，复合组件适合表达有上下文约束的组件族。
需要先区分它解决的具体问题，以及它不负责解决的部分。高级回答要避免把语法、运行时机制、框架约定和业务架构混成一个概念。
2. 解释核心机制
Tabs、Select、Menu 等组件可通过 Context 共享注册信息；子组件 API 要保持语义稳定，避免把内部 DOM 结构暴露成隐式契约。
text
输入或用户操作 -> 框架/运行时处理 -> 状态、数据或资源更新 -> 可观察结果如果题目涉及 React，要说明渲染、更新、提交、状态或组件边界；如果题目涉及 Next.js，要说明服务端、客户端、边缘运行时、路由、数据获取和缓存边界；如果题目涉及性能，要把用户指标和具体链路对应起来。
3. 讲清边界和相近概念
- 概念边界：说明它和相邻 API、渲染模式、缓存层或架构方案的区别。
- 状态与数据：区分局部 UI 状态、服务端数据、缓存数据和持久化数据。
- 运行位置：明确代码是在浏览器、Node.js、Edge 还是构建阶段执行。
- 失败模式：列出竞态、过期数据、重复执行、hydration mismatch、权限绕过或性能退化等风险。
4. 讲工程取舍
render props 灵活但嵌套可能变深；Context 方便但会扩大更新范围；复合组件要补齐错误用法提示和类型约束。
- 适合场景：边界清晰、收益可测量、团队已有对应基础设施的场景。
- 不适合场景：数据规模、实时性、安全约束或运行时环境不满足时，不要强行使用。
- 评估维度：复杂度、性能、可测试性、可观测性、兼容性和迁移成本。
- 验证方式：用类型检查、单元测试、E2E、Profiler、Network、RUM 或服务端 trace 证明判断。
5. 生产落地与风险控制
如何让复合组件支持 TypeScript 类型推导、可访问性和服务端渲染？
落地时至少要补齐输入校验、错误态、空态、超时、取消、重试、降级和回滚。涉及用户数据时，还要检查鉴权、授权、租户隔离、敏感信息脱敏和缓存隔离。涉及性能时，要同时看实验室数据和真实用户分位数，避免只优化一个孤立指标。
可直接背诵的 30 秒回答
text
这道题的核心是它们都是组合能力；`children` 适合结构插槽，render props 适合把内部状态以行为方式暴露，复合组件适合表达有上下文约束的组件族。实现上我会先确认它在整条链路中的位置，再解释Tabs、Select、Menu 等组件可通过 Context 共享注册信息；子组件 API 要保持语义稳定，避免把内部 DOM 结构暴露成隐式契约。选型时不会只看“能不能实现”，还会结合数据规模、性能、可测试性、运行时和团队维护成本判断边界。生产环境要补上如何让复合组件支持 TypeScript 类型推导、可访问性和服务端渲染？，并通过测试、监控和指标验证方案确实有效。扩展知识
面试回答框架
text
定义问题 -> 运行机制 -> 概念边界 -> 工程取舍 -> 风险控制 -> 指标验证常见答题误区
- 只背 API 名称，不说它解决的真实问题。
- 只讲优点，不讲缓存、性能、安全、兼容性或维护成本。
- 把服务端、客户端、构建时和边缘运行时的行为混为一谈。
- 说“可以优化”，但没有说明基线、工具、指标和回滚方案。
面试官追问链
追问一：如果线上出现异常，你会怎么排查？
- 考察点：是否具备从现象定位到根因的能力。
- 回答方向：先记录版本、路由、用户上下文和复现条件，再根据题目检查控制台、Network、React Profiler、Performance、服务端日志、trace 和监控，逐层缩小到输入、状态、渲染、缓存、网络或部署。
追问二：这个方案有什么缺点，什么时候不用？
- 考察点：是否理解方案边界而不是绝对化背答案。
- 回答方向：从复杂度、性能、可测试性、兼容性、安全、团队理解成本和迁移成本说明；如果约束不满足，选择更简单或更靠近数据源的方案。
追问三：如果数据量、访问量或团队规模继续增长，你会如何调整？
- 考察点：是否能从 demo 方案升级到生产架构。
- 回答方向：缩小边界、分层、缓存、分页、虚拟化、异步化、限流、降级和服务端聚合，并用容量、延迟、错误率和业务指标验证收益。