当状态规模和依赖关系规模都很小的时候，手写是完全没问题，但是在中大型项目中，在缺乏系统化架构约束的情况下，中大型项目极易失控，维护成本也会急剧上升，此时可以有以下选择

  • 使用 MVC 架构

  • 使用 MVVM 思想

  • 自己写轻量级响应系统

  • 使用 Web Components

  • 使用 jQuery + 模块化

  • 使用状态机架构

  • 使用框架

从以上选项中，目前很多大厂基本都选择使用框架（自研框架或者开源框架），总结原因可能有以下几点，当然上面的方案中有些也能解决其中的一些问题，这里暂不做过多的分析。

一、人脑无法维护依赖关系

假设一个页面有：

  • 20 个状态
  • 50 个 UI 区域
  • 30 个交互行为

问题来了：

某个状态改变时：
哪些 UI 需要更新？
更新顺序是什么？
会不会影响其他状态？

手写时必须：

updateA()
updateB()
updateC()

一旦漏了一个，UI 会不一致。

框架可以通过结构化，维护复杂的依赖关系，我们只需要改数据，不需要关注依赖关系。

二、副作用失控

复杂页面会出现：

A 改变 B
B 改变 C
C 又触发 A

形成循环更新，更新代码时需要：

  • 小心顺序
  • 手动加锁
  • 加条件判断

框架可以有效控制副作用。

三、DOM 操作成本高

浏览器渲染流程：

JS → DOM → Reflow → Repaint

频繁 DOM 操作会导致：

  • 卡顿
  • 掉帧
  • 抖动

框架通过抽象层和调度机制控制 DOM 更新粒度，可以避免频繁更新 DOM。

四、状态一致性问题

例如购物车：

商品数量
总价
优惠
库存
按钮禁用状态

代码必须这样写：

updateCount()
updateTotal()
updateButton()

而使用框架，我们可能只需要一句话，比如这样

const total = computed(...)

总价可以使用计算属性算出来，不用到处写，降低了状态混乱问题的出现频率。

五、可维护性和团队协作

当项目达到：

50+ 页面
10+ 开发者

如果没有框架：

  • 每个人写法不同
  • 状态管理混乱
  • DOM 操作方式不同
  • 代码不可预测

框架可以提供：

统一模式
组件规范
生命周期规则
状态流向规则

解决工程规范问题。

六、真正核心：抽象能力

框架本质是：

把”变化的东西”抽象成规则。

比如 Vue 抽象出：

  • 响应式
  • 组件
  • 生命周期
  • 调度
  • 模板编译

这些都是：

对”变化”的抽象

框架让业务代码变成声明式，而把命令式复杂度封装起来，可以有效降低开发门槛。