今年前端圈子的信息量，说实话比往年都大。各种新工具、新写法、新框架版本层出不穷，但真正落到日常项目里的，其实还是那些被反复验证过的核心知识。我整理了 2026 年这一版 web 前端知识点总结，这是第二篇。上一篇更多是 HTML、CSS、JavaScript 基础补全，这一篇我会把重心放在工程化、框架实战、TypeScript 业务落地、性能优化和线上稳定性上。如果你已经能独立写页面，但对构建链路怎么选、状态管理怎么设计、类型怎么运用、线上问题怎么排查还缺一套系统性打法，这篇笔记应该能帮你省不少时间。
1. 工程化底座：构建链路与项目组织
1.1 为什么 2026 年我仍然首推 Vite 构建方案
很多新人对构建工具的印象停留在“配置复杂的 webpack”，但这两年实际开发里，Vite 已经逐渐变成默认选项。我接触的新项目，十个里有八个直接用 Vite 起步，剩下两个要么是维护老项目，要么是有特殊的兼容需求。
Vite 之所以能站稳脚跟，核心在于它把开发体验和构建产物分开处理了。开发时依赖原生 ES Module 按需编译，启动一个中型项目的速度通常在几百毫秒到两秒左右，根本不用像 webpack 那样先打包整个应用。等真正要发布，底层再用 Rollup 做生产构建，既保证了编译速度，也能做充分的静态分析和 tree shaking。
这里放一段我在中后台项目里常用的 Vite 配置，很多人拿官方模板就跑，结果连别名都没配，后面改路径改到崩溃。
// vite.config.ts import { defineConfig } from 'vite'; import react from '@vitejs/plugin-react'; import path from 'path'; export default defineConfig({ plugins: [react()], resolve: { alias: { '@': path.resolve(__dirname, 'src'), }, }, server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, rewrite: (p) => p.replace(/^\/api/, ''), }, }, }, build: { rollupOptions: { output: { manualChunks: { vendor: ['react', 'react-dom', 'react-router-dom'], antd: ['antd', '@ant-design/icons'], }, }, }, }, });这段配置涉及的三个点，我在项目评审里反复强调：第一是别名，必须统一用@指向 src，否则深层目录引用组件时会写出一串../../../；第二是开发代理，前后端分离几乎是标配，把/api代理到后端接口能避免大量跨域问题；第三是分包，把依赖单独拆出来，这样业务代码更新时用户的缓存利用率更高。
在构建工具选型上，我也遇到过不少团队在 Vite 和 Rspack 之间纠结。实际体验下来，两者的最终产物差距并不是特别大，Vite 生态更成熟，Rspack 在大型工程的增量编译上有优势。如果团队是新人为主，我建议先选 Vite，理由很朴素：遇到问题搜到的答案最多，上手成本最低。
| 对比维度 | Vite | webpack | Rspack |
|---|---|---|---|
| 开发冷启动 | 极快（ESM 按需编译） | 慢（全量打包） | 快（Rust 实现） |
| 配置复杂度 | 低 | 高 | 中 |
| 插件生态 | 丰富 | 最丰富 | 仍在完善 |
| 适用场景 | 新项目、中后台 | 老项目、复杂定制 | 超大型 monorepo |
1.2 Monorepo 与模块联邦：解决“项目变大”以后的协作问题
单个项目还好，一旦牵扯到多个业务系统，比如一个中后台、一个 H5 端、一个管理后台，很多人上来就复制代码，改一个公共组件要同步三个仓库，痛苦写在脸上。这个问题可以用 Monorepo 的思路来解决，也就是多个项目放在同一个仓库里统一管理依赖和发布。
我现在的团队用的是 pnpm workspace，package.json 里只需要写上：
{ "name": "admin-platform", "private": true, "pnpm": { "overrides": {} } }然后配合一个pnpm-workspace.yaml：
packages: - "packages/*"这样就能把公共组件库、工具函数、配置规范都抽成独立包。业务项目引用的时候直接pnpm add @repo/ui --workspace，全局只维护一份 lockfile，依赖版本冲突概率大幅下降。
模块联邦是另一个实用工具，适合多团队并行开发独立部署的场景。它的思路是允许运行时加载远程模块，简单说就是一个应用可以动态引用另一个应用暴露出来的组件。比如权限管理模块由 A 团队维护，业务系统由 B 团队维护，B 系统可以直接在运行时拉取 A 暴露的权限组件，两边独立发版，不用等对方排期。
但模块联邦不是银弹，它带来的版本兼容和调试成本也不低。我的建议是：一开始别上模块联邦，先用 Monorepo 把公共依赖和组件统一起来。只有当团队规模大到“无法一起发布”的程度，再考虑模块联邦方案。
2. 框架与数据流：组件化之后的核心矛盾
2.1 框架选择：React 和 Vue 的现实差异
2026 年聊框架，已经不是“谁更好”的问题，而是“你所在的团队需要什么”。React 19 生态依然庞大，Vue 3.5 后的组合式 API 也很成熟，两者都能撑起大型应用。
我的个人体感是：React 的迭代方向更偏运行时机制和并发能力，比如 Server Components、Transition 这些概念对开发者有更高的心智要求；Vue 则延续了“易上手、模板能力强”的传统，单文件组件把模板、脚本、样式收拢到一个文件，新人理解起来几乎无门槛。
如果你在选型阶段，我会给你一条非常务实的判断路径：如果团队里后端转前端的人多，优先 Vue，因为模板语法更接近直觉；如果团队长期投入做复杂交互产品，并且希望积累 React 生态里的组件和工具链，那就选 React。框架本身不决定项目成败，招人难度和维护成本反而影响更大。
我见过太多团队因为“别人都在用”就盲目切换框架，结果代码迁移折腾了半年。框架选型的本质是团队能力模型和业务需求的匹配，不是追逐潮流。
2.2 服务端状态与客户端状态，别再装进同一个篮子里
状态管理是前端绕不开的痛。很多新手拿到一个需求，第一反应就是往全局 store 里塞数据，最后页面多了，store 变成垃圾场，找 bug 能把头发熬白。
我的核心理念很简单：全局状态分两类，一类是服务端状态，比如用户信息、列表数据、订单详情，这类数据从接口来，需要处理 loading、error、缓存、失效；另一类是客户端状态，比如弹窗开关、主题颜色、表单填写项，这类数据只存在于浏览器内存里。
这两类状态如果混在一个 store 里，会有两个直接问题：一是接口请求代码和 UI 状态耦合，很难复用；二是缓存失效逻辑写得乱七八糟，用户切个页面再回来数据就过期了。
我目前的推荐组合是 TanStack Query 管服务端状态，Zustand 管客户端全局状态。TanStack Query 自带缓存、自动重试、窗口聚焦重新请求，这些功能自己写非常容易踩坑。Zustand 则足够轻量，写起来还不到一百行代码，老项目里迁移成本也低。
// 服务端状态示例 const { data, isLoading, error } = useQuery({ queryKey: ['project', projectId], queryFn: () => fetchProject(projectId), staleTime: 5 * 60 * 1000, }); // 客户端状态示例 const useThemeStore = create((set) => ({ theme: 'light', toggleTheme: () => set((state) => ({ theme: state.theme === 'light' ? 'dark' : 'light', })), }));这里有个容易忽略的细节：staleTime要按业务来设置，并不是缓存时间越长越好。用户修改了项目名称，如果列表数据五分钟内还是旧缓存，界面上看起来就像没保存成功，这种 bug 一旦上线，反馈会很激烈。
2.3 服务端组件 RSC：组件边界的一次重构
React Server Components 这几年的讨论热度一直不低，它的核心思想是部分组件不需要打包到浏览器，直接在服务端渲染成 HTML 或数据流发给客户端，从而大幅减少首屏 JS 体积。
这个方案确实有效，但落地时很多团队理解偏了。有人把 API 请求直接写在服务端组件里，认为只要组件在服务端跑就不会有性能问题。实际上 RSC 的收益主要体现在“减少客户端运行时开销”，而不是“把服务端逻辑搬进组件”。真正合理的做法是：确定组件的渲染场景，纯展示、无交互、不需要客户端事件的组件优先放到服务端渲染；有状态、有交互、依赖浏览器 API 的组件明确标记为客户端组件。
// 服务端组件示例 async function ProjectTitle() { const project = await getProjectFromDatabase(id); return <h1>{project.name}</h1>; } // 客户端组件示例 'use client'; function EditButton({ onClick }) { return <button onClick={onClick}>编辑</button>; }在 2026 年评判一个框架或能力值不值得学，我有一个判断标准：它能不能直接减少一类问题，还是只是换了一种写法。RSC 能减少的是首屏脚本体积，如果你当前项目性能瓶颈根本不在这，优先级可以往后放。
3. TypeScript 实战：把类型能力用在业务细节上
3.1 可辨识联合：消灭“神秘字段”的利器
很多前端写 TypeScript 只停留在“把 props 标个类型”的水平，遇到稍微复杂的业务就退回到any边界。真正把 TypeScript 用到位的项目，类型系统能成为第一层文档和第一道安全网。
可辨识联合是我在业务代码里用得非常多的技巧。比如一个消息中心，消息类型有文本、图片、文件，每种类型的数据结构完全不同。与其写一堆可选字段，不如用联合类型把每种情况约束清楚：
type Message = | { type: 'text'; content: string } | { type: 'image'; url: string; width: number; height: number } | { type: 'file'; name: string; size: number }; function renderMessage(msg: Message) { switch (msg.type) { case 'text': return msg.content; case 'image': return `<img src="${msg.url}" width="${msg.width}" />`; case 'file': return `${msg.name} (${formatSize(msg.size)})`; } }只要type字段是字面量类型，TypeScript 就能在switch分支里自动收窄类型。新增一种消息类型时，编译器会强制你在renderMessage里补上对应分支，这种约束能直接减少“改了数据结构忘记改渲染逻辑”的低级 bug。
3.2 从 API 层反推前端类型：泛型与类型工具的组合用法
接口数据结构发生变化是常态，前端最忌讳的是每个接口手写一个 interface，然后接口返回字段变了就全局搜索替换。更稳妥的做法是统一封装 API 返回体，用泛型复用通用结构。
比如后端常见的返回结构是{ code, message, data }，我可以这样封装：
export interface ApiResponse<T> { code: number; message: string; data: T; } export async function request<T>(url: string): Promise<T> { const res = await fetch(url); const body: ApiResponse<T> = await res.json(); if (body.code !== 0) { throw new Error(body.message); } return body.data; } // 调用时只需要声明业务类型 const user = await request<User>('/api/user');代码里还经常用到Pick、Omit、Partial、ReturnType这些工具类型。比如编辑接口提交的数据通常是实体类型的子集，用Pick选字段比重新写一个更安全；某个函数返回值需要被引用时，用ReturnType<typeof fn>可以避免重复维护一份接口类型。
写类型不是一个被迫的额外工作，它其实是把接口契约固化到代码里。后端字段改了，前端编译期就能发现，而不是等线上报错才去排查。
3.3 类型体操适可而止：别把 TypeScript 写成密码学
有人写 TypeScript 会进入另一个极端：把类型当炫技场，一个泛型嵌套几十层，同事打开代码直接愣住。类型是给人看的，过度抽象的理解成本往往比业务代码本身还高。
我的原则是：类型复杂度控制在“让编辑器补全和重构成功能正常工作”的程度就够。如果一段类型代码需要看十分钟才能明白，大概率是设计出了问题。需要重构的是数据结构，而不是硬用类型去扭曲表达。
在代码评审里看到超长类型，我通常建议先拆成基础类型别名，再组合。这样既保持了约束能力，也让可读性回到正常水平。记住一个标准：如果一个新同学能像读普通代码一样读懂类型，这套类型才算合格。
4. 性能优化：从指标到代码的落地动作
4.1 先把 Core Web Vitals 翻译成具体动作
性能优化最怕聊概念。LCP、INP、CLS 这些指标很重要，但落到日常开发里，每一步都要有对应的代码动作。
| 指标 | 含义 | 前端能做的落地动作 |
|---|---|---|
| LCP | 首屏最大内容绘制时间 | 优化图片格式、压缩首屏 JS、骨架屏 |
| INP | 交互到下一帧响应时间 | 避免长任务阻塞、减少大数据渲染开销 |
| CLS | 布局偏移率 | 图片设置宽高、动态内容预留空间、字体加载策略 |
以 LCP 为例，我见过最多的问题不是“没做优化”，而是“不知道瓶颈在哪”。解决路径其实很清晰：先打开 Chrome DevTools 的 Performance 面板录制一次页面加载，找出最耗时的五件事，再针对性处理。图片永远是首屏优化的第一大户，没必要把所有图片都压到极低质量，但首屏图片转成 WebP 或 AVIF，尺寸按实际展示大小裁剪，通常能省下 60% 以上的传输体积。
INP 反映的是交互响应能力。一个常见反例是列表页里点击筛选，整个页面重新渲染，永远卡在那几百毫秒。改善思路也不复杂：把setState的影响范围缩小到真正变化的组件，或者采用防抖把高频触发合并成一次。记住，用户感受到的卡顿，本质是主线程被密集型任务占了太久。
4.2 列表渲染与状态粒度的优化思路
前端列表渲染是最容易出性能问题的场景。表格里几百行数据，每行又有多个操作按钮，只要有一个组件更新，整个列表跟着重绘，帧率直接掉到 30 以下。
我的经验是先区分数据量。几百行的列表，优先用记忆化组件和稳定的 key 来减少重复渲染。React 里memo是有效手段，但它起作用的前提是 props 引用保持稳定，所以配合useCallback、useMemo才有意义。滥用memo反而会因为比较 props 而增加开销。
数据量上万时，虚拟列表是更直接的解法。虚拟列表的原理是只渲染视口内看得见的行，滚动时动态替换内容。实际项目里可以用react-virtual这类成熟库，它对动态高度和横向滚动的支持已经做得不错。
状态粒度也是性能优化里容易被忽略的环节。一个常见的错误是全局状态里存了一大坨重要数据，组件一多，任何状态变化都会引起所有订阅组件重新 render。解决问题的方法是拆分状态切片：分别维护弹窗开关、筛选条件、列表数据多个 store，而不是把整个页面状态塞进一个对象里。
4.3 构建产物体积与加载优先级：不要盲目追求小体积
很多团队讨论性能，开口闭口“把包体积降到多少 KB”，但体积小不等于体验快。一个只有 100KB 的页面如果在拿到数据之前一直转圈，体验还不如把骨架屏和数据预取做好。
我的做法是把构建产物拆分和资源加载优先级结合来看。按路由拆包是基本操作，首屏只加载当前路由需要的代码，其他路由代码等到访问时再加载。Vite 里只需要写：
const ListPage = () => import('@/pages/ListPage');关键资源可以加<link rel="preload">提前预取，比如首屏用到的字体文件和主接口数据；次要资源用defer或动态导入，避免阻塞渲染。
这里有个容易被忽视的细节：拆包粒度太细也会有反效果。如果每个页面拆出来只有 5KB，请求数量却翻了几倍，HTTP 的开销反而拖慢加载。我一般把“公共依赖”和“路由级 chunk”作为两级拆包标准，既有缓存复用，又不会产生大量小请求。
5. 线上稳定与安全：前端工程师的兜底能力
5.1 前端常见攻击面与基础防御
安全话题平时不显眼，出问题就是大事故。前端最容易忽视的几类攻击，其实都有成熟的防御手段：
XSS 攻击的核心是“用户的输入被当成代码执行”。在 React 里，默认的文本插值已经做了转义，真正的问题通常出在dangerouslySetInnerHTML这类后门。我处理内部后台时经常遇到富文本展示业务，处理原则是：能用纯文本绝不用 HTML，必须富文本展示时走成熟的白名单过滤库。
CSRF 攻击的防御主要靠后端校验，但前端配合上，可以对不受信任的请求不附带默认凭据，或者在后端要求自定义请求头。最常见的“不背锅”写法是统一封装请求库，在 header 里加上自定义字段，这样后端就能判断请求来源。
CSP（内容安全策略）是最值得上手的安全配置，它用 HTTP 头告诉浏览器“页面只允许加载哪些来源的脚本和样式”。设置一个基础的Content-Security-Policy，能把很多未知来源的脚本注入堵在门外。这个配置在开发和测试阶段会因为内联脚本、eval 之类的冲突变得有点烦，但上线前值得花时间理清。
5.2 错误监控与性能上报的埋点设计
很多前端项目没有主动收集线上错误的能力，用户反馈不好用了，前端第一反应是“我本地没问题”。本地没问题恰恰说明缺少监控。一个成熟的线上项目，至少要有三件事：全局错误捕获、资源加载失败捕获、接口请求异常上报。
代码层做全局捕获，思路很统一：
window.addEventListener('error', (event) => { reportError({ type: 'resource', source: event.target?.src || event.target?.href, }); }); window.addEventListener('unhandledrejection', (event) => { reportError({ type: 'promise', message: event.reason?.message, stack: event.reason?.stack, }); });上报的数据不直接 alert 用户，而是统一 POST 到采集服务。如果用了 Sentry 这类平台，可以少造不少轮子，但埋点思路是一样的：错误信息、堆栈、用户操作路径、当前 URL、设备信息，这五个字段缺一不可。
性能上报的逻辑则不同，它更看重“聚合”和“趋势”。首屏加载时间、接口响应耗时、路由切换耗时可以按小时或按天聚合，波动超过阈值时报警。没有性能监控，优化就是一个人的手感；有了监控，才能说一句“这轮优化确实生效了”。
5.3 一次线上事故的排查实录
写一段真实排查经历，可能比原理更容易让人记住。有一次线上后台用户反馈列表页“数据全没了”，打开报错后台发现大量Unexpected token错误，来自接口返回的 JSON 解析失败。
排查过程大概是这样的：我先在 Sentry 里按错误关键词筛选出受影响用户，发现集中在某个浏览器版本；然后在本地用同样的浏览器复现，确实能稳定复现；打开 Network 面板看响应，发现接口返回了一串被截断的 JSON。正常的 JSON 应该是完整闭合的，但这个响应在第二十行左右被切断了。
再往下追，定位到是网关配置的超时时间太短，接口处理了 20 秒还没返回完整数据，网关直接把响应截断了。这个问题的坑在于：HTTP 状态码依然是 200，前端代码拿到的是残缺的 JSON，只能解析报错。
修复方案是三方配合：后端优化查询语句，网关调大超时时间，前端给 JSON.parse 包一层 try-catch。最让我在意的是，如果前端有“接口异常兜底”，这个事故的影响面积会小很多。这也是我坚持推荐团队做统一请求封装的原因：底层把所有 JSON 解析、错误码判断、异常上报都收口，上层业务代码就不用每个人各写一套异常逻辑。
6. 2026 年，我这样安排前端学习与进阶
6.1 用“完整项目”建立知识闭环
前端知识散落在文档、视频、博客里，每天刷技术文章感觉很充实，一旦关掉页面就什么都说不出来，这种现象我很熟悉。真正能让知识长在身上的方式，是做一个需要自己独立解决所有问题的完整项目。
我建议不要做那些随处可见的“待办事项”或“新闻列表”。给自己设计一个有点复杂度的小系统，比如一个可视化数据看板、一个多角色权限管理系统、一个低代码表格配置工具。这类项目会逼着你处理布局、状态、接口、权限、错误处理、打包部署全链路问题，每一步都会踩坑，但每一坑都是有效积累。
做的时候注意一件事：尽量用当前主流的技术栈和工程化工具，不要把时间浪费在搭建旧脚手架上。2026 年再写原生 class 组件，对找工作和做项目都没有实际帮助。
6.2 判断能力的标准不是“学过”，而是“能修”
我面试前端的时候，很少问对方“你学过什么”，更常问“你最近排查过什么难 bug”。后一个问题的回答质量，基本能反映真实水平。能描述清楚一个 bug 的背景、定位方法、修复思路，说明这个人真的在项目里待过，而不是只敲过教学例子。
日常工作里，主动去接那些“别人不愿意碰”的模块，往往成长最快。老项目的代码虽然又丑又乱，但它是一本活的百科全书：你能看到别人怎么设计状态、怎么拆分组件、怎么处理边界情况。修一个老 bug 学到的东西，常常比新写十个页面还多。
学习路径上我建议给自己定一个可验证的目标：这个月结束前，能把一个中小型前端项目从零搭建、开发、发布到线上，并且能说清楚每个环节为什么这么做。做到了再进入下一个模块。
6.3 最后分享一个我的日常习惯
关于学习本身，我的个人习惯是每周固定抽一点时间去看官方 changelog，不追求逐条都看，只看和自己工作直接相关的部分。比如你用的 UI 库发了个新版本，新增了一个组件，修复了几个 issues，这些信息能让你在项目里少踩很多已知坑。很多同学习惯等出问题再搜答案，但 changelog 里的信息，是别人已经帮你排过雷的总结，这个成本比“踩坑后搜答案”低太多。
另外建议写笔记时不要直接抄文档，用自己的话把“这个知识点解决了什么问题”写出来。那种笔记里最容易出现的现象是复制粘贴了很多示例代码，但永远不会再看第二遍。反而是那些用大白话记录“我当时是这么理解”的文字，过几个月回去看仍然有参考价值。
前端这个行业变化很快，但如果能把工程化、数据流、类型、性能、稳定性这些底座打扎实，任它框架怎么换，你都能在短时间内跟上。这篇总结只是一个参考框架，真正值钱的永远是你在项目里亲自动手解决过的问题。
