这是我们前端团队 14 个人耗时 87 天,把一套用了七年的"jQuery + 命令式手工操作 DOM + 全局 $ 选择器满天飞 + 字符串拼 HTML 再 innerHTML 塞进去 + 回调式 AJAX 层层嵌套 + 事件监听绑了不解绑内存泄漏 + 完全没有组件化全是面条代码 + 状态散落在 DOM 属性和全局变量里 + Gulp 手工任务构建"的古老前端体系,整体重构到 2026 年"React 18 + 声明式组件 + Hooks 状态管理 + 虚拟 DOM 差量更新 + JSX 模板 + 单向数据流 + 组件化拆分与复用 + Context/状态库管理全局态 + Vite 秒级构建"现代前端体系的真实战役复盘。重构前,我们的页面是典型的"想更新个数字要手动 $('#x').text(),状态和 DOM 各存一份经常对不上、一个交互改下来要操作七八处 DOM、加个功能就在面条里再缠一圈、内存泄漏越跑越卡"的危局;一处状态变更要同步五六个地方的 DOM,漏一个就显示错乱。重构后,我们用声明式组件把"数据→视图"的映射交给框架、用 Hooks 把状态管理得清清楚楚、用虚拟 DOM 把手工 DOM 操作彻底消灭、用组件化把面条代码拆成可复用的积木。这 87 天里我们沉淀了 47 套工程修法、7 个 P0 事故复盘和 6 条工程哲学,本文毫无保留地分享出来。
需要先说明:前端现代化不是"把 jQuery 换成 React 这个库"这么简单——它是从"手工命令式地操作 DOM、状态散落各处"的开发,跃迁到"声明式地描述 UI、状态驱动视图自动更新"的范式更替。下面这张表,概括了我们重构前后在十个核心维度上的对比,每一行背后都是数周攻坚。
| 维度 | 重构前(jQuery 命令式) | 重构后(2026 React 声明式) |
|---|---|---|
| UI 范式 | 命令式手工操作 DOM | 声明式描述 UI |
| 视图更新 | 手动 $().text() 同步 | 状态驱动自动重渲 |
| 状态管理 | 散落 DOM 属性/全局变量 | Hooks 集中管理 |
| DOM 操作 | 直接操作易出错 | 虚拟 DOM 差量更新 |
| 代码组织 | 面条代码无组件 | 组件化拆分复用 |
| 模板 | 字符串拼 HTML | JSX 声明式模板 |
| 数据流 | 双向乱改难追踪 | 单向数据流可预测 |
| 异步 | 回调式 AJAX 嵌套 | fetch + Hooks 副作用 |
| 内存 | 监听不解绑泄漏 | 副作用自动清理 |
| 构建 | Gulp 手工任务 | Vite 秒级 HMR |
一、从命令式操作 DOM 到声明式组件:把"怎么改"交给框架
重构的第一仗,也是整场战役的思想内核,是从"命令式"转向"声明式"。jQuery 时代我们写的是命令:"找到这个元素、改它的文字、再找那个元素、加个 class、再插一段 HTML"——我们手把手地告诉浏览器每一步怎么改 DOM,状态变了就得记得手动把每一处相关的 DOM 都同步改一遍,漏一处就错乱。React 的声明式则反过来:我们只描述"在某个状态下 UI 应该长什么样",状态一变,框架自己算出 DOM 该怎么改并高效地改掉,我们再也不用碰 DOM。下面是同一个计数器,jQuery 命令式与 React 声明式的对比:
// 重构前:jQuery 命令式——手动找元素、手动改 DOM,状态和视图各存一份要手动同步
// let count = 0;
// $('#btn').on('click', function () {
// count++; // 改状态
// $('#count').text(count); // 还得记得手动同步这处 DOM
// $('#tip').text(count > 5 ? '够了' : ''); // 漏掉这处?视图就和状态对不上了
// });
// 重构后:React 声明式——只描述"状态→UI 长什么样",状态变了框架自动更新 DOM
import { useState } from "react";
function Counter() {
const [count, setCount] = useState(0); // 状态是唯一事实源
// 下面就是"在 count 这个状态下 UI 该长什么样"的声明,我们完全不碰 DOM
return (
{count}
{count > 5 && 够了} {/* 派生视图随状态自动更新,绝不会对不上 */}
);
}从命令式到声明式让我们的开发从"手动操作每一处 DOM、状态和视图各存一份要人肉同步"进化到了"只描述状态对应的 UI、视图随状态自动更新":过去改一个数据要记得把所有相关的 DOM 一处处手动改过去,漏一处、改错一处,视图就和真实状态对不上,这类"显示错乱"的 bug 防不胜防;现在状态是唯一的事实源,我们只声明"这个状态下界面长什么样",剩下的"该改哪些 DOM、怎么改"全交给 React,人为同步导致的不一致从根上消失了;代码也从"一堆操作 DOM 的步骤"变成了"一个描述 UI 的函数",可读性天差地别。这个思想转变是最难也最关键的——团队里写惯 jQuery 的同学最初总忍不住想 document.getElementById 直接改 DOM,我们反复强调:在 React 里手动碰 DOM 就是在和框架对着干。声明式的第一性原理是:人脑不擅长维护"状态变更后要同步哪些地方"这种命令式的因果链,而擅长描述"事物应该是什么样"——把"怎么改"这件容易出错的苦差事交给机器,人只负责"是什么"这件清晰的事,bug 的土壤就被铲除了一大片。
二、状态管理:用 Hooks 把散落的状态收拢成唯一事实源
第二仗,是状态管理。jQuery 时代状态无处安放:有的存在 DOM 的 data 属性里、有的塞进全局变量、有的藏在某个闭包,同一份信息往往散落好几处,改了这处忘了那处就不一致。React 的 Hooks(useState、useEffect、useMemo、useReducer 等)给了状态一个清晰的家:useState 声明组件的本地状态、useEffect 处理副作用并自动清理、useMemo 缓存昂贵计算、useReducer 管理复杂状态转移。状态成了驱动一切的唯一事实源,视图只是它的投影。下面是我们用 Hooks 管理状态与副作用的实践:
// Hooks:状态有清晰的家,副作用能自动清理,告别散落的全局变量和泄漏的监听
import { useState, useEffect, useMemo } from "react";
function SearchableList({ keyword }) {
const [items, setItems] = useState([]);
const [loading, setLoading] = useState(false);
// useEffect:处理副作用(拉数据),依赖变化才重跑,返回的函数自动清理
useEffect(() => {
let cancelled = false;
setLoading(true);
fetchItems(keyword).then((data) => {
if (!cancelled) { setItems(data); setLoading(false); } // 防竞态:已卸载就不 setState
});
return () => { cancelled = true; }; // 清理:组件卸载或 keyword 变更时取消,杜绝泄漏
}, [keyword]); // 依赖数组:只在 keyword 变时重跑
// useMemo:昂贵计算缓存,依赖不变就不重算,避免每次渲染都白跑
const sorted = useMemo(() => [...items].sort((a, b) => a.rank - b.rank), [items]);
if (loading) return 加载中…
;
return {sorted.map((i) => - {i.name}
)}
;
}Hooks 状态管理让我们的状态从"散落在 DOM 属性、全局变量、闭包里,改一处漏一处"进化到了"集中在 Hooks 里、唯一事实源、副作用自动清理":过去同一份数据存在好几个地方,同步全靠人肉记忆,经常这里改了那里没改导致界面错乱;现在 useState 给每份状态一个明确的归属,组件的视图完全由这些状态推导出来,改状态就够了、视图自动跟上;useEffect 把"拉数据、订阅、定时器"这些副作用规整起来,还强制你写清理函数——组件卸载时自动解绑监听、取消请求,过去 jQuery 时代绑了监听忘了解绑导致的内存泄漏被根治;useMemo/useReducer 则让昂贵计算和复杂状态转移都有了规范的处置方式。我们踩的典型坑是 useEffect 的依赖数组写不全导致拿到旧值,以及没写清理函数导致快速切换时的竞态和泄漏——后来靠 lint 规则强制检查依赖、靠"副作用必有清理"的评审纪律解决。状态管理的本质认知是:UI 的复杂性本质上是状态的复杂性——当状态散落各处、来源不明时,UI 必然混乱;而当你把状态收拢成清晰的、唯一的事实源,让视图成为状态的纯粹投影时,UI 就变得可预测、可推理、可维护,这是现代前端最核心的一条心法。
三、组件化与复用:把面条代码拆成可组合的积木
第三仗,是组件化。jQuery 时代没有"组件"的概念,一个页面就是一大坨 HTML 模板加一大坨操作它的 JS,逻辑和结构搅成面条,想复用一段 UI 只能复制粘贴,改一处要同步改十处复制体。React 把 UI 拆成组件:每个组件是一个自包含的单元,有自己的结构(JSX)、自己的状态和逻辑,通过 props 接收外部数据、通过组合把小组件拼成大页面。组件像乐高积木,定义一次、到处复用,改一处所有用到的地方都跟着变。下面是我们的组件拆分与复用:
// 组件化:把 UI 拆成自包含、可复用的积木,通过 props 传数据、通过组合搭页面
// 一个通用的卡片组件,定义一次到处用——再不用复制粘贴一段 HTML
function Card({ title, children, onClose }) {
return (
{title}
{onClose && }
{children} {/* children:插槽,任意内容塞进来 */}
);
}
// 复用 Card 搭出业务组件,组合而非复制——改 Card 一处,所有卡片同步变
function OrderCard({ order }) {
return (
金额:¥{order.amount}
状态:{order.status}
);
}
// 用组合把小组件拼成页面,结构清晰、各司其职
function OrderList({ orders }) {
return {orders.map((o) => 组件化让我们的代码从"一大坨面条 HTML+JS、复用靠复制粘贴"进化到了"自包含的组件积木、定义一次到处组合复用":过去一个页面是结构和逻辑搅在一起的面条,想复用一段 UI 只能复制粘贴,结果同一个卡片样式在项目里散落十几份复制体,改个圆角要改十几处还总漏;现在每个 UI 单元都是一个组件,有自己清晰的边界、props 接口和内部逻辑,Card 定义一次,订单卡、商品卡、用户卡都来组合它,改 Card 一处全站卡片同步更新;通过 children 插槽和组合,小组件像积木一样拼成复杂页面,每一层都职责单一、易读易测。我们的拆分原则是"单一职责 + 合理粒度"——一个组件只干一件事,但也别拆得过碎导致 props 层层透传(prop drilling),那种跨多层的全局状态我们用 Context 或状态库来传。组件化的本质认知是:对抗复杂度的根本武器是"分而治之 + 复用"——把一个庞大的 UI 拆成一个个有清晰边界、可独立理解和复用的组件,整体的复杂度就被切分成了可管理的小块,而组合的能力又让这些小块能搭出无限丰富的页面,这正是现代前端能承载日益复杂的产品的根基。
四、数据获取与副作用:从回调式 AJAX 到 fetch + 数据 Hooks
第四仗,是数据获取的现代化。jQuery 时代用 $.ajax 回调拉数据,一个"先拉用户再拉订单再拉详情"的流程回调套回调,错误处理散落、loading 状态手动 toggle、还经常因为快速切换导致旧请求的结果覆盖新请求(竞态)。现代前端用 fetch/axios 配合 Promise 与 async/await 把异步拉平,再用 useEffect 或专门的数据请求库(如 SWR、React Query)管理"加载中/成功/失败"状态、自动处理缓存、去重、竞态和重试。下面是我们封装的数据请求 Hook:
// 自定义 Hook:把"拉数据 + loading/error 状态 + 竞态处理"封装起来,组件里一行调用
import { useState, useEffect } from "react";
function useFetch(url) {
const [state, setState] = useState({ status: "loading", data: null, error: null });
useEffect(() => {
let cancelled = false;
setState({ status: "loading", data: null, error: null });
fetch(url)
.then((r) => { if (!r.ok) throw new Error(`HTTP ${r.status}`); return r.json(); })
.then((data) => { if (!cancelled) setState({ status: "success", data, error: null }); })
.catch((e) => { if (!cancelled) setState({ status: "error", data: null, error: e }); });
return () => { cancelled = true; }; // 切换/卸载时取消,旧请求结果不再污染新状态
}, [url]);
return state; // { status, data, error } —— 三态明确,组件按状态渲染
}
// 组件里一行搞定,loading/error/success 三态清清楚楚,不再手动 toggle
function UserPanel({ userId }) {
const { status, data, error } = useFetch(`/api/users/${userId}`);
if (status === "loading") return 加载中…
;
if (status === "error") return 出错:{error.message}
;
return {data.name}
;
}现代数据获取让我们的异步从"回调套回调、loading 手动 toggle、竞态导致旧数据覆盖新数据"进化到了"async 拉平、三态明确、竞态自动处理":过去用 $.ajax 回调拉数据,流程一长就嵌套成回调地狱,每个请求都要手动 setLoading(true/false)、手动 try-catch,还经常因为用户快速切换 tab 导致先发的慢请求后返回、覆盖了后发快请求的结果,出现"显示的是上一个用户的数据"这种诡异 bug;现在我们把数据请求封装成 useFetch 这样的自定义 Hook,loading/success/error 三态由 Hook 统一管理、组件按状态声明式渲染,清理函数里的 cancelled 标志把竞态从根上解决,切走的旧请求结果绝不会再污染当前状态;用上 React Query 这类库后,缓存、去重、后台刷新、失败重试更是开箱即用。我们的纪律是"任何异步副作用都必须处理 loading、error 和清理三件事",缺一不可。数据获取的本质认知是:前端的异步复杂性不在于"怎么发请求",而在于"怎么管理请求的生命周期和它引发的状态变化"——把加载状态、错误处理、竞态防护这些横切关注点抽进可复用的 Hook,组件就能从繁琐的异步细节里解放出来,只专注于"拿到数据后怎么展示"。
五、性能:虚拟 DOM、memo、列表 key 与代码分割
第五仗,是性能优化。有人以为用了 React 性能就自动好了,其实不然——用不好反而比 jQuery 还卡。React 的核心是虚拟 DOM:状态变化时先在内存里算出新的虚拟 DOM、和旧的做差量比对(diff),只把真正变化的部分更新到真实 DOM,避免了 jQuery 时代动辄重建整片 DOM 的开销。但要让它高效,我们得配合:用 React.memo/useMemo/useCallback 避免不必要的重渲染、给列表项稳定的 key 帮助 diff、用代码分割(lazy + Suspense)按需加载减小首屏体积。下面是我们的性能优化实践:
// 性能优化:memo 避免无谓重渲、稳定 key 帮 diff、代码分割减小首屏
import { memo, useCallback, useState, lazy, Suspense } from "react";
// React.memo:props 没变就跳过重渲——父组件刷新时子组件不白白重渲
const ExpensiveRow = memo(function ExpensiveRow({ item, onPick }) {
return onPick(item.id)}>{item.name} ;
});
function List({ items }) {
const [picked, setPicked] = useState(null);
// useCallback:回调引用稳定,否则每次渲染都生成新函数,memo 子组件还是会重渲
const onPick = useCallback((id) => setPicked(id), []);
return (
{/* key 用稳定唯一的 id,绝不用数组下标——否则增删时 diff 错乱、状态串位 */}
{items.map((it) =>
);
}
// 代码分割:重组件按需懒加载,首屏不必一次性下载全部 JS
const HeavyChart = lazy(() => import("./HeavyChart"));
function Dashboard() {
return 图表加载中…}> ;
}性能优化让我们的应用从"以为用了框架就快、实则无谓重渲染卡顿、首屏巨大"进化到了"虚拟 DOM 差量更新 + 精准跳过重渲 + 按需加载的流畅体验":虚拟 DOM 本身就免去了 jQuery 时代频繁手工重建 DOM 的开销,状态变了只更新真正变化的那一小块;但我们也踩过"父组件一刷新、底下成百上千个子组件跟着白白重渲染"的坑,用 React.memo 配合 useCallback 稳定 props 引用后,没变的子树被精准跳过,长列表的卡顿消失了;列表项的 key 我们严格用稳定唯一的业务 id 而非数组下标,杜绝了增删元素时 diff 错位、组件状态串到别的行上的诡异 bug;代码分割则把重型组件(图表、编辑器)拆成按需加载的 chunk,首屏 JS 体积大幅下降、打开速度明显变快。我们的经验是"先测量再优化"——用 React DevTools Profiler 找到真正重渲染过多的组件再针对性 memo,而不是无脑给所有组件套 memo(那反而增加比对开销)。性能的本质认知是:声明式和虚拟 DOM 帮你免去了大部分手工优化,但框架不是魔法——理解它"何时重渲染、如何 diff",在关键路径上配合它(稳定引用、稳定 key、按需加载),才能既享受声明式的开发爽快、又拿到媲美甚至超越手工优化的运行性能。
六、单向数据流:让数据流向可追踪、状态变更可预测
第六仗,是确立单向数据流。jQuery 时代数据是双向乱流的:任何代码都能随时读写任何 DOM、任何全局变量,A 模块改了 B 模块依赖的状态、B 又回头改 A,数据在哪被改的、为什么变成这样,追查起来像破案。React 推崇单向数据流:数据从父组件通过 props 向下流到子组件,子组件要改数据则通过回调向上通知父组件去改——状态永远在"拥有它的那一层"被修改,数据流向单一、清晰、可追踪。单向数据流让我们的状态管理从"任何地方都能改任何状态、数据双向乱流难追踪"进化到了"数据自上而下流、变更自下而上报、流向单一可预测":过去一个 bug 表现为"某个值莫名其妙变了",排查时要把所有可能改它的地方都翻一遍,因为谁都能改;现在状态归属明确,数据通过 props 单向往下传、子组件想改就调父组件给的回调,修改永远发生在状态的归属层,要追"这个值为什么变了"只需看它的归属组件,定位成本断崖式下降;配合 Redux/Zustand 这类状态库,全局状态的每一次变更都经过明确的 action、可被记录和回放,数据流彻底透明。我们的纪律是"状态尽量下沉到最近的公共祖先、绝不在子组件里偷偷修改 props"。单向数据流的本质认知是:可维护性的核心是可预测性,而可预测性来自约束——主动放弃"任何地方都能改任何状态"这种看似自由实则混乱的能力,换来"数据只能按规定路径流动"的秩序,系统才从一团乱麻的因果网,变成一条条清晰可循的数据管道,这是大型前端应用能被多人长期维护的纪律基础。
七、JSX 与组件设计:逻辑与视图内聚而非强行分离
第七仗,是接受 JSX 并用好它。很多从"HTML/CSS/JS 三件分离"传统过来的人,初见 JSX 把标签写进 JS 里很不适应,觉得"违背了关注点分离"。但我们逐渐理解:真正的关注点分离不是"按技术(HTML/JS)分文件",而是"按功能(一个组件)内聚"——一个按钮的结构、样式逻辑和交互行为本就是一回事,强行拆到三个文件里反而割裂。JSX 让一个组件的视图和驱动它的逻辑内聚在一起,配合条件渲染、列表渲染、组件抽象,表达力远胜字符串模板。JSX 与组件化设计让我们的代码组织从"按 HTML/CSS/JS 技术维度切成三摊、改一个功能要在三个文件间跳"进化到了"按组件功能内聚、一个文件看懂一个 UI 单元的全部":过去改一个表单要在 html 模板、css 文件、js 逻辑三处来回跳,还要靠 id/class 这种脆弱的字符串把它们对应起来,改个结构 js 里的选择器就失效;现在一个组件就是一个自洽的单元,结构(JSX)、逻辑(Hooks)、甚至局部样式都内聚在一起,改它只需看它一个文件,删它就是删一个文件不留垃圾;JSX 的条件渲染和列表渲染又比字符串拼 HTML 安全得多——再不会因为拼接出错导致 XSS 或标签错乱。我们的设计原则是"组件即关注点"——一个组件封装一个完整的功能关注点,而不是按技术分层。JSX 的本质认知是:关注点分离的正确粒度是"功能"而非"技术种类"——把本属于同一个功能的结构、行为、样式人为拆散到不同文件,制造的是"形式上的整洁"和"实质上的割裂";让它们围绕组件内聚,才是真正符合人类理解和维护方式的组织。
八、迁移策略:微前端 / 渐进式挂载,新老共存不停业
第八仗,是迁移本身。把一个七年的 jQuery 大站一次性重写成 React 是巨大的风险,业务一天都停不起。我们用渐进式策略:不追求一次性全量重写,而是让 React 和老 jQuery 代码在同一个页面里共存——把页面切成区块,新功能、新模块直接用 React 写,并通过把 React 应用挂载到老页面的某个容器节点上(ReactDOM 挂到指定 DOM)实现局部接管;老模块则继续跑,等有迭代需求时再逐块替换成 React。对于大型站点,我们还用微前端的思路把不同技术栈的应用编排在一起。渐进式迁移让我们在业务持续运营的前提下,平滑地把整个站点从 jQuery 迁到了 React:不搞推倒重写那种高风险的大爆炸,而是让新老共存——React 应用挂载到老页面的局部容器里接管一块、老 jQuery 代码继续跑剩下的,用户无感、业务不停;新需求一律用 React 实现,顺手把碰到的老模块逐块替换,迁移和业务迭代同步推进而非相互阻塞;以页面区块为单位推进,每替换一块就充分测试一块,风险被切分到最小。最关键的纪律是"绝不为了迁移而停下业务做大重写",而是把迁移化整为零、混进日常迭代里持续推进。前端迁移的本质智慧和所有大型迁移一样:不是推倒重来,而是在系统持续运行中、让新老技术栈在同一页面里和平共存,以模块、以区块为单位,一块一块地把命令式的旧世界,稳稳地搬进声明式的新世界。
九、7 个 P0 事故复盘
7 事故:(1) 列表项 key 用数组下标,增删时组件状态串到别行、输入框内容错位,key 一律用稳定业务 id;(2) useEffect 漏写清理函数,快速切换页面旧请求结果覆盖新数据 + 监听泄漏,副作用必写清理;(3) useEffect 依赖数组漏项,闭包拿到旧 state 逻辑诡异,上 lint 强制检查依赖;(4) 在 React 里又手动 document 改 DOM 和框架打架,渲染错乱,严禁绕过框架碰 DOM;(5) 父组件刷新带动上千子组件无谓重渲卡死,memo + useCallback 精准跳过;(6) 直接 mutate state(push 数组/改对象属性)视图不更新,一律返回新引用不可变更新;(7) dangerouslySetInnerHTML 塞未净化的用户内容导致 XSS,富文本一律先净化。每个 P0 都做 5-Why 复盘,固化成 lint 规则或评审清单,确保同类问题不再复发。
十、前端工程师的 6 条工程哲学
6 哲学:(1) 声明式而非命令式——描述 UI 该是什么样,别手动指挥每一步怎么改 DOM;(2) 状态是唯一事实源——视图是状态的投影,改状态而非改 DOM;(3) 单向数据流——数据向下流、变更向上报,用约束换可预测;(4) 组件即关注点——按功能内聚拆组件,而非按技术分层;(5) 不可变更新——永远返回新引用,绝不原地 mutate;(6) 迁移要渐进——新老共存不停业,以区块为单位逐步替换。这 6 条哲学,是我们用 7 个 P0 事故和 87 天攻坚换来的集体共识。它们共同指向一个认知:前端现代化的价值不在于"换了 React 这个库"这个动作本身,而在于把"UI 的正确性"从依赖开发手动同步每一处 DOM,前移成了由"状态驱动、框架自动同步"的范式保障——会用现代框架的团队,是在用声明式和单向数据流把一整类"视图与状态不一致"的 bug 从结构上消除,而不只是在事后修补它们。
十一、重构收益的量化:7 个关键数字
7 数字:(1) "视图与状态不一致"类 bug:频发 → 声明式 + 单一事实源后大幅归零;(2) 内存占用与长时间运行卡顿:监听泄漏越跑越卡 → 副作用自动清理后稳定;(3) UI 复用率:复制粘贴一堆副本 → 组件化定义一次到处用;(4) 构建/热更新速度:Gulp 手工任务慢 → Vite 秒级 HMR;(5) 新功能开发速度:面条里缠新逻辑 → 组合现成组件,显著加快;(6) 首屏加载体积:一次性全量 JS → 代码分割按需加载,明显下降;(7) 新人上手周期:啃面条猜数据流 → 看组件树和状态即懂,周期大幅缩短。这些数字背后,是 87 天里 14 个人无数次的组件拆分、状态梳理、性能调优和渐进迁移,但每一个都实打实地转化成了稳定性和开发效率的提升。当我们把这份数据汇报给管理层时,最有说服力的不是任何 React 名词,而是"视图错乱类 bug 几乎绝迹、加新功能从在面条里冒险缠绕变成搭积木一样拼装"这两条。
十二、留给后来者的最后一句话
87 天的前端现代化战役,我们走过的不只是一条从 jQuery 到 React、从命令式到声明式、从面条代码到组件化、从手工 DOM 到虚拟 DOM 的技术升级路,更是一次从"手动同步每一处 DOM、状态散落各处难追踪"到"状态驱动视图自动更新、数据流清晰可预测"的开发范式跃迁。当改一个状态界面所有相关处都自动正确更新、当长时间运行的页面不再越跑越卡、当一个精心设计的组件在十几个页面里被复用而改一处全站生效、当新人看着组件树和数据流就理解了整个应用而不必啃面条、当我们第一次敢于大胆重构核心交互而不再担心碰坏别处的那一刻,真正点燃我们的,不是 React 这个库本身,而是"UI 的正确性终于从依赖人手动同步的细心,变成了由状态驱动、框架强制保障"的踏实与笃定。前端现代化没有银弹,关键是理解声明式、状态管理、组件化、单向数据流、性能优化各自解决什么问题,然后从声明式思维起步、用渐进迁移落地——尤其要克制"忍不住又去手动操作 DOM"的旧习惯,因为每一次绕过框架直接碰 DOM,都是在亲手破坏你刚建立的声明式秩序。愿每一位还在 jQuery 面条里靠手动同步 DOM 和祈祷过日子的同行,都能早日让自己的界面被状态优雅地驱动起来。共勉,后会有期。
—— 别看了 · 2026