今年前端圈子的信息量说实话比往年都大。各种新工具、新写法、新框架版本层出不穷但真正落到日常项目里的其实还是那些被反复验证过的核心知识。我整理了 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理由很朴素遇到问题搜到的答案最多上手成本最低。对比维度VitewebpackRspack开发冷启动极快ESM 按需编译慢全量打包快Rust 实现配置复杂度低高中插件生态丰富最丰富仍在完善适用场景新项目、中后台老项目、复杂定制超大型 monorepo1.2 Monorepo 与模块联邦解决“项目变大”以后的协作问题单个项目还好一旦牵扯到多个业务系统比如一个中后台、一个 H5 端、一个管理后台很多人上来就复制代码改一个公共组件要同步三个仓库痛苦写在脸上。这个问题可以用 Monorepo 的思路来解决也就是多个项目放在同一个仓库里统一管理依赖和发布。我现在的团队用的是 pnpm workspacepackage.json 里只需要写上{ name: admin-platform, private: true, pnpm: { overrides: {} } }然后配合一个pnpm-workspace.yamlpackages: - 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 ApiResponseT { code: number; message: string; data: T; } export async function requestT(url: string): PromiseT { const res await fetch(url); const body: ApiResponseT await res.json(); if (body.code ! 0) { throw new Error(body.message); } return body.data; } // 调用时只需要声明业务类型 const user await requestUser(/api/user);代码里还经常用到Pick、Omit、Partial、ReturnType这些工具类型。比如编辑接口提交的数据通常是实体类型的子集用Pick选字段比重新写一个更安全某个函数返回值需要被引用时用ReturnTypetypeof 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 relpreload提前预取比如首屏用到的字体文件和主接口数据次要资源用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 里的信息是别人已经帮你排过雷的总结这个成本比“踩坑后搜答案”低太多。另外建议写笔记时不要直接抄文档用自己的话把“这个知识点解决了什么问题”写出来。那种笔记里最容易出现的现象是复制粘贴了很多示例代码但永远不会再看第二遍。反而是那些用大白话记录“我当时是这么理解”的文字过几个月回去看仍然有参考价值。前端这个行业变化很快但如果能把工程化、数据流、类型、性能、稳定性这些底座打扎实任它框架怎么换你都能在短时间内跟上。这篇总结只是一个参考框架真正值钱的永远是你在项目里亲自动手解决过的问题。