3.数据管理场景题
查看飞书原文 ↗2,790 字符
开场话术
“这个功能涉及大量数据的增删改查，数据流设计是核心挑战。”
“我们当时建立了一套标准化的数据规范，确保数据的一致性和可预测性。”
标准答题示例
我当时负责开发公司内部的 CRM 系统，要管理客户、订单、产品等多实体数据，结构复杂，关系紧密。
在数据建模上，我采用了扁平化的 normalized 结构，把每个实体单独维护，彼此之间通过 ID 引用。为了简化操作，还封装了统一的 Entity Adapter，配合 TypeScript 的强类型校验，让所有增删改查都更安全可靠。
在状态管理层，用的是 Redux Toolkit 搭配 RTK Query：
•
用 RTK Query 自动处理数据缓存与同步；
•
对于表单提交类操作，加入了乐观更新机制，失败后能自动回滚；
•
针对列表类页面，我们实现了数据预取策略，提前加载用户可能访问的数据页。
数据一致性方面，做了三层防线：
•
用 Immer 保证状态不可变；
•
加了运行时和类型层的双重数据校验；
•
还实现了离线模式，支持数据断网操作、重连自动同步。
性能方面，我们也做了系统优化：
•
用 useMemo 缓存计算结果，减少重复计算；
•
大数据列表使用虚拟滚动，实测支持万级数据不卡顿；
•
页面交互还配合了分页与搜索策略，最大程度减轻接口压力。
目前这套数据方案已经稳定支撑了 10w+ 客户的数据管理，使用体验和性能都很稳定。
常见追问及应对
面试官： "Normalized 数据结构具体是怎么设计的？"
这个部分我们是参考了数据库的范式拆解方式，把每个实体拆成独立模块，只通过 ID 引用，避免了冗余和同步问题。
传统写法中，订单里可能会嵌套整个客户对象和产品列表，这种方式在多处复用客户信息时容易出现数据不一致。而我们采用 normalized 结构之后：
interface Order {
id: string;
customerId: string; // 引用
productIds: string[]; // 引用
amount: number;
status: OrderStatus;
}
所有数据都统一存放在 state.orders.entities、state.customers.entities 这种扁平结构里。
我们还借助了 @reduxjs/toolkit 提供的 createEntityAdapter 自动生成常见的增删改操作，大大提升了开发效率：
const customersAdapter = createEntityAdapter<Customer>();
const customersSlice = createSlice({
name: 'customers',
initialState: customersAdapter.getInitialState(),
reducers: {
customerAdded: customersAdapter.addOne,
customerUpdated: customersAdapter.updateOne,
}
});
这样做的好处是，任何更新操作只改一个地方，比如更新客户信息后，所有使用这个客户数据的订单视图都能自动响应更新。
面试官： "大量数据的性能问题是怎么解决的？"
这方面我们做得比较系统，主要是从「渲染优化 + 数据加载策略 + 计算缓存」三个角度入手。
首先是虚拟滚动。像客户列表这类大数据页面，我们没有一次性渲染所有数据，而是只渲染用户当前视口可见的那部分，极大降低了 DOM 数量，提高了响应速度。
然后是分页和预加载。我们用 useInfiniteQuery 实现了滚动加载，每次加载 50 条，滚动到底部自动触发 fetchNextPage，用户体验几乎无感。
对于一些统计型视图，我们还做了计算缓存。比如用户消费统计信息，用 useMemo 只在相关订单数据变更时重新计算，有效避免了无意义的重复计算。
最后还有索引优化。比如我们对客户名字、邮箱等字段做了索引，在本地搜索时性能能稳定在 10ms 以内。
🔍 "数据一致性是怎么保证的？"
我会把数据一致性分为四个层级来做保障：
1.
类型系统保障：我用 TypeScript 明确定义每个数据结构的字段、类型和枚举值，开发阶段就能规避很多问题；
2.
运行时校验：用 Zod 做 API 响应数据的 schema 校验，确保服务端传回来的数据也符合前端预期；
3.
状态不可变性：所有状态更新都通过 Immer 自动转化为不可变操作，防止数据被意外篡改；
4.
操作回滚机制：比如更新客户信息时，我会先做乐观更新，失败后再根据原始快照进行自动回滚。
同时我还做了对「关联数据一致性」的约束。比如要删除客户之前，我们会校验是否存在未完成订单，如果有则阻止操作，并提示用户。
🔍 "离线模式是怎么实现的？"
这个我们是用 IndexedDB + 操作队列 结合实现的。
所有的增删改操作，如果发现用户是离线状态，就会被推入一个离线队列里。我们会监听 window.online 事件，网络恢复时自动批量同步。
每一条离线操作我们会记录操作类型、目标实体、数据内容、重试次数等字段，保证可以有序恢复。同步失败超过 3 次的操作会被标记为「异常项」，进入手动审核流程。
为了解决同步冲突，我们引入了简单的「最后更新时间优先」策略，同时保留了部分字段的本地合并逻辑，比如用户的自定义标签、备注等，避免重要信息丢失。
最终这套方案在弱网环境下也能保障数据可用，实际测试下同步成功率在 99.5% 以上。
💡 整体答题策略
1.
画出数据流图：能用图解形式说明数据从接口 → store → UI 的完整流程；
2.
突出治理体系：不止是会用工具，更要讲出你如何“规范”数据；
3.
补充边界场景：比如离线、冲突、权限、批量操作这些 edge case；
4.
最好有实际数据：比如操作数据量、接口返回大小、列表最大容量等，增加说服力。