简介一套面向前端开发者的系统学习笔记合集覆盖从HTML/CSS/JS基础、ES6、TypeScript、Scss到Git版本控制、Ajax/Axios请求、Promise异步编程、Webpack构建再到Vue、React、React Hooks、Mobx状态管理、微信小程序以及正则表达式、前端部署、UI库选型、代码规范和Chrome开发调试等高频主题知识点均来自实际开发与长期学习记录。全包以zip压缩形式打包体积约114.96MB文件总数暂未标注笔记按主题分块保存穿插示例代码、排错经验和关键概念对比结构较清晰适合按需查阅其中的示例代码多带注释便于直接参考。目前已有912人参与学习适合正在搭建知识体系的前端初学者、希望系统查漏补缺的初中级工程师以及准备面试或快速回顾技术点的从业者。整体是一份覆盖面广、实践性强的前端手册能减少碎片化搜索与重复踩坑帮助读者更快建立完整技术认知。1. 前端工程师的超级详细笔记缺的不是内容而是索引反直觉的是大部分前端工程师不缺信息缺的是把信息变成可检索、可回溯、可复验的索引。浏览器收藏夹里躺着上百个链接GitHub Star 了几十个仓库面试前还是翻聊天记录找“上次那个跨域方案到底怎么改的”。真正能撑住五年以上职业生涯的不是记住多少 API而是有没有一套“前端学习笔记”系统让写过的代码、踩过的坑、看过的源码在三个月后还能被一行命令捞出来。我倾向把笔记看成“反遗忘工程”它解决三个问题第一八股文背了就忘第二组件封装方案散落在各个项目里第三线上故障复盘后没有沉淀。这篇内容不讨论某个框架的 API而是给出一条从小到大、可落地的学习笔记搭建路径包含目录规范、自动化脚本、面试题模板和每日复习机制。应届生能照着搭五年的老手也能把零散文档收拢成自己的知识库。2. 为「前端学习笔记」搭一个 Markdown Git Node 的知识索引库2.1 先想清楚笔记系统为什么需要“后端”很多人把笔记软件当作文件夹用新建一个“前端学习”然后往里面猛塞截图和文档。一年后打开发现 800 个文件平铺在一起搜索“闭包”能搜出 40 条结果但每条都长得差不多。原因很简单收集层没有和索引层分离。我一般把前端知识库分成三层。最底层是收集层存放原始资料比如某个组件库的 API 截图、某次面试的真题记录这部分允许乱中间层是索引层用 Markdown 文件描述“知识点关键词到原始资料的映射”相当于图书馆的目录柜最顶层是检索层通过脚本或命令把索引暴露出来比如“列出所有标记为#vite的笔记”“查询本周新增了哪些面经”。这个架构用纯笔记软件很难实现因为笔记软件的标签体系是平的无法表达“笔记 A 引用了笔记 B”的关系。常见做法是用 Markdown 作为存储格式用 Git 管理历史用 Node 脚本做索引生成。Markdown 保证任何电脑上都能打开Git 解决误删和回滚Node 脚本则是把“超级详细”变成“超级好查”的关键一环。2.2 最小可复现的目录结构三条命令建好骨架在本地新建一个仓库目录结构不需要复杂能撑住三个月以上的积累就行。我常用的骨架是这样frontend-notes/ ├── README.md ├── docs/ │ ├── interview/ # 前端面试题、八股文记录 │ ├── engineering/ # 构建、部署、CI/CD、nginx 配置 │ ├── component/ # 组件库封装、UI 框架踩坑 │ ├── performance/ # 性能优化案例与指标复盘 │ └── debug/ # 线上故障、疑难 bug 的排错过程 ├── scripts/ │ ├── scan-index.mjs │ └── daily-review.mjs └── package.json初始化命令如下mkdir -p frontend-notes/{docs/{interview,engineering,component,performance,debug},scripts} cd frontend-notes git init npm init -y这段命令做了三件事一次性创建docs下的五个知识分类目录初始化 Git 仓库生成package.json。为什么要拆成五个目录而不是直接用标签因为标签只能告诉你“这条笔记和 Vue 有关”但目录能告诉你“这是在面试场景里遇到的 Vue 问题还是在生产环境排错时遇到的 Vue 问题”。场景不同记录的侧重点就不同。2.3 用 scan-index.mjs 自动生成 README 索引“超级详细”的笔记库必须有索引入口否则对不起“详细”两个字。一个小脚本可以做到扫描docs下所有 Markdown 文件提取标题、标签和更新时间生成带目录跳转的 README 索引。// scripts/scan-index.mjs import { readdir, readFile, stat, writeFile } from node:fs/promises import { join, basename } from node:path import matter from gray-matter // 需要先安装npm i gray-matter const DOCS_ROOT join(process.cwd(), docs) const output [] async function walkDir(dir) { const entries await readdir(dir, { withFileTypes: true }) for (const entry of entries) { if (entry.isDirectory()) { await walkDir(join(dir, entry.name)) } else if (entry.name.endsWith(.md)) { const fullPath join(dir, entry.name) const raw await readFile(fullPath, utf-8) const { data } matter(raw) const stats await stat(fullPath) output.push({ title: data.title || basename(entry.name, .md), tags: data.tags || [], updated: stats.mtime.toISOString().slice(0, 10), path: fullPath.replace(process.cwd(), .) }) } } } await walkDir(DOCS_ROOT) output.sort((a, b) b.updated.localeCompare(a.updated)) const lines output.map(n | ${n.title} | ${n.tags.join(, )} | ${n.updated} | [查看](${n.path}) | ).join(\n) const readme # 前端学习笔记索引\n\n最近更新在前。\n\n| 标题 | 标签 | 更新日期 | 链接 |\n| --- | --- | --- | --- |\n${lines}\n await writeFile(join(process.cwd(), README.md), readme, utf-8) console.log(已生成 ${output.length} 条索引记录)脚本的逻辑不复杂递归遍历docs目录用gray-matter读取每个 Markdown 文件头部的title和tags字段取文件的修改时间作为更新日期最后按日期倒序拼成表格写入 README。参数上要注意两点gray-matter只解析---包裹的 YAML 头如果笔记没有写 YAML 头脚本会用文件名兜底mtime在 Git 克隆后会被修改所以本地维护即可不要依赖它做版本对比。在package.json里加上快捷命令{ scripts: { scan: node scripts/scan-index.mjs } }以后每次写完笔记跑一次npm run scanREADME 就是最新的。这里的用意是索引不是靠人手工维护的是每次提交前自动刷新的。2.4 同一套脚本体系查重与失效链接检测笔记多了以后最怕两件事重复记录和链接失效。查重可以用一个简单的思路——按标题相似度去重。Node 脚本读取所有笔记标题两两计算编辑距离超过阈值就输出疑似重复的清单。// 编辑距离简化实现只用于标题级别的查重 function editDistance(a, b) { const dp Array.from({ length: a.length 1 }, (_, i) [i, ...Array(b.length).fill(0)]) for (let j 0; j b.length; j) dp[0][j] j for (let i 1; i a.length; i) { for (let j 1; j b.length; j) { const cost a[i - 1] b[j - 1] ? 0 : 1 dp[i][j] Math.min(dp[i - 1][j] 1, dp[i][j - 1] 1, dp[i - 1][j - 1] cost) } } return dp[a.length][b.length] }这个函数本身很简单但用途很实际当我写的两篇笔记标题相似度超过 80% 时说明可能在同一主题上重复造轮子该合并了。配合 Git每周末跑一次查重就能把“超级详细”控制在“冗余但不臃肿”的范围内。3. 从「前端面试题」到「八股文」把高频题写成可复验的笔记3.1 只记答案不记题干是面经笔记里最大的时间黑洞翻看很多人的前端面试题笔记典型的写法是“闭包的作用是保护变量不被污染减少全局变量。”然后再看下一页“闭包缺点内存泄漏。”第三条“闭包应用场景防抖、节流。”这些内容对吗对但没用。因为没有题干映射复习的时候想不起来是在什么情景下问的面试官换个问法就答不上了。八股文的正确打开方式是题干驱动。每篇笔记都以一个真实的面试问题开头下面附上“考察点拆解 — 结论 — 可复现验证”。比如“闭包”这条题干写“下面的 for 循环为什么全部输出 5怎样修改才能输出 0 到 4”考察点拆解是“作用域链、var 与 let 的区别、异步执行顺序”可复现验证是一段能直接跑的 Node 命令。这样记笔记面试前复习的就是“问题—答案—原因”的完整映射而不是割裂的知识碎片。用 Markdown 写模板时我把 YAML 头当作检索字段正文当作记录本体--- title: 闭包与循环变量泄漏为什么 for 循环里全是 5 tags: [JavaScript, 闭包, 面试题] date: 2026-03-10 category: interview --- ## 题干 js for (var i 0; i 5; i) { setTimeout(() console.log(i), 100) }写出以上代码的输出结果并说明原因。考察点var 声明的变量遵循函数作用域循环结束时 i 已经是 5宏任务与微任务的执行顺序setTimeout 的回调在循环结束后才执行let 声明变量的块级作用域每次迭代会产生新的绑定结论输出五次 5。改成let i 0或者用 IIFE 包裹 setTimeout 可输出 0 到 4。验证命令node -e for (let i 0; i 5; i) { setTimeout(() console.log(i), 100) }YAML 头里的 category 字段对应 docs 下的分类目录tags 数组则用来做跨类检索。这样面试前想突击“作用域”一条命令就把所有相关笔记抓出来了 bash grep -r tags:.*作用域 docs/interview/3.2 前端传参、跨域、大文件上传把真题映射成场景笔记2026 年的前端面试早已不是纯八股文的天下题目通常带着具体场景。整理笔记时必须把“参数怎么传”和“这里的限制是什么”绑定在一起写。比如“前端传参”这个高频点我一般会记录三种形态URL query 适合简单的 GET 请求application/json适合复杂结构multipart/form-data适合文件上传。每条下面都附带正反例特别是“用 query 传数组”这种常见的翻车写法。再比如“前端使用 worker 上传大文件”这个题目它把 Web Worker、文件分片、并发控制三个知识点串在一起。笔记如果只写“用 Worker 分片”就丢失了“为什么不用主线程”的上下文。折中的方案是在笔记里放上一张简化的流程图文字描述把主流程写成主线程读文件 → 按 5MB 分片 → 通过postMessage传给 Worker → Worker 负责计算 hash 和发起上传 → 主线程负责进度条渲染。面试时把这个流程说清楚比背十个 API 名管用。3.3 给八股文笔记内置“自测模式”命令行随机抽题笔记写了不看等于白写。更有效的思路是给每个 Markdown 文件约定一个约定在末尾加一行## Answer正文只留题干。然后写一个几百字节的脚本随机抽取五道面试题打印题干自己在脑子里默答再翻文件核对。# 随机抽取 5 篇面试题笔记打印题干部分 find docs/interview -name *.md | shuf -n 5 | while read f; do echo ### $(basename $f .md) awk /^## Answer/{exit} {print} $f | head -20 echo done这段 shell 命令利用shuf随机排序再用awk截取## Answer之前的内容。输出的是纯题干逼着自己先回忆再打开完整笔记对照。这个模式背后是一个认知科学结论提取练习比重复阅读更能巩固记忆。面经笔记的价值不在写的时候在抽的时候。4. 把「前端开发」笔记升级成排错手册工程化约定与复盘表4.1 组件库与 UI 框架笔记不要写 API写封装决策五年以上的前端工程师翻自己的笔记最常看的不是“Vue 有哪些生命周期”而是“这个组件当初为什么这么设计”。所以组件库笔记的写法要区别于官方文档少粘贴 API多记录决策背景。我习惯用四个小节组织一篇组件笔记使用场景、封装边界、性能注意点、已知缺陷。以“前端组件库”里的虚拟滚动表格为例使用场景写“需要渲染一万行以上数据且不能分页”封装边界写“只做可视区渲染不做单元格合并”性能注意点写“行高必须固定否则需要二次测量”已知缺陷写“键盘导航失效已在 v2.3 修复但未同步到线上”。这些信息才是真正的“超级详细”。表格在组件笔记里也很有用一个典型的组件选型对比表长这样组件库包体积样式定制方式SSR 兼容团队熟悉度Element Plus偏大CSS Variables支持高Ant Design Vue偏大ConfigProvider token支持高Naive UI中等主题变量支持中选型笔记的价值不在于“哪个最好”而在于记录当时对比的维度。半年后组件库升级或团队扩张重读这篇笔记能快速回忆起当初决策的出发点。4.2 排错笔记的标准模板现象、剥离、定位、修复、回归“前端开发”中最容易产生高价值笔记的场景是线上故障。很多人的排错记录是聊天记录截图加一句“已修复”三个月后看完全不知道发生了什么。我用的排错模板是五段式--- title: 生产环境首屏白屏nginx 返回 index.html 但 JS 加载 404 tags: [nginx, vite, 部署] category: debug --- ## 现象 用户反馈白屏控制台显示 /assets/index-abc.js 404 ## 剥离过程 1. 本地构建正常排除代码问题 2. 检查 nginx 配置发现 try_files 只写了 $uri 3. 刷新页面时 URL 为 /user/listnginx 尝试返回 /user/list 文件失败 ## 根因 history 路由模式缺少 try_files 回退SPA 路由无法在刷新时命中 index.html ## 修复方案 location / { try_files $uri $uri/ /index.html; } ## 回归验证 刷新 /user/list 页面JS 正常加载nginx -t 通过这个模板的核心不是“五段式”本身而是“剥离过程”这一节。排错笔记最值钱的部分不是最终修复的那一行配置是排查路径。把排查路径记录下来下次遇到类似问题能少走一半弯路。4.3 用nginx 部署前端 Vue 项目当第一个排错案例部署类笔记最适合做排错模板的练习。拿“nginx 部署前端 Vue 项目”这个高频场景举例一篇完整的笔记至少应覆盖build命令确认、dist产物检查、nginx 的root和try_files配置、gzip是否开启、刷新 404 的处理。我见过太多次“本地好好的上服务器就白屏”的提问问题几乎都出在路径前缀和 history 路由上。一个最简的 nginx 配置片段值得放进笔记里做基准配置server { listen 80; server_name example.com; root /var/www/frontend/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /assets/ { expires 30d; add_header Cache-Control public, immutable; } }配置里值得标注的参数是第二段location /assets/它把静态资源的缓存时间拉长到 30 天同时用immutable告诉浏览器文件内容不会变化。这样配合 Vite 构建时生成的内容指纹既能保证用户拿到最新代码又能充分利用缓存。4.4 性能优化笔记里的“指标复盘表”性能优化是最容易写水的内容“减少请求数”“压缩图片”“开启 CDN”每句话都对每句都没用。真正的笔记必须带数字。每做一次性能优化都把关键指标记下来才形成可复用的经验。指标优化前优化后优化手段LCP3.8s1.9s图片转 WebP preload 首屏大图TTFB800ms420ms接入 CDN源站开启 gzipCLS0.240.08图片容器固定宽高比骨架屏占位这张表的每一行都是独立的一篇笔记。优化前后数值差距越大笔记的参考价值越高。写性能笔记的时候我会刻意把“测量方式”也写进去比如 LCP 是用的 Lighthouse 10 还是 Web Vitals 库在什么网络条件下测的。不同测量条件下数值不可比这是很多人忽略的点。5. 用定时任务驱动「超级详细」笔记的每日复习5.1 给复习计划加一个简单的遗忘曲线调度笔记系统如果没有复习机制撑死只是一个本地文档库。我采用极简的间隔重复策略每篇笔记的 YAML 头里加review_count字段每复习一次加一复习间隔按2 ^ review_count天推算。复习过三次的笔记间隔 8 天过六次间隔 64 天这样高频考点自然比冷门知识点出现得更频繁。下面的脚本读取所有笔记的review_count和last_reviewed日期筛出今天需要复习的// scripts/daily-review.mjs import { readdir, readFile } from node:fs/promises import { join } from node:path import matter from gray-matter const DOCS_ROOT join(process.cwd(), docs) const today new Date() const dueList [] async function walk(dir) { const entries await readdir(dir, { withFileTypes: true }) for (const entry of entries) { if (entry.isDirectory()) { await walk(join(dir, entry.name)) } else if (entry.name.endsWith(.md)) { const raw await readFile(join(dir, entry.name), utf-8) const { data } matter(raw) if (!data.last_reviewed) continue const interval Math.pow(2, data.review_count || 0) const lastDate new Date(data.last_reviewed) const diffDays Math.floor((today - lastDate) / (1000 * 60 * 60 * 24)) if (diffDays interval) { dueList.push({ title: data.title, path: join(dir, entry.name), interval }) } } } } await walk(DOCS_ROOT) if (dueList.length 0) { console.log(今日无待复习笔记) } else { dueList.forEach(item { console.log([到期] ${item.title} (间隔 ${item.interval} 天)) }) }脚本逻辑很简单用last_reviewed和review_count两个字段算下一次到期时间。间隔用指数增长的方案符合记忆的遗忘曲线。使用时复习完一篇笔记就同步更新 YAML 头里的两个字段然后跑一遍daily-review.mjs它会把到期清单打出来。配合crontab就可以做到每天早上自动输出复习清单0 9 * * * cd /path/to/frontend-notes node scripts/daily-review.mjs /tmp/notes-review.log 21定时任务的参数里0 9 * * *表示每天早上九点执行。把输出追加到日志文件既不打扰工作又可以回头检查自己一周内到底复习了几次。复习这个动作不需要一次搞定所有的笔记每天五篇到八篇就已经能产生明显的效果。5.2 用git diff和npm run scan做每周笔记活力检查最后再补一个技巧与其逼自己“每天必须写笔记”不如在每周五下班前看一眼本周的 Git 提交记录。一条命令就能统计一周里新增和修改了多少篇笔记git log --since7 days ago --prettyformat:%h %s -- docs/输出的每一行代表一次提交冒号前面是提交哈希后面是提交信息。如果想统计每篇笔记的改动行数可以再叠加git diffgit diff HEAD~7 --stat -- docs/这两条命令会诚实地暴露一个问题如果你这周一行笔记都没写那说明这周的前端学习基本是停滞的。没有更新就没有成长这个检查方式比任何打卡工具都直接。把npm run scan跑一遍README 刷新出本周新增的内容周一度假回来打开仓库新的一周就从最新的索引开始。本文还有配套的精品资源点击获取