简介面向初学者的 GitHub 综合入门指南围绕版本控制、开源协作与 JavaScript 开发展开帮助新用户快速上手托管代码、管理项目与参与开源。压缩包共 12 个文件主要以 HTML 页面呈现辅以 JavaScript 脚本、图片及配置文件整体仅 229KB内容紧凑实用。已有 2084 人学习浏览受到一定关注。资料系统梳理了 GitHub 的核心功能包括 Git 追踪、Pull Request 代码审查、Issue 管理、Actions 自动化测试部署、Pages 静态网站托管和 Webhooks 事件触发等同时结合 JavaScript 的典型应用场景如 Node.js 后端、Electron 桌面开发和 React Native 移动开发给出具体示例与说明。此外还涉及开源许可证选择、贡献指南CONTRIBUTING.md以及 Gist 代码片段分享等细节可作为新手在 GitHub 上进行日常开发与协作的随身参考。1. 一份能直接抄的 JavaScript 工程实战资源包从源码阅读到二次开发很多开发者拿到一份 JavaScript 资源包第一反应就是 npm install 然后赶紧跑 demo结果十有八九卡在依赖缺失和语法报错上最后只能无奈关掉窗口。这份资源包的思路刚好反过来它把手写 Promise、深拷贝、防抖节流、事件循环推演这类核心机制拆成一个个独立模块每个模块都能单独运行、单独验证不依赖任何构建工具装好 Node 就能直接跑。适合两类人准备前端面试、想把 JavaScript 核心原理彻底吃透的进阶开发者以及想快速拿到一套可复用工具函数和配套测试的工程向开发者。下面我按「结构 → 核心代码 → 运行验证 → 避坑 → 二次开发」的顺序把它完整拆一遍。2. 资源包结构与技术选型读懂目录设计就掌握了主线2.1 目录设计按「一个目录一个能力」划分模块先看整体结构这是理解整个包最快的方式js-engineer-toolkit/ ├── src/ │ ├── core/ # 核心机制实现 │ │ ├── promise/ # 手写 Promise 及派生 API │ │ ├── clone/ # 深拷贝实现 │ │ ├── event-loop/ # 事件循环推演示例 │ │ └── function/ # 防抖、节流工具 │ ├── utils/ # 类型判断、格式化等通用函数 │ └── patterns/ # 设计模式示例 ├── tests/ # 与 src 一一对应的测试用例 ├── scripts/ # 一键运行与验证脚本 ├── docs/ # 设计文档与面试要点 └── package.json这份目录的核心原则是「一个目录一个能力」。promise、clone、event-loop、function 四个子目录互不引用各自包含实现文件和演示入口文件tests 目录下的文件名与 src 保持一一对应比如 src/core/clone/ 里的实现对应 tests/clone.test.js。这样设计的好处有两个读代码时不用沿着一堆 import 跳来跳去调试时也能直接定位到具体文件不需要启动整个应用。对面试准备者来说这种「一个主题一个闭环」的组织方式也方便按天推进复习。各核心模块的入口与可验证点对应关系如下目录入口文件可验证点src/core/promiseindex.js状态流转、链式调用、微任务时序src/core/cloneindex.js循环引用、Date/RegExp、Symbol 键src/core/event-loopindex.jsasync/await 输出顺序src/core/functionindex.js防抖触发次数、节流触发间隔tests 目录与 src/core 保持一对一关系tests/function 里同时覆盖防抖和节流两种场景防抖用例验证连续调用后只触发一次且参数和 this 正确透传节流用例验证高频调用被压缩到窗口内最多一次。utils 和 patterns 是补充模块不参与主链路适合作为扩展阅读——比如 utils 里的类型判断函数深拷贝内部判断对象类型时也会用到属于跨模块复用。docs 目录里放的是每块机制的设计说明包括状态流转图、执行顺序表以及面试追问的参考思路。我拆这类资源包时有个习惯先看 docs 目录有没有有就先读它再回头读代码效率比直接啃源码高不少这份资源的 docs 写得够细基本可以当复习笔记用。2.2 技术选型为什么能做到零构建直接跑先看选型总览模块选型说明运行环境Node LTS18 及以上原生支持 ES 模块无需编译语言原生 ES2015只用标准语法无额外编译步骤测试Node 内置 test runner每个模块自带验证用例依赖运行时零依赖无第三方库可整体移植这里最值得说的是「零依赖」这件事。很多开源包为了省事直接把第三方工具库引进来结果读源码时一半时间在查别人封装的实现。这个包刻意不用任何运行时依赖深拷贝、防抖、节流全部手写连断言都用 Node 内置模块。npm install 只装一个东西整个包体积基本没有变化拷到离线环境也能跑。我一般会建议如果你想把里面的代码挪到公司项目直接复制文件即可不会带着一串依赖把项目搞臃肿。package.json 里的核心配置也不复杂拆开看就三行{ type: module, scripts: { test: node --test tests/, verify: node scripts/verify.js } }type 字段声明为 module所有 .js 文件按 ES 模块解析源码里的 import/export 才能直接跑test 脚本走 Node 自带的 test runner不用装额外测试框架verify 脚本则负责逐个模块跑演示输出。这里有个常见的理解误区ES 模块不是新框架它就是 Node 原生支持的语法只要版本达标不需要任何打包器。这也是这份资源能实现「零构建直接跑」的根本原因——不是它做了多牛的工程化而是它把不必要的东西全砍掉了。版本这里要特别留意test script 依赖 Node 18 之后内置的 test runnernode --test tests/这种写法在 16 上会直接报错。如果你本机版本偏低两个选择升级 Node或者把 test script 改回node --test tests/clone.test.js这种单文件写法。我拆包时习惯先跑node -v确认环境再决定要不要动 script省得后面排查半天发现是环境问题。整体来看这份资源的技术选型思路就一句话能零依赖就零依赖能用标准语法就用标准语法把「读代码」的成本降到最低。3. 核心代码拆解手写 Promise、深拷贝与事件循环推演3.1 手写 Promise状态机加微任务是最小骨架先看核心实现完整版在源码里包含全部静态方法这里先看最关键的状态机与链式调用function MyPromise(executor) { this.state pending; // pending / fulfilled / rejected this.value undefined; // fulfilled 的终值或 rejected 的拒因 this.callbacks []; // 等待队列存放 then 注册的回调 const resolve (value) { if (this.state ! pending) return; // 状态只能变更一次 this.state fulfilled; this.value value; this.callbacks.forEach((cb) this._handle(cb)); }; const reject (reason) { if (this.state ! pending) return; this.state rejected; this.value reason; this.callbacks.forEach((cb) this._handle(cb)); }; try { executor(resolve, reject); } catch (e) { reject(e); // executor 同步抛错直接转 reject } } MyPromise.prototype._handle function (cb) { if (this.state pending) { this.callbacks.push(cb); return; } const fn this.state fulfilled ? cb.onFulfilled : cb.onRejected; queueMicrotask(() fn(this.value)); // 保证异步执行 }; MyPromise.prototype.then function (onFulfilled, onRejected) { return new MyPromise((resolve, reject) { this._handle({ onFulfilled: (value) { try { resolve(onFulfilled ? onFulfilled(value) : value); // 未传则透传 } catch (e) { reject(e); } }, onRejected: (reason) { try { resolve(onRejected ? onRejected(reason) : reason); } catch (e) { reject(e); } } }); }); };几个关键设计点拆开说。首先是状态机state 只有 pending、fulfilled、rejected 三种resolve/reject 入口处都判断「非 pending 直接 return」这就是 Promise 状态不可逆的实现——从根上杜绝了重复决议。其次是 then 的返回值then 内部 new 了一个新的 MyPromise并把 onFulfilled/onRejected 的返回值交给新 Promise 的 resolve这样链式调用才成立如果回调里抛异常会被 catch 捕获并转成新 Promise 的 reject这也是链上后面的 catch 能接住的原因。最后是微任务调度这里用 queueMicrotask 而不是 setTimeout。两者差别在于优先级——microtask 队列会在当前宏任务结束后立即清空而 setTimeout 要等下一轮宏任务。Promise 的回调必须走微任务这个顺序直接影响事件循环里 console.log 的输出时序3.3 节的推演会用到这条规则。关于参数executor 是构造时立即同步执行的回调接收 resolve、reject 两个函数onFulfilled、onRejected 分别是 then 注册的成功、失败回调都可省略省略时做透传处理。需要注意这个实现刻意省略了「resolve 传入 thenable 时递归展开」的 A 规范细节那是规范完备性问题不影响理解主流程。3.2 深拷贝与防抖节流两个高频实用手写题深拷贝实现如下function deepClone(target, seen new Map()) { if (target null || typeof target ! object) return target; if (seen.has(target)) return seen.get(target); // 循环引用直接返回已有克隆 if (target instanceof Date) return new Date(target.getTime()); if (target instanceof RegExp) return new RegExp(target.source, target.flags); if (target instanceof Map) { const cloneMap new Map(); seen.set(target, cloneMap); target.forEach((v, k) cloneMap.set(deepClone(k, seen), deepClone(v, seen))); return cloneMap; } if (target instanceof Set) { const cloneSet new Set(); seen.set(target, cloneSet); target.forEach((v) cloneSet.add(deepClone(v, seen))); return cloneSet; } const clone Array.isArray(target) ? [] : {}; seen.set(target, clone); Reflect.ownKeys(target).forEach((key) { clone[key] deepClone(target[key], seen); }); return clone; }这个实现对比常见的 JSON.parse(JSON.stringify(obj)) 方案解决了四个经典问题循环引用导致的栈溢出、Date 被序列化成字符串、RegExp 被序列化成空对象、Symbol 键被直接丢弃。实现上有三个要点。第一seen 这个 Map 参数是整个函数的核心记录「原对象 → 克隆对象」的映射遇到循环引用时命中缓存直接返回递归就不会无限走下去了。第二内置对象要分类型处理Date、RegExp、Map、Set 各自走自己的构造路径不能走普通对象遍历。第三遍历用 Reflect.ownKeys 而不是 Object.keys前者能把 Symbol 键也带上后者会丢。关于参数target 是需要克隆的任意值seen 是内部使用的缓存 Map调用方不需要传。防抖与节流的实现更短但参数语义值得说清楚// wait 毫秒内的连续调用只执行最后一次 function debounce(fn, wait 300) { let timer null; return function (...args) { clearTimeout(timer); timer setTimeout(() { fn.apply(this, args); timer null; }, wait); }; } // 每 wait 毫秒最多执行一次首次立即执行 function throttle(fn, wait 300) { let last 0; return function (...args) { const now Date.now(); if (now - last wait) { last now; fn.apply(this, args); } }; }两个函数都返回一个新函数新函数里用 this 和 args 把原函数的调用上下文完整保留。区别在触发策略debounce 每次调用都重置定时器只有停顿超过 wait 才会真正执行适合输入框搜索、窗口 resizethrottle 用时间戳对比wait 内最多执行一次适合滚动事件、mousemove 这类高频回调。参数方面fn 是目标函数wait 是间隔毫秒数默认 300。常见误用是拿防抖去做滚动节流结果「一直滚动就一直不执行」看起来像卡死。3.3 事件循环推演async/await 到底先打印谁事件循环模块里放了一组对照 demo最典型的是下面这段async function asyncA() { console.log(A1); await asyncB(); console.log(A2); // 这里是微任务恢复点 } async function asyncB() { console.log(B1); } console.log(S1); asyncA(); Promise.resolve().then(() console.log(P1)); console.log(S2); // 实际输出S1 - A1 - B1 - S2 - P1 - A2推演逻辑分四步。第一步async 函数体在第一个 await 之前是同步执行的所以 asyncA() 调用后先打印 A1进入 asyncB 后打印 B1此时还没碰到任何异步队列。第二步await asyncB() 把恢复点打印 A2 的代码挂到微任务队列末尾同时主线程继续往下走打印 S2。第三步Promise.resolve().then 注册的回调也在主线程同步执行时进入了微任务队列而且比 A2 的恢复点更早入队。第四步本轮同步代码执行完后微任务队列按先进先出清空先打印 P1 再打印 A2。这个 demo 不接收任何参数纯粹是语法演示改代码时只需要调整 console.log 的位置就能构造新的推演题。真正容易翻车的是下面这个变体console.log(start); setTimeout(() console.log(timer), 0); Promise.resolve().then(() console.log(micro)); console.log(end); // 输出start - end - micro - timer这里的规则是每执行完一个宏任务都要先把微任务队列清空再取下一个宏任务。Promise 回调属于微任务setTimeout 属于宏任务所以哪怕 setTimeout 的延迟是 0也会排在微任务后面。事件循环模块的 docs 里把这条规则画成了表格面试手撕题目时先定「同步 → 微任务 → 宏任务」的优先级再逐行推演基本不会错。4. 从拉取到跑通环境配置、依赖安装与输出验证4.1 环境准备先确认 Node 版本再决定要不要改脚本第一步永远是确认运行环境node -v # 需要 18 及以上版本 npm -v # 确认包管理器可用node -v 的输出直接决定后面能不能用 test runner 和 ES 模块。18 以下版本跑 npm run test 会报错报错信息通常指向 node --test 不是合法命令这时候与其排查半天不如先升级 Node或者把 package.json 里的 test script 改成 node --test tests/clone.test.js 这种单文件写法。我拆包的习惯是任何资源包到手先跑 node -v两秒钟确认环境能省掉后面一大半莫名其妙的报错。这份资源包从代码托管平台整理下来是个普通目录没有构建产物解压就能用。版本没问题就直接装依赖npm install因为运行时零依赖install 过程通常几秒就结束。如果网络波动导致安装超时清掉 npm 缓存重新执行一次即可不需要改任何配置。node --test tests/ 这个命令还有个隐藏行为它会递归查找 tests/ 下所有符合命名规则的文件并并行执行文件里用 test() 函数组织用例断言失败时终端会打印具体到行的差异。4.2 一键验证全量测试与单模块演示依赖装完按下面的顺序跑验证npm run test # 跑全部测试用例 npm run verify # 逐个模块打印演示输出 node src/core/clone/index.js # 单独看某个模块的演示第一条命令走 Node 内置 test runner输出会列出每个测试文件的通过情况第二条命令由 scripts/verify.js 驱动它内部维护一个模块路径数组按顺序 import 各模块的 demo 函数把输入、输出用分隔线打印到终端。最后一条命令是单模块运行方式适合改动代码后快速看效果比如改完深拷贝直接 node 到 clone 目录的入口文件眼睛扫一遍输出就能确认行为对不对。具体验证点的预期结果如下命令验证点预期结果npm run test全量回归所有用例通过无失败项npm run verify四个核心模块演示依次输出 Promise、深拷贝、防抖、事件循环的演示结果node src/core/clone/index.js深拷贝单模块打印克隆前后对象与原始对象是否相等这里有个容易被忽略的动作verify 输出的演示结果需要和 docs 目录里的预期输出逐行对照而不是只看「有没有打印东西」。比如事件循环 demo只要有一行顺序不对就说明当前运行环境或代码改动改变了微任务时序需要按第 5 章的排查思路处理。提示如果单模块跑出来的结果和文档不一致优先检查 Node 版本和 package.json 的 type 字段绝大多数不一致都出在这两处。4.3 输出对照怎么判断模块真的跑通了verify 脚本的打印格式是固定的每个模块先打印一行分隔线再打印「演示输入 → 实际输出」。判断跑通的标准有三条实际输出与预期输出完全一致测试用例没有失败项单独 node 某个入口文件不会抛出未捕获异常。三条都满足才算通过只看「没报错」是不算数的。如果输出和预期不一致但没抛错先检查当前 Node 版本是否在 18 以上再看改动是否影响了共享模块——比如改了 utils 里的类型判断函数可能连带影响深拷贝和事件循环两个模块。单项输出对不上时优先怀疑最近一次改动而不是怀疑运行环境这是排查顺序上最基本的先后关系。5. 避坑记录手写 JS 模块最容易翻车的五个点5.1 深拷贝与 Promise 的高频翻车点翻车点一循环引用导致栈溢出。现象拷贝一个带 self 属性的对象例如 obj.self obj深拷贝函数直接抛 Maximum call stack size exceeded严重时把整个进程带崩。原因递归实现里没有记录已访问的对象A 引用 B、B 又引用 A递归永远走不完栈被撑爆。解决给递归函数加一个 Map 类型的 seen 参数每次克隆前先查缓存命中就直接返回已有克隆。3.2 节的实现已经内置了这层处理但注意 clone 的赋值顺序一定要先 seen.set(target, clone) 再递归子属性不然子属性里引用回 target 时缓存还没生效。翻车点二then 回调抛错后面的 catch 接不住。现象Promise 链中间某个 onFulfilled 里抛了异常最后的 .catch 完全没有触发错误被静默吞掉。原因then 返回的新 Promise 没有在回调执行时包 try/catch或者 onRejected 分支只处理错误却不把 reason 往下传链条在中间断掉。解决在 then 的两个分支里分别包 try/catch回调正常返回走 resolve抛错走 rejectonFulfilled/onRejected 缺省时透传参数。对照 3.1 代码逐行核对这两个分支这是手写 Promise 时最容易写漏的地方。5.2 防抖、运行与事件循环的坑翻车点三防抖用在滚动事件上页面看起来卡死了。现象给 window 绑了防抖后的 scroll 回调滚动过程中一次都不触发停住才执行视觉上以为页面没反应。原因防抖的语义是「停顿后执行最后一次」滚动期间每次触发都重置定时器回调永远等不到执行。解决滚动、mousemove 这类高频事件改走节流防抖留给输入框搜索、窗口 resize 这类「以最后一次为准」的场景。选型判断就一句只要最终一次的结果用防抖过程中就要有反馈用节流。翻车点四npm install 后运行报 Cannot use import statement outside a module。现象依赖装完node src/core/promise/index.js 直接抛 SyntaxError指向第一行 import。原因package.json 缺少 type: module 字段Node 默认按 CommonJS 解析 .js 文件import 语句在这种模式下不是合法语法。解决在 package.json 里补上 type: module如果项目不允许动这个字段把源码文件后缀改成 .mjs 同样能绕过限制。两种改法选一个改完重新跑即可。这个问题是我帮同事排查时遇到最多的一次其实不是代码问题是包配置问题。翻车点五事件循环推演结果和实际输出对不上。现象按「微任务优先」推演的打印顺序和 Node 终端里真实输出差了一两行尤其是涉及 setTimeout 嵌套时。原因Node 与浏览器的事件循环实现存在差异在宏任务嵌套、定时器与 I/O 混用的边界场景行为不完全一致Node 跨大版本也调整过微任务清空时机。解决推演时先固定运行环境确认 Node 版本再按「同步代码 → 微任务 → 宏任务」的三级优先级逐行推导定时器嵌套的题目直接在代码里用 queueMicrotask 显式控制时序而不是赌默认行为。5.3 通用排查思路先分清环境问题还是逻辑问题遇到模块跑不起来我一般按下面的顺序排查第一步看报错类型SyntaxError 大概率是 module 配置或 Node 版本问题跑一下 node -v 和 package.json 就能确认第二步看有没有堆栈有堆栈跟着最顶层文件名定位通常是空引用或类型错误第三步才轮得到逻辑问题比如输出顺序不对、触发次数不对这时候拿 docs 里的预期结果逐行对照。很多看起来像玄学的问题最后定位出来都是环境差异。所以我的习惯是任何资源包到手先把运行环境固化成文档里要求的版本再谈改代码。这一步做扎实了后面的调试时间能省一半。用上这些排查手段手写模块的调试就不再是黑匣子。6. 二次开发把它改造成你自己的前端工具底座6.1 三个可落地的改造方向方向一给手写 Promise 补齐静态方法。现在只有 resolve、reject 和 then可以加上 race、allSettled、finally每加一个方法就在 tests/promise.test.js 里补两条用例一条正常路径一条异常路径。把 A 规范里「resolve 传入 thenable 要递归展开」也补上这个包就能当教学版 Promise 库用。方向二给防抖节流增加配置项。参照常见工具库的做法给 debounce 增加 immediate 参数首次是否立即执行给 throttle 增加 trailing 参数结束边沿是否补一次执行并把参数默认值写进 docs。改造完跑一遍 verify观察连续调用场景下触发次数是否符合预期。方向三把这套「单模块 一对一测试 verify 演示」的目录结构复制到业务项目里。新写工具函数时照这个结构建目录和用例团队的公共代码会越来越好维护。6.2 改造后的验证方法改造完的验证动作固定为三步先 node 到对应模块跑演示输出确认基本行为没变再跑 npm run test 做全量回归最后跑 npm run verify逐行对照 docs 的预期输出。前两步防逻辑错误第三步防时序类问题——这类问题单测常常覆盖不到。从那以后我每次给这套件加新模块都强制走一遍「单模块验证 → 全量测试 → verify 输出对照」三步缺一步都不算改完。这个习惯帮我挡下了好几次微任务时序被改崩的翻车。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/15 19:51:57 · 阅读 1.2k JS工程实战资源包：手写Promise、深拷贝与事件循环
简介面向初学者的 GitHub 综合入门指南围绕版本控制、开源协作与 JavaScript 开发展开帮助新用户快速上手托管代码、管理项目与参与开源。压缩包共 12 个文件主要以 HTML 页面呈现辅以 JavaScript 脚本、图片及配置文件整体仅 229KB内容紧凑实用。已有 2084 人学习浏览受到一定关注。资料系统梳理了 GitHub 的核心功能包括 Git 追踪、Pull Request 代码审查、Issue 管理、Actions 自动化测试部署、Pages 静态网站托管和 Webhooks 事件触发等同时结合 JavaScript 的典型应用场景如 Node.js 后端、Electron 桌面开发和 React Native 移动开发给出具体示例与说明。此外还涉及开源许可证选择、贡献指南CONTRIBUTING.md以及 Gist 代码片段分享等细节可作为新手在 GitHub 上进行日常开发与协作的随身参考。1. 一份能直接抄的 JavaScript 工程实战资源包从源码阅读到二次开发很多开发者拿到一份 JavaScript 资源包第一反应就是 npm install 然后赶紧跑 demo结果十有八九卡在依赖缺失和语法报错上最后只能无奈关掉窗口。这份资源包的思路刚好反过来它把手写 Promise、深拷贝、防抖节流、事件循环推演这类核心机制拆成一个个独立模块每个模块都能单独运行、单独验证不依赖任何构建工具装好 Node 就能直接跑。适合两类人准备前端面试、想把 JavaScript 核心原理彻底吃透的进阶开发者以及想快速拿到一套可复用工具函数和配套测试的工程向开发者。下面我按「结构 → 核心代码 → 运行验证 → 避坑 → 二次开发」的顺序把它完整拆一遍。2. 资源包结构与技术选型读懂目录设计就掌握了主线2.1 目录设计按「一个目录一个能力」划分模块先看整体结构这是理解整个包最快的方式js-engineer-toolkit/ ├── src/ │ ├── core/ # 核心机制实现 │ │ ├── promise/ # 手写 Promise 及派生 API │ │ ├── clone/ # 深拷贝实现 │ │ ├── event-loop/ # 事件循环推演示例 │ │ └── function/ # 防抖、节流工具 │ ├── utils/ # 类型判断、格式化等通用函数 │ └── patterns/ # 设计模式示例 ├── tests/ # 与 src 一一对应的测试用例 ├── scripts/ # 一键运行与验证脚本 ├── docs/ # 设计文档与面试要点 └── package.json这份目录的核心原则是「一个目录一个能力」。promise、clone、event-loop、function 四个子目录互不引用各自包含实现文件和演示入口文件tests 目录下的文件名与 src 保持一一对应比如 src/core/clone/ 里的实现对应 tests/clone.test.js。这样设计的好处有两个读代码时不用沿着一堆 import 跳来跳去调试时也能直接定位到具体文件不需要启动整个应用。对面试准备者来说这种「一个主题一个闭环」的组织方式也方便按天推进复习。各核心模块的入口与可验证点对应关系如下目录入口文件可验证点src/core/promiseindex.js状态流转、链式调用、微任务时序src/core/cloneindex.js循环引用、Date/RegExp、Symbol 键src/core/event-loopindex.jsasync/await 输出顺序src/core/functionindex.js防抖触发次数、节流触发间隔tests 目录与 src/core 保持一对一关系tests/function 里同时覆盖防抖和节流两种场景防抖用例验证连续调用后只触发一次且参数和 this 正确透传节流用例验证高频调用被压缩到窗口内最多一次。utils 和 patterns 是补充模块不参与主链路适合作为扩展阅读——比如 utils 里的类型判断函数深拷贝内部判断对象类型时也会用到属于跨模块复用。docs 目录里放的是每块机制的设计说明包括状态流转图、执行顺序表以及面试追问的参考思路。我拆这类资源包时有个习惯先看 docs 目录有没有有就先读它再回头读代码效率比直接啃源码高不少这份资源的 docs 写得够细基本可以当复习笔记用。2.2 技术选型为什么能做到零构建直接跑先看选型总览模块选型说明运行环境Node LTS18 及以上原生支持 ES 模块无需编译语言原生 ES2015只用标准语法无额外编译步骤测试Node 内置 test runner每个模块自带验证用例依赖运行时零依赖无第三方库可整体移植这里最值得说的是「零依赖」这件事。很多开源包为了省事直接把第三方工具库引进来结果读源码时一半时间在查别人封装的实现。这个包刻意不用任何运行时依赖深拷贝、防抖、节流全部手写连断言都用 Node 内置模块。npm install 只装一个东西整个包体积基本没有变化拷到离线环境也能跑。我一般会建议如果你想把里面的代码挪到公司项目直接复制文件即可不会带着一串依赖把项目搞臃肿。package.json 里的核心配置也不复杂拆开看就三行{ type: module, scripts: { test: node --test tests/, verify: node scripts/verify.js } }type 字段声明为 module所有 .js 文件按 ES 模块解析源码里的 import/export 才能直接跑test 脚本走 Node 自带的 test runner不用装额外测试框架verify 脚本则负责逐个模块跑演示输出。这里有个常见的理解误区ES 模块不是新框架它就是 Node 原生支持的语法只要版本达标不需要任何打包器。这也是这份资源能实现「零构建直接跑」的根本原因——不是它做了多牛的工程化而是它把不必要的东西全砍掉了。版本这里要特别留意test script 依赖 Node 18 之后内置的 test runnernode --test tests/这种写法在 16 上会直接报错。如果你本机版本偏低两个选择升级 Node或者把 test script 改回node --test tests/clone.test.js这种单文件写法。我拆包时习惯先跑node -v确认环境再决定要不要动 script省得后面排查半天发现是环境问题。整体来看这份资源的技术选型思路就一句话能零依赖就零依赖能用标准语法就用标准语法把「读代码」的成本降到最低。3. 核心代码拆解手写 Promise、深拷贝与事件循环推演3.1 手写 Promise状态机加微任务是最小骨架先看核心实现完整版在源码里包含全部静态方法这里先看最关键的状态机与链式调用function MyPromise(executor) { this.state pending; // pending / fulfilled / rejected this.value undefined; // fulfilled 的终值或 rejected 的拒因 this.callbacks []; // 等待队列存放 then 注册的回调 const resolve (value) { if (this.state ! pending) return; // 状态只能变更一次 this.state fulfilled; this.value value; this.callbacks.forEach((cb) this._handle(cb)); }; const reject (reason) { if (this.state ! pending) return; this.state rejected; this.value reason; this.callbacks.forEach((cb) this._handle(cb)); }; try { executor(resolve, reject); } catch (e) { reject(e); // executor 同步抛错直接转 reject } } MyPromise.prototype._handle function (cb) { if (this.state pending) { this.callbacks.push(cb); return; } const fn this.state fulfilled ? cb.onFulfilled : cb.onRejected; queueMicrotask(() fn(this.value)); // 保证异步执行 }; MyPromise.prototype.then function (onFulfilled, onRejected) { return new MyPromise((resolve, reject) { this._handle({ onFulfilled: (value) { try { resolve(onFulfilled ? onFulfilled(value) : value); // 未传则透传 } catch (e) { reject(e); } }, onRejected: (reason) { try { resolve(onRejected ? onRejected(reason) : reason); } catch (e) { reject(e); } } }); }); };几个关键设计点拆开说。首先是状态机state 只有 pending、fulfilled、rejected 三种resolve/reject 入口处都判断「非 pending 直接 return」这就是 Promise 状态不可逆的实现——从根上杜绝了重复决议。其次是 then 的返回值then 内部 new 了一个新的 MyPromise并把 onFulfilled/onRejected 的返回值交给新 Promise 的 resolve这样链式调用才成立如果回调里抛异常会被 catch 捕获并转成新 Promise 的 reject这也是链上后面的 catch 能接住的原因。最后是微任务调度这里用 queueMicrotask 而不是 setTimeout。两者差别在于优先级——microtask 队列会在当前宏任务结束后立即清空而 setTimeout 要等下一轮宏任务。Promise 的回调必须走微任务这个顺序直接影响事件循环里 console.log 的输出时序3.3 节的推演会用到这条规则。关于参数executor 是构造时立即同步执行的回调接收 resolve、reject 两个函数onFulfilled、onRejected 分别是 then 注册的成功、失败回调都可省略省略时做透传处理。需要注意这个实现刻意省略了「resolve 传入 thenable 时递归展开」的 A 规范细节那是规范完备性问题不影响理解主流程。3.2 深拷贝与防抖节流两个高频实用手写题深拷贝实现如下function deepClone(target, seen new Map()) { if (target null || typeof target ! object) return target; if (seen.has(target)) return seen.get(target); // 循环引用直接返回已有克隆 if (target instanceof Date) return new Date(target.getTime()); if (target instanceof RegExp) return new RegExp(target.source, target.flags); if (target instanceof Map) { const cloneMap new Map(); seen.set(target, cloneMap); target.forEach((v, k) cloneMap.set(deepClone(k, seen), deepClone(v, seen))); return cloneMap; } if (target instanceof Set) { const cloneSet new Set(); seen.set(target, cloneSet); target.forEach((v) cloneSet.add(deepClone(v, seen))); return cloneSet; } const clone Array.isArray(target) ? [] : {}; seen.set(target, clone); Reflect.ownKeys(target).forEach((key) { clone[key] deepClone(target[key], seen); }); return clone; }这个实现对比常见的 JSON.parse(JSON.stringify(obj)) 方案解决了四个经典问题循环引用导致的栈溢出、Date 被序列化成字符串、RegExp 被序列化成空对象、Symbol 键被直接丢弃。实现上有三个要点。第一seen 这个 Map 参数是整个函数的核心记录「原对象 → 克隆对象」的映射遇到循环引用时命中缓存直接返回递归就不会无限走下去了。第二内置对象要分类型处理Date、RegExp、Map、Set 各自走自己的构造路径不能走普通对象遍历。第三遍历用 Reflect.ownKeys 而不是 Object.keys前者能把 Symbol 键也带上后者会丢。关于参数target 是需要克隆的任意值seen 是内部使用的缓存 Map调用方不需要传。防抖与节流的实现更短但参数语义值得说清楚// wait 毫秒内的连续调用只执行最后一次 function debounce(fn, wait 300) { let timer null; return function (...args) { clearTimeout(timer); timer setTimeout(() { fn.apply(this, args); timer null; }, wait); }; } // 每 wait 毫秒最多执行一次首次立即执行 function throttle(fn, wait 300) { let last 0; return function (...args) { const now Date.now(); if (now - last wait) { last now; fn.apply(this, args); } }; }两个函数都返回一个新函数新函数里用 this 和 args 把原函数的调用上下文完整保留。区别在触发策略debounce 每次调用都重置定时器只有停顿超过 wait 才会真正执行适合输入框搜索、窗口 resizethrottle 用时间戳对比wait 内最多执行一次适合滚动事件、mousemove 这类高频回调。参数方面fn 是目标函数wait 是间隔毫秒数默认 300。常见误用是拿防抖去做滚动节流结果「一直滚动就一直不执行」看起来像卡死。3.3 事件循环推演async/await 到底先打印谁事件循环模块里放了一组对照 demo最典型的是下面这段async function asyncA() { console.log(A1); await asyncB(); console.log(A2); // 这里是微任务恢复点 } async function asyncB() { console.log(B1); } console.log(S1); asyncA(); Promise.resolve().then(() console.log(P1)); console.log(S2); // 实际输出S1 - A1 - B1 - S2 - P1 - A2推演逻辑分四步。第一步async 函数体在第一个 await 之前是同步执行的所以 asyncA() 调用后先打印 A1进入 asyncB 后打印 B1此时还没碰到任何异步队列。第二步await asyncB() 把恢复点打印 A2 的代码挂到微任务队列末尾同时主线程继续往下走打印 S2。第三步Promise.resolve().then 注册的回调也在主线程同步执行时进入了微任务队列而且比 A2 的恢复点更早入队。第四步本轮同步代码执行完后微任务队列按先进先出清空先打印 P1 再打印 A2。这个 demo 不接收任何参数纯粹是语法演示改代码时只需要调整 console.log 的位置就能构造新的推演题。真正容易翻车的是下面这个变体console.log(start); setTimeout(() console.log(timer), 0); Promise.resolve().then(() console.log(micro)); console.log(end); // 输出start - end - micro - timer这里的规则是每执行完一个宏任务都要先把微任务队列清空再取下一个宏任务。Promise 回调属于微任务setTimeout 属于宏任务所以哪怕 setTimeout 的延迟是 0也会排在微任务后面。事件循环模块的 docs 里把这条规则画成了表格面试手撕题目时先定「同步 → 微任务 → 宏任务」的优先级再逐行推演基本不会错。4. 从拉取到跑通环境配置、依赖安装与输出验证4.1 环境准备先确认 Node 版本再决定要不要改脚本第一步永远是确认运行环境node -v # 需要 18 及以上版本 npm -v # 确认包管理器可用node -v 的输出直接决定后面能不能用 test runner 和 ES 模块。18 以下版本跑 npm run test 会报错报错信息通常指向 node --test 不是合法命令这时候与其排查半天不如先升级 Node或者把 package.json 里的 test script 改成 node --test tests/clone.test.js 这种单文件写法。我拆包的习惯是任何资源包到手先跑 node -v两秒钟确认环境能省掉后面一大半莫名其妙的报错。这份资源包从代码托管平台整理下来是个普通目录没有构建产物解压就能用。版本没问题就直接装依赖npm install因为运行时零依赖install 过程通常几秒就结束。如果网络波动导致安装超时清掉 npm 缓存重新执行一次即可不需要改任何配置。node --test tests/ 这个命令还有个隐藏行为它会递归查找 tests/ 下所有符合命名规则的文件并并行执行文件里用 test() 函数组织用例断言失败时终端会打印具体到行的差异。4.2 一键验证全量测试与单模块演示依赖装完按下面的顺序跑验证npm run test # 跑全部测试用例 npm run verify # 逐个模块打印演示输出 node src/core/clone/index.js # 单独看某个模块的演示第一条命令走 Node 内置 test runner输出会列出每个测试文件的通过情况第二条命令由 scripts/verify.js 驱动它内部维护一个模块路径数组按顺序 import 各模块的 demo 函数把输入、输出用分隔线打印到终端。最后一条命令是单模块运行方式适合改动代码后快速看效果比如改完深拷贝直接 node 到 clone 目录的入口文件眼睛扫一遍输出就能确认行为对不对。具体验证点的预期结果如下命令验证点预期结果npm run test全量回归所有用例通过无失败项npm run verify四个核心模块演示依次输出 Promise、深拷贝、防抖、事件循环的演示结果node src/core/clone/index.js深拷贝单模块打印克隆前后对象与原始对象是否相等这里有个容易被忽略的动作verify 输出的演示结果需要和 docs 目录里的预期输出逐行对照而不是只看「有没有打印东西」。比如事件循环 demo只要有一行顺序不对就说明当前运行环境或代码改动改变了微任务时序需要按第 5 章的排查思路处理。提示如果单模块跑出来的结果和文档不一致优先检查 Node 版本和 package.json 的 type 字段绝大多数不一致都出在这两处。4.3 输出对照怎么判断模块真的跑通了verify 脚本的打印格式是固定的每个模块先打印一行分隔线再打印「演示输入 → 实际输出」。判断跑通的标准有三条实际输出与预期输出完全一致测试用例没有失败项单独 node 某个入口文件不会抛出未捕获异常。三条都满足才算通过只看「没报错」是不算数的。如果输出和预期不一致但没抛错先检查当前 Node 版本是否在 18 以上再看改动是否影响了共享模块——比如改了 utils 里的类型判断函数可能连带影响深拷贝和事件循环两个模块。单项输出对不上时优先怀疑最近一次改动而不是怀疑运行环境这是排查顺序上最基本的先后关系。5. 避坑记录手写 JS 模块最容易翻车的五个点5.1 深拷贝与 Promise 的高频翻车点翻车点一循环引用导致栈溢出。现象拷贝一个带 self 属性的对象例如 obj.self obj深拷贝函数直接抛 Maximum call stack size exceeded严重时把整个进程带崩。原因递归实现里没有记录已访问的对象A 引用 B、B 又引用 A递归永远走不完栈被撑爆。解决给递归函数加一个 Map 类型的 seen 参数每次克隆前先查缓存命中就直接返回已有克隆。3.2 节的实现已经内置了这层处理但注意 clone 的赋值顺序一定要先 seen.set(target, clone) 再递归子属性不然子属性里引用回 target 时缓存还没生效。翻车点二then 回调抛错后面的 catch 接不住。现象Promise 链中间某个 onFulfilled 里抛了异常最后的 .catch 完全没有触发错误被静默吞掉。原因then 返回的新 Promise 没有在回调执行时包 try/catch或者 onRejected 分支只处理错误却不把 reason 往下传链条在中间断掉。解决在 then 的两个分支里分别包 try/catch回调正常返回走 resolve抛错走 rejectonFulfilled/onRejected 缺省时透传参数。对照 3.1 代码逐行核对这两个分支这是手写 Promise 时最容易写漏的地方。5.2 防抖、运行与事件循环的坑翻车点三防抖用在滚动事件上页面看起来卡死了。现象给 window 绑了防抖后的 scroll 回调滚动过程中一次都不触发停住才执行视觉上以为页面没反应。原因防抖的语义是「停顿后执行最后一次」滚动期间每次触发都重置定时器回调永远等不到执行。解决滚动、mousemove 这类高频事件改走节流防抖留给输入框搜索、窗口 resize 这类「以最后一次为准」的场景。选型判断就一句只要最终一次的结果用防抖过程中就要有反馈用节流。翻车点四npm install 后运行报 Cannot use import statement outside a module。现象依赖装完node src/core/promise/index.js 直接抛 SyntaxError指向第一行 import。原因package.json 缺少 type: module 字段Node 默认按 CommonJS 解析 .js 文件import 语句在这种模式下不是合法语法。解决在 package.json 里补上 type: module如果项目不允许动这个字段把源码文件后缀改成 .mjs 同样能绕过限制。两种改法选一个改完重新跑即可。这个问题是我帮同事排查时遇到最多的一次其实不是代码问题是包配置问题。翻车点五事件循环推演结果和实际输出对不上。现象按「微任务优先」推演的打印顺序和 Node 终端里真实输出差了一两行尤其是涉及 setTimeout 嵌套时。原因Node 与浏览器的事件循环实现存在差异在宏任务嵌套、定时器与 I/O 混用的边界场景行为不完全一致Node 跨大版本也调整过微任务清空时机。解决推演时先固定运行环境确认 Node 版本再按「同步代码 → 微任务 → 宏任务」的三级优先级逐行推导定时器嵌套的题目直接在代码里用 queueMicrotask 显式控制时序而不是赌默认行为。5.3 通用排查思路先分清环境问题还是逻辑问题遇到模块跑不起来我一般按下面的顺序排查第一步看报错类型SyntaxError 大概率是 module 配置或 Node 版本问题跑一下 node -v 和 package.json 就能确认第二步看有没有堆栈有堆栈跟着最顶层文件名定位通常是空引用或类型错误第三步才轮得到逻辑问题比如输出顺序不对、触发次数不对这时候拿 docs 里的预期结果逐行对照。很多看起来像玄学的问题最后定位出来都是环境差异。所以我的习惯是任何资源包到手先把运行环境固化成文档里要求的版本再谈改代码。这一步做扎实了后面的调试时间能省一半。用上这些排查手段手写模块的调试就不再是黑匣子。6. 二次开发把它改造成你自己的前端工具底座6.1 三个可落地的改造方向方向一给手写 Promise 补齐静态方法。现在只有 resolve、reject 和 then可以加上 race、allSettled、finally每加一个方法就在 tests/promise.test.js 里补两条用例一条正常路径一条异常路径。把 A 规范里「resolve 传入 thenable 要递归展开」也补上这个包就能当教学版 Promise 库用。方向二给防抖节流增加配置项。参照常见工具库的做法给 debounce 增加 immediate 参数首次是否立即执行给 throttle 增加 trailing 参数结束边沿是否补一次执行并把参数默认值写进 docs。改造完跑一遍 verify观察连续调用场景下触发次数是否符合预期。方向三把这套「单模块 一对一测试 verify 演示」的目录结构复制到业务项目里。新写工具函数时照这个结构建目录和用例团队的公共代码会越来越好维护。6.2 改造后的验证方法改造完的验证动作固定为三步先 node 到对应模块跑演示输出确认基本行为没变再跑 npm run test 做全量回归最后跑 npm run verify逐行对照 docs 的预期输出。前两步防逻辑错误第三步防时序类问题——这类问题单测常常覆盖不到。从那以后我每次给这套件加新模块都强制走一遍「单模块验证 → 全量测试 → verify 输出对照」三步缺一步都不算改完。这个习惯帮我挡下了好几次微任务时序被改崩的翻车。希望帮到你。本文还有配套的精品资源点击获取