https://mr-pardon.github.io/Mr_Pardon-Blog/A personal blog about technology, or maybe others. 2026-03-27T16:16:32+08:00 https://mr-pardon.github.io/Mr_Pardon-Blog/ Jekyll © 2026 /Mr_Pardon-Blog/assets/img/favicons/favicon.ico /Mr_Pardon-Blog/assets/img/favicons/favicon-96x96.png 2026-02-06T10:00:00+08:00 2026-02-06T10:00:00+08:00 https://mr-pardon.github.io/Mr_Pardon-Blog/posts/Vite-Dev-Server%E5%86%85%E9%83%A8%E6%9C%BA%E5%88%B6(%E4%B8%80)/

引言：从“运行时模型”走向“内部实现” 在上一篇文章中我们已经建立起了Vite Dev Server运行时模型的整体认知： 浏览器驱动模块加载 Dev Server 按请求即时转换源码 构建行为被拆散进一次次模块请求之中 从本篇文章开始，我们将深入Vite Dev Server内部机制，去探究一个更基本的问题: 当浏览器请求一个模块时，Vite Dev Server内部发生了什么 这一过程并非是简单的从“读取”到直接“编译转换”，而是一条由插件系统、模块解析机制与缓存机制共同协作构成的“模块处理管线”(TransfromPipeline)。完整的理解这一过程，需要从浏览器请求一个模块开始，逐步分析Vite Dev Server内部的每个组件是如何协同工作的。 一次模块请求，是如何进入“模块处理管线”的？ 在正式拆解模块处理管线之前，我们需要先简单了解...

2026-01-30T10:00:00+08:00 2026-01-30T10:00:00+08:00 https://mr-pardon.github.io/Mr_Pardon-Blog/posts/Vite-Dev-Server%E7%9A%84%E8%BF%90%E8%A1%8C%E6%97%B6%E6%A8%A1%E5%9E%8B/

引言: 从“构建工具”到“运行时系统” 在上一篇文章《为什么Vite能这么快》里面，我们已经对Vite的定位已经有了一个十分清晰的认识，其核心能力在于在合适的阶段中选择合适的“执行模型”: 开发阶段：由浏览器主导模块系统，工具只做最小必要的代码转换 生产阶段：由构建工具接管全局视角，完成针对于对应环境的静态优化 这意味着在开发阶段，Vite 不再存在一个集中式、预先完成的构建阶段，取而代之的是一个持续运行的由浏览器驱动、以模块为单位运作的运行时供给系统。 本篇文章开始，我们将深入探究Vite在开发阶段的运行时模型(Vite Dev Server)，明白Vite是如何在“不打包，不构建”的情况下，让整套运行时系统成为浏览器的起点的。 一、重新理解 Dev Server: 不再作为“托管者” 在传统构建工具体系中，构建行为与开发服务器(Dev Server)是明确...

2026-01-23T10:00:00+08:00 2026-01-23T10:00:00+08:00 https://mr-pardon.github.io/Mr_Pardon-Blog/posts/%E4%B8%BA%E4%BB%80%E4%B9%88-Vite-%E8%83%BD%E8%BF%99%E4%B9%88%E5%BF%AB/

引言：Vite 究竟快在哪里？ 在Vite出现之前，开发者对于“启动一个前端项目”的心理预期往往是： 运行项目 → 等待一次完整构建 → 页面呈现 而 Vite 的出现，第一次让人产生了一种反直觉的体验：项目几乎是秒启动的，并且热更新也非常的快。这种体验差异并不是来自某个单点优化，而是源于 Vite 对“开发阶段构建模型”的彻底重构。 要确切理解Vite如此“快”缘由，关键不在于理解“它做了什么”，而在于理解相对于传统构建工具而言，它“不做了什么”。 一、Webpack Dev的设计初衷与成功模型 在进入Vite之前，我们首先需要明晰传统构建工具的设计初衷。 Webpack、Rollup等传统构建工具从设计上并不服务于“快启动”，而是为了： 生成可部署的生产代码 兼容复杂的模块系统 在一次构建中完成所有分析、转换与合并 它们的设计理念在于：...

2026-01-16T10:00:00+08:00 2026-01-16T10:00:00+08:00 https://mr-pardon.github.io/Mr_Pardon-Blog/posts/%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3%E5%89%8D%E7%AB%AF%E6%9E%84%E5%BB%BA%E5%B7%A5%E5%85%B7%E7%9A%84%E6%9C%AC%E8%B4%A8/

引言: 构建工具在解决什么问题？ 在现代前端工程体系中，Vite、Webpack、Rollup 等构建工具几乎已经成为项目的基础设施。它们承担了模块解析、依赖管理、代码转换与产物生成等一系列工作，使复杂的前端应用得以稳定的运行。 然而在实际的开发过程中，这些工具更多是以“配置”的形式存在。我们通过调整对应的参数，安装插件，执行构建命令，使得项目得以顺利的运行。然而在这个过程中，却很少有机会从原理层面理解它们的工作方式。这也导致一个问题经常被忽略： 构建工具究竟在构建什么？它解决了什么核心问题？ 如果仅仅停留在“代码打包”这一层面，我们很难去理解不同构建工具之间的差异，也无法真正理解其设计上的核心职责与所作的取舍。 要真正弄清楚这一问题，需要回到构建工具底层的三个核心概念： 模块（Module） 抽象语法树（AST） Bundle（最终产物） 构建...