这篇文章整理了我在备考过程中归纳出的 6 个前端思维模型。每个模型都有一个“触发信号”——当你在题目里看到这个信号，就知道该用哪个模型了。

再看模型一，数据分组 → 先想 Map。不要想嵌套循环

触发信号题目出现“按 X 分组”、 “统计每个 X 的 Y”、 “多维度聚合”。使用者痛点手写嵌套循环代码难读、性能不佳、调试时容易出错。

为什么 Map 比嵌套循环好

遇到“按部门和月份统计用车金额”这类需求。第一反应往往是写嵌套 reduce——外层按部门分，内层再按月份分。这样写能跑，但有两个问题：

• 代码难读，维护成本高。
• 查询时还要嵌套访问 result导致 O 的遍历成本。老实说，

更清晰的思路是：把多维 key 拍平成复合字符串。建一张 Map，查询时 O 直接拿。

// 环境：浏览器 / Node.js
// 场景：按部门 × 月份聚合用车金额
const records =;// ✅ 复合 key + Map：结构清晰，查询 O
function groupByDeptAndMonth {
const map = new Map;for {
const key = `${record.dept}|${record.month}`;// 复合 key
const current = map.get?，0;map.set，}
return map;}
const result = groupByDeptAndMonth;console.log);// 1500
console.log);// 500

这个模型的延伸

复合 key 不只适用于两个维度，三个维度一样有效：${dept}|${month}|${project}。不过，分隔符选一个不会出现在值里的字符即可。| 是常见选择。

当维度更复杂、需要频繁更新或删除时可以考虑嵌套 Map（Map)——但要警惕过度设计，大多数聚合场景用扁平 Map 就够了。

从模型二来看，状态机 → 用数据表替代 if/else

触发信号题目出现“不同状态下不同角色有不同权限/行为”、 “状态流转”。使用者痛点if/else 嵌套炸裂、业务变更时改动散落多处、容易遗漏分支导致安全漏洞。

条件爆炸的根源

// 环境：浏览器
// 场景：❌ if/else 地狱，每新增一个状态或角色都要改多处
function getActions {
if {
if return;怎么说呢，if return;return，}
if {
if return;return，}
}

三个状态 × 三个角色 = N 种组合，代码已经开始难以维护。再加到五个状态 × 五个角色，就是 N² 种组合散落在代码里。

把矩阵写成数据表

// 环境：浏览器
// 场景：✅ 状态机表格，新增状态或角色只需修改数据，不改逻辑
const ACTION_TABLE = {
pending: {
manager:。employee:,finance:,},approved: {
manager:,employee:,finance:,},rejected: {
manager:,employee:,finance:,};function getActions {
return ACTION_TABLE?.，?，}
function canPerform {
return getActions.includes;}
console.log);//
console.log);// true

新增一个状态？说起来， 在表格里加一行。新增一个角色？ 在每个状态里加一列。逻辑代码永远不需要动，

This approach follows “data‑driven” principle—let data absorb change while logic stays stable. The more branching conditions you have。bigger payoff.

从模型三来看，跨 render 的可变值 → useRef，而不是 useState

触发信号: “取消上一个请求”、 “停止轮询”、 “计时器 id”、 “上一次的值”。使用者痛点: 用 useState 保存不需要渲染的数据会导致不必要的重渲染、内存泄漏还有 UI 卡顿。

A simple decision rule

• If yes →
• If no →

示例的观点是。轮询实现，用 useRef 保存 timer id

// 环境：React
// 场景：轮询实现，用 useRef 保存 timer id
function usePolling {
const timerRef = useRef;怎么说呢，// 不需要渲染 → useRef
const = useState;// 数据变化需要 UI 更新
const start = useCallback => {
if clearInterval;timerRef.current = setInterval => {
const result = await fetchFn;setData，},interval);},)，const stop = useCallback => {
clearInterval;timerRef.current = null;},)，useEffect => {
start;return stop，// 卸载时停止轮询
},);return { data,stop };其实，}

The or common use‑case of useRef – storing previous value

// 环境：React
// 场景：保存上一次请求的 AbortController。实现取消上一次请求
function useSearchWithCancel {
const abortRef = useRef;// 保存 AbortController，不触发渲染
const = useState;useEffect => {
if return;abortRef.current?.abort，话说回来，// 主动取消上一次未完成请求
const controller = new AbortController;abortRef.current = controller;fetch
.n)
.n
.catch(err => {
if console.error;})，return => controller.abort;// 清理函数保证组件卸载时安全
},);其实，return results;}

模型四这方面，异步副作用 → cleanup 函数是你的安全网

触发信号："轮询"、"防抖"、"WebSocket订阅"、"事件监听" 使用者痛点："忘记清理副作用导致内存泄漏、页面卸载后仍然执行 setState 报错"

The symmetry principle

// 示例：对称性的 cleanup
useEffect => {
const timer = setInterval;// 启动定时器
return => clearInterval;// cleanup 停止定时器
},);useEffect => {
window.addEventListener;// 启动监听
return => window.removeEventListener;// 清理监听
},)，useEffect => {
const ws = new WebSocket;// 启动 WebSocket
ws.onmessage = handleMessage;return => ws.close;// cleanup →关闭连接
},);

A frequent interview pitfall – debounce cleanup

// 场景：搜索框防抖，cleanup 清除未触发的 timer
function SearchBox {
const = useState;useEffect => {
if return;const timer = setTimeout => onSearch,500);return => clearTimeout;// query 改变或组件卸载都要清除旧 timer
},);return (
 setQuery}
placeholder="搜索…"
/>
)，}

If you forget cleanup step,React will warn about setting state on an unmounted component and may cause memory leaks.

模型五的观点是。批量异步 → Promise.all vs Promise.allSettled

触发信号："批量操作"、"即使部分失败也继续"、"需要所有都成功" 使用者痛点："不知道该用 all还是 allSettled 导致错误处理混乱、异常被吞掉"

A single question decides which API to pick

a. 部分失败也要收集结果

// 批量审批订单，允许部分失败并收集每条结果
async function batchApprove {
const tasks = orderIds.map(id =>
approveOrder
.n => )
.catch)
);const results = await Promise.allSettled;const succeeded = results.filter.map;const failed = results.filter.map;return { succeeded,failed };}

b. 任意一步失败都必须整体回滚

// 页面初始化，需要同时拿到使用者信息、权限列表和配置项；任意一个失败页面无法正常渲染。async function initPage {
try {
const = await Promise.all();return { user,permissions,config };
} catch {
showErrorPage;不过，}
}

Easily missed detail

The objects returned by : success 👉 }<\/code>,failure 👉 }<\/code>. Mixing up / is a common bug.

再看模型六。递归组件 → 聚焦关注点分离

触发信号："树形结构"、"嵌套列表"、"组织架构" 使用者痛点："递归组件状态散落导致展开/折叠失控、渲染性能急剧下降"

The two decisions before writing a recursive component

1. The expand/collapse state—where does it live? In parent or inside each node?
2. The rendering of leaf vs non‑leaf nodes—should y be split?按理说，
\end{ol}

A robust pattern is to lift expand state to parent using a 。letting each node become a pure presenter.

// 环境：React
// 场景：首页展示部门组织架构树；展开状态集中管理
const deptTree = },{ id:'dept_01_02',name:'Backend'。children: },]
},{ id:'dept_02',name:'Sales',children: },]
},];function DeptTree {
const = useState);const toggle=useCallback(id=>{
setExpandedIds(prev=>{
const next=new Set;next.has，老实说，next.delete:next.add;按理说，return next;})，},);const expandAll==>{
const allIds=getAllIds;setExpandedIds);}，return (

全部展开
setExpandedIds)}>全部折叠
{data.map(node=>

)}

);}
// Pure recursive node – no internal state.
function DeptNode{
const isExpanded=expandedIds.has;const hasChildren=node.children.length>0;return (


hasChildren && onToggle}>
{hasChildren && {isExpanded?按理说，'▼':'▶'}}
{node.name}

{isExpanded && hasChildren && (

{node.children.map(child=>

)}

}

);}
// Helper – collect every node id recursively.
function getAllIds{
let ids=;for{
ids.push;if ids=ids.concat);说起来，}
return ids;}

The performance tip you shouldn’t ignore

• Add

六个模型的触发信号汇总

"按 X 分组"/ "统计每个 X 的 Y"模型一 ：复合 key + Map​

"不同状态 × 不同角色 的 权限/行为"模型二 ：状态机数据表​

"取消"/ "停止"/ "计时器 ID"/ "上一次请求"模型三 ：useRef 保存可变值​

"轮询"/ "防抖"/ "WebSocket"/ "事件监听"模型四 ：cleanup 对称原则​

"批量操作"/ "允许部分失败"模型五 ：Promise.allSettled vs Promise.all​

"树形结构"/ "嵌套列表"/ "组织架构"模型六 ：状态提高 +递归组件​ ​​