← 返回思维链目录
前端架构思维链
看到组件耦合、状态混乱、性能差,顺藤摸瓜找到架构根因
1. 组件耦合:改一处崩一片
现象
改个按钮文案,结果其他页面也崩了;组件不敢动
本质:
组件之间耦合度高 —— 直接依赖对方的内部实现或共享状态。改一个影响了别人。好的架构是"高内聚低耦合",组件内部变化不影响外部。
🌊 顺藤摸瓜
① 耦合表现
①
props 层层透传
(A→B→C→D 传 5 层,中间组件不关心);②
子组件直接改父状态
;③
兄弟组件共享变量
;④
依赖另一个组件的内部结构
props 透传
直接改父
兄弟共享
② 怎么解耦
①
provide/inject
或
Context
(跨层传递不透传);②
状态管理
(Pinia/Redux,共享状态集中管);③
事件通信
(发布订阅,兄弟解耦);④
组件接口稳定
(props 定义清晰,内部变化不外泄)
provide/inject
Pinia/Redux
事件总线
稳定接口
③ 判断标准
怎么判断耦合度? → 删掉这个组件,影响几个? → 只影响直接使用者 = 低耦合;一堆都崩 = 高耦合 →
"改一处影响多少处"
是黄金标准
影响范围
单一职责
高内聚低耦合
2. 状态混乱:什么时候用全局 store
现象
到处都是状态,不知道放哪;多个组件要同步同一份数据
本质:
状态分两种 ——
局部状态
(组件内部用,不用共享)放组件内;
共享状态
(多个组件要读写)放全局 store。判断标准是"这个状态几个组件用"。
🌊 顺藤摸瓜
① 状态分类
组件局部状态
(表单输入、展开折叠)→ ref/useState;
跨组件共享
(用户信息、购物车)→ store;
服务端数据
(接口返回)→ React Query / VueUse / 直接管理
局部状态
共享状态
服务端数据
② 别滥用全局
不是所有状态都要进 store →
能局部就局部
(组件内自己管)→ 全局只放真正共享的 → 滥用全局 = 全局变量灾难
能局部就局部
全局只放共享
别滥用
③ Pinia/Redux 选型
Pinia
(Vue):去掉了 mutation,TS 支持好,简单 →
Redux Toolkit
(React):成熟生态,中间件丰富 → 核心都是"集中管理共享状态 + 单一数据源 + 可预测变化"
Pinia
Redux Toolkit
单一数据源
可预测
原则:
能局部就局部,真正共享的才进 store。服务端数据(接口返回)用专门的库(React Query),别和 UI 状态混一起。
3. 性能差:页面卡、渲染慢
现象
页面卡顿、切换慢、输入延迟
本质:
前端性能问题大多两类:①
渲染太多
(DOM 多、组件多);②
计算太多
(JS 阻塞主线程)。先定位是渲染卡还是 JS 卡。
🌊 顺藤摸瓜
① DOM 太多
DOM 节点多 → Layout/Paint 慢 →
虚拟滚动
(只渲染可视区)/
懒加载
(IntersectionObserver)/
分页
虚拟滚动
懒加载
分页
② 不必要的渲染
父更新导致所有子组件重渲染 →
memo/useMemo
(React)/
computed
(Vue)→
v-once
(只渲染一次)→ 拆细组件减少影响范围
memo/useMemo
computed
v-once
组件拆细
③ JS 阻塞
大计算阻塞主线程 →
Web Worker
(移到子线程)→
requestIdleCallback
(空闲时算)→
分片处理
(大数据分批)
Web Worker
requestIdleCallback
分片处理
④ 首屏慢
首屏白屏久 →
路由懒加载
(动态 import)/
代码分割
/
骨架屏
/
关键请求并行
/
预加载
路由懒加载
代码分割
骨架屏
请求并行
先量化:
Lighthouse / Performance 火焰图找瓶颈,再针对性优化。
渲染卡查 DOM/重渲染,JS 卡查长任务。
4. 组件复用:为什么写不出通用组件
现象
每个项目都在写类似的表格、表单、弹窗,复用不了
本质:
通用组件的核心是
"变化与不变分离"
—— 不变的(布局/交互/样式)封装在组件里,变化的(数据/行为)通过 props/slots/渲染函数暴露给外部。
🌊 顺藤摸瓜
① 不变 vs 变化
通用表格:不变的是"表格结构/分页/排序/虚拟滚动";变化的是"列配置/数据源/操作按钮" → 变化的通过
props + slots
暴露
变化与不变分离
props 配置
slots 插槽
② 配置 vs 代码
配置驱动
(JSON 描述列)适合标准化场景 → 但太灵活的用
组合模式
(基础组件 + 包装)→ 别让 props 变成"配置地狱"
配置驱动
组合模式
避免 props 地狱
③ 设计原则
①
单一职责
(一个组件干一件事);②
接口稳定
(props 变化向后兼容);③
合理的默认值
(开箱即用);④
可组合
(小组件拼成大组件)
单一职责
接口稳定
默认值
可组合
总结
现象
本质
第一反应
改一处崩一片
组件耦合度高
状态管理/provide-inject/稳定接口
状态混乱
局部 vs 共享没分清
能局部就局部,共享才进 store
页面卡
渲染多或 JS 阻塞
虚拟滚动/memo/Web Worker
复用不了
变化与不变没分离
props/slots 暴露变化,封装不变
本质:
前端架构的核心是
"管理复杂度"
—— 用分层(数据/逻辑/视图)、解耦(高内聚低耦合)、复用(变化分离)来对抗复杂度。
衡量标准:"改一处影响多少处"。