标准答案
- 先说明页面业务目标和核心复杂度，例如表格筛选、权限操作、实时数据、复杂表单或多团队协作。
- 再讲状态分层：服务端数据、本地 UI 状态、URL 状态、跨页面状态分别放在哪里。
- 组件结构要说明容器层、业务组件、展示组件和自定义 Hook 的职责边界。
- 数据请求、缓存、错误态、空态、提交态和重试机制要能形成闭环。
- 最后讲性能、测试、监控和后续演进，体现取舍依据和风险控制。
题目解析
这道题考表达结构。复杂页面不是靠“用了 Redux、React Query、Table 组件”就能说明白。
好的回答应该让别人听出你为什么这样拆、解决了什么问题、牺牲了什么、怎么验证效果。
可以用一个真实页面举例，从用户操作路径往回解释架构，而不是从技术栈往下堆名词。
代码示例
可以按这样的结构组织回答，确保架构取舍有上下文。
Text
1. 页面目标：谁使用，完成什么任务
2. 复杂来源：数据、权限、表单、性能或协作
3. 状态分层：服务端状态、URL 状态、本地状态、全局状态
4. 组件边界：页面容器、业务组件、展示组件、hooks
5. 风险控制：错误态、测试、监控、回滚和后续演进常见误区
- 只背技术名词，不说明业务问题和取舍原因。
- 把所有复杂度都归结为状态管理，没有讲数据请求、错误、权限和性能。
- 没有讲验证方式，听起来像事后包装而不是实际做过的架构设计。