https://plumephp.com/posts/vite/Recent content in Vite 专题：从脚手架到生产优化的现代前端构建工程化 on PlumePHPHugozh-CNTue, 29 Sep 2026 15:00:00 +0800https://plumephp.com/vite-bundle-analysis-performance/Tue, 29 Sep 2026 15:00:00 +0800https://plumephp.com/vite-bundle-analysis-performance/<h2 id="引言">引言</h2> <p>「页面变慢了」是结果，不是原因。真正的问题在于：<strong>包体为什么大、首屏为什么慢、谁在拖慢构建</strong>——这些需要「分析 + 监控 + 门禁」的体系，而不是靠感觉优化。本文讲 Vite 项目的包体分析与性能监控：先讲包体分析的价值（把「感觉」变成「数据」）、Bundle Analyzer 可视化产物（占比一目了然）、构建报告与产物统计（体积/请求/重复）、性能预算与 CI 门禁（设阈值、超限即失败，防回退）、运行时性能监控（Web Vitals/错误监控/性能数据采集）、加载性能优化闭环（分析→优化→验证→门禁）、长尾模块与按需加载（找大而用的少模块）、慢构建的定位（构建耗时与缓存）、最后是性能治理流程（从临时优化到制度化、可量化的性能文化）。</p>https://plumephp.com/vite-component-library-guide/Tue, 29 Sep 2026 14:00:00 +0800https://plumephp.com/vite-component-library-guide/<h2 id="引言">引言</h2> <p>「在应用里写组件」和「做一套可发布的组件库」是两回事：库要被 npm 安装、按需引入、类型提示、样式可控、版本演进。Vite 的**库模式（lib mode）**正是为此设计。本文讲用 Vite 开发组件库的完整流程：先讲为什么独立构建组件库（复用/一致性/独立版本）、库模式构建配置（build.lib/formats/external/多入口）、组件与样式方案（CSS 方案选择/主题变量/样式隔离）、类型声明与 dts（构建生成 .d.ts）、按需加载与 sideEffects（子路径导出与摇树）、发布 npm 流程（打包/版本/发布/发布验证）、版本管理与变更日志（语义化版本/CHANGELOG）、与 Monorepo 的整合（多包管理）、最后是组件库的调试与文档（Storybook/文档站/测试）。目标：你能从零搭建一套可发布、可按需、可维护的组件库。</p>https://plumephp.com/vite-react-architecture-patterns/Tue, 29 Sep 2026 13:00:00 +0800https://plumephp.com/vite-react-architecture-patterns/<h2 id="引言">引言</h2> <p>「React 应用能跑」和「React 应用能长期演进」是两件事。规模一大，组件散乱、状态失控、加载缓慢、维护困难全都冒出来——这需要<strong>架构模式</strong>。本文讲用 Vite 搭建 React 应用的架构：先讲三层架构（UI/状态/数据分离），再讲目录结构与模块边界（Feature-based 而非按类型堆叠）、状态管理选型（本地/全局/服务端三类状态怎么分）、路由与代码分割（懒加载路由 + 预取）、数据获取与缓存（请求层/缓存/竞态处理）、SSR/CSR 与混合渲染（什么时候上 SSR）、组件设计模式（组合/受控/Hook 抽取的纪律）、性能优化清单（渲染/包体/加载三维）、最后是与 Vite 工程化的结合（多环境/构建/部署）。目标：你能搭出「可扩展、可维护、高性能」的 React 应用架构。</p>https://plumephp.com/vite-rollup-build-pipeline/Tue, 29 Sep 2026 12:00:00 +0800https://plumephp.com/vite-rollup-build-pipeline/<h2 id="引言">引言</h2> <p><code>vite build</code> 背后是 Rollup——一个以「插件钩子」组织的打包器：从解析入口到生成产物，每个阶段都有钩子让插件介入。理解这条管线，你才知道产物为什么长这样、chunk 是怎么分的、manifest 是什么、插件该挂哪个钩子。本文讲透 Rollup 构建管线：先讲从入口到产物的完整链路（输入→模块图→chunk→产物），再讲 Rollup 插件钩子体系（build 阶段钩子 resolveId/load/transform、模块图钩子、输出阶段钩子）、解析与加载阶段（resolveId/load 的职责）、转换阶段（transform 与代码处理）、打包与代码生成阶段（图→chunk 的算法、renderChunk/generateBundle）、产物结构（chunk/asset/entry 的关系与命名）、manifest 与运行时注入（build.manifest、modulepreload）、浏览器目标与降级（build.target、legacy 插件）、最后是构建诊断（debug 日志与故障排查）。</p>https://plumephp.com/vite-tree-shaking-deep-dive/Tue, 29 Sep 2026 11:00:00 +0800https://plumephp.com/vite-tree-shaking-deep-dive/<h2 id="引言">引言</h2> <p>「打包出来的文件怎么这么大」往往是同一个原因：<strong>Tree-shaking 没生效</strong>。摇树（Tree-shaking）是 Rollup/Vite 的核心优化，能把「没用的导出」从产物里删掉，但它的生效有一整套前提：ESM 的静态分析、副作用标记、package.json 字段、代码的可摇性。本文讲透摇树：先讲原理（按使用标记 + 删除未用）、为什么必须 ESM（静态可分析，CommonJS 摇不动）、副作用标记 sideEffects（<code>&quot;sideEffects&quot;: false</code> 让包可摇）、package.json 的 exports 与 module 字段（入口该指向 ESM）、摇树的边界（动态导入/运行时/条件导入摇不掉）、常见摇树失败与排查（副作用误判/入口错误/黑魔法）、库作者的摇树优化（怎么写可摇的库）、与代码分割的配合（摇树 + 分割的组合策略）、最后是验证摇树效果（产物分析看包体）。</p>https://plumephp.com/vite-import-graph-internals/Tue, 29 Sep 2026 10:00:00 +0800https://plumephp.com/vite-import-graph-internals/<h2 id="引言">引言</h2> <p>Vite 启动快、按需加载，秘密都藏在**导入图（Import Graph）**里——一个记录「谁导入谁」的图结构，Vite 通过它知道该转换哪些文件、哪些模块是热更新边界、哪些依赖该预打包。本文讲透 Vite 的导入图与模块图内部：先讲导入图是什么（从入口递归展开的依赖映射）、模块节点（id、依赖、被依赖、模块信息）、解析流程（从裸导入 <code>react</code> 到 <code>node_modules/react/...</code> 的文件路径）、依赖追踪（静态分析 import 语句与动态 import）、模块图与转换流水线的协作（转换与依赖收集的关系）、动态导入与图的惰性扩展（为什么首屏只加载用到的）、模块图与 HMR 边界（为什么热更新要沿导入图传播）、图的内存与性能优化、最后是调试模块图的工具与实践（<code>vite debug</code>、插件钩子、可视化）。</p>https://plumephp.com/vite-dev-server-proxy-backend-integration/Mon, 28 Sep 2026 15:00:00 +0800https://plumephp.com/vite-dev-server-proxy-backend-integration/<h2 id="引言">引言</h2> <p>前端开发时浏览器直接请求 <code>https://api.example.com/...</code> 会遇到三座大山：<strong>跨域</strong>（CORS）、<strong>环境地址混乱</strong>、<strong>后端还没就绪</strong>。Vite 的 <code>server.proxy</code> 让 Dev Server 扮演「中间人」：前端只请求<strong>同源</strong>路径（<code>/api/...</code>），Dev Server 把它转发给真实后端，顺带处理重写、WebSocket 与多个目标。配合本地 Mock，前端可以不依赖后端进度独立开发。本文把代理与联调做成一套标准工作流。</p>https://plumephp.com/vite-runtime-performance-optimization/Mon, 28 Sep 2026 14:00:00 +0800https://plumephp.com/vite-runtime-performance-optimization/<h2 id="引言">引言</h2> <p>「构建很快」不等于「用户打开很快」。Vite 负责把代码变成产物，而<strong>用户感知的性能</strong>由加载策略、缓存、资源优先级与运行时开销共同决定。本文聚焦<strong>运行期</strong>：产物如何被浏览器更快地加载与执行——代码分割与按路由懒加载、preload 资源优先级、长缓存策略、LCP/INP 的优化路径、性能预算与 RUM 监控。目标是把「构建期快」翻译成「首屏快、交互顺、缓存命中高」的用户体验。</p>https://plumephp.com/vite-containerized-docker-builds/Mon, 28 Sep 2026 13:00:00 +0800https://plumephp.com/vite-containerized-docker-builds/<h2 id="引言">引言</h2> <p>把 Vite 应用部署到生产，最干净的形态是「一个可复现的镜像」：<code>docker build</code> 出包含构建产物 + 静态服务器的镜像，随处可跑、可回滚、可审计。但 Docker 用不好就成了灾难——每次构建全量重装依赖、镜像几个 GB、层缓存失效。本文用 <strong>多阶段构建</strong> 把「构建」与「运行」分离，用 <strong>依赖层缓存</strong> 让 CI 秒级复用，用 <strong>nginx 配置</strong> 处理好 SPA 路由与缓存，最后给出体积优化与安全加固清单。</p>https://plumephp.com/vite-security-csp-hardening/Mon, 28 Sep 2026 12:00:00 +0800https://plumephp.com/vite-security-csp-hardening/<h2 id="引言">引言</h2> <p>前端安全经常被忽视——直到线上被打穿。Vite 项目的基础设施（构建、依赖、产物）本身就构成攻击面：<strong>依赖被投毒、构建脚本被篡改、产物泄漏源码、内联脚本被注入</strong>。本文不重复「别写 XSS」的老话，而是聚焦<strong>构建层与配置层</strong>的安全加固：CSP 的正确配置（含 nonce）、依赖供应链的锁与扫、产物的敏感信息治理，以及开发/生产两套环境的策略差异。目标是让「安全」成为 Vite 工程的一部分，而不是事后补丁。</p>https://plumephp.com/vite-sourcemap-deep-dive/Mon, 28 Sep 2026 11:00:00 +0800https://plumephp.com/vite-sourcemap-deep-dive/<h2 id="引言">引言</h2> <p>压缩后的生产 JS 一行几千字符，报错堆栈却是 <code>main.abc123.js:1:12345</code>——没有 source map 这行错误毫无意义。<strong>Source Map</strong> 把「压缩后的位置」映射回「源码的位置」，是调试与线上可观测性的基石。它不复杂，但总被误解：为什么有 <code>//# sourceMappingURL</code>？<code>mappings</code> 里的乱码是什么？<code>hidden</code> 模式有什么用？上线到底该不该带上 source map？本文将把 source map 从字节级原理到工程策略讲透。</p>https://plumephp.com/vite-ci-cd-optimization/Mon, 28 Sep 2026 10:00:00 +0800https://plumephp.com/vite-ci-cd-optimization/<h2 id="引言">引言</h2> <p>Vite 的「快」不只体现在本地开发，<strong>在 CI 里同样可以通过缓存与并行把构建压到几十秒</strong>。但 CI 环境与本地不同——没有 <code>node_modules</code>、没有 <code>.vite</code> 缓存、依赖每次重新安装。本文系统讲 Vite 项目的 CI/CD：先搭一条标准的 GitHub Actions 流水线（安装 → 测试 → 构建 → 部署），再给依赖缓存、构建缓存与分片并行的优化手段，接着讲产物交付（带 hash 的构建产物如何部署到 Vercel / Netlify / GitHub Pages / 对象存储），最后给构建失败排查清单。</p>https://plumephp.com/vite-hmr-internals/Mon, 28 Sep 2026 10:00:00 +0800https://plumephp.com/vite-hmr-internals/<h2 id="引言">引言</h2> <p>HMR（Hot Module Replacement，热模块替换）是 Vite 开发体验的灵魂——改一行代码，浏览器<strong>不刷新</strong>就更新。但它并非魔法：底层是「模块图 + WebSocket + 边界 accept」。本文从原理讲透 HMR：先拆解一次热更新的完整链路（改文件 → 依赖图计算 → 增量更新 → 边界执行），再讲框架如何自动 accept、手写 <code>import.meta.hot</code> 自定义热更新、插件侧实现 HMR，最后给出 HMR 失效排查与性能优化，让你从「用 HMR」进阶到「掌控 HMR」。</p>https://plumephp.com/vite-worker-wasm/Mon, 28 Sep 2026 10:00:00 +0800https://plumephp.com/vite-worker-wasm/<h2 id="引言">引言</h2> <p>浏览器主线程不能阻塞——<strong>重计算要么分片、要么扔进 Worker</strong>，而 WASM 能把这些计算跑得接近原生。Vite 对这两者都有<strong>第一方支持</strong>：Worker 自动打包、WASM 直接 import。本文讲透组合拳：先讲 Vite 原生 Worker 的三种写法（<code>?worker</code>、<code>new URL</code>、动态 import）与代码分割，再讲<strong>模块 Worker</strong>（共享 import 与依赖、避免重复打包），接着讲 Worker 池与通信设计（Transferable、共享内存）、WASM 在 Vite 的加载姿势（<code>?url</code> + <code>instantiateStreaming</code>、async）、Worker + WASM 的组合模式（图片处理/加密/编解码），最后给性能权衡与决策（线程 vs 内存 vs 传输）。</p>https://plumephp.com/vite-dependency-pre-bundling/Mon, 28 Sep 2026 10:00:00 +0800https://plumephp.com/vite-dependency-pre-bundling/<h2 id="引言">引言</h2> <p>Vite 启动时会对 <code>node_modules</code> 里的依赖做一次「预构建」——这是它比传统 bundler 启动快的关键。预构建解决两个问题：<strong>① 兼容 CJS/老包（把 CommonJS 转成 ESM）② 性能（把分散的依赖合并成少量大模块，减少请求数）</strong>。本文讲透预构建：先拆解 esbuild 扫描与打包的完整流程，再给 <code>optimizeDeps</code> 配置实战（include/exclude/force），接着讲缓存失效与 <code>.vite</code> 目录管理，最后覆盖 Monorepo、链接包与动态导入的预构建疑难。</p>https://plumephp.com/vite-dev-server-internals/Mon, 28 Sep 2026 10:00:00 +0800https://plumephp.com/vite-dev-server-internals/<h2 id="引言">引言</h2> <p>Vite 最大的卖点是「启动快、HMR 快」——它的秘诀不是魔法，而是一套清晰的架构：<strong>开发服务器不打包，只转换</strong>。浏览器原生请求 ESM 模块，Dev Server 按需把每个模块「原地转换」后返回，模块之间靠浏览器自己解决依赖。这个设计背后是 Connect 中间件管线、模块图（Module Graph）、转换管道与 WebSocket 协作。理解这些内部机制，你才能解决「为什么我改了不生效」「为什么启动还是慢」「为什么这个文件 HMR 失效」。</p>https://plumephp.com/vite-devtools-debugging/Mon, 28 Sep 2026 10:00:00 +0800https://plumephp.com/vite-devtools-debugging/<h2 id="引言">引言</h2> <p>Vite 报错时最常见的反应是&quot;重启 dev server&quot;——但很多问题重启也没用：<strong>依赖预构建失效、别名没生效、HMR 不更新、sourcemap 对不上</strong>。本文给一套 Vite 调试工具箱：先讲 dev server 的调试开关（<code>--debug</code>、<code>--host</code>、端口、<code>vite</code> 日志级别），再讲<strong>构建调试</strong>（<code>vite build --debug</code>、产物分析、<code>--sourcemap</code>），接着讲浏览器侧的 sourcemap 与依赖网络、依赖解析问题的定位（预构建目录、<code>optimizeDeps</code>、别名、<code>resolve.alias</code>），再讲 HMR 不更新、性能慢（启动/热更新耗时）的定位法，最后给常见报错的系统排查清单。</p>https://plumephp.com/vite-micro-frontend/Mon, 28 Sep 2026 10:00:00 +0800https://plumephp.com/vite-micro-frontend/<h2 id="引言">引言</h2> <p>多个团队各自独立开发、独立部署，再组合成一个完整应用——<strong>微前端</strong>解决的是&quot;组织分工&quot;而非&quot;技术炫技&quot;。Vite 的<strong>原生 ESM 架构</strong>让微前端比 webpack 时代更顺滑：不需要运行时打包器，可以直接共享模块。本文从诉求出发，讲清三种主流方案的取舍（<strong>Module Federation</strong>、<strong>qiankun</strong>、<strong>import maps</strong>），给出 Vite + Module Federation 的完整配置，再讲 qiankun 与 Vite 的兼容坑（这是 Vite 微前端最常踩的点），接着讲样式/路由隔离与共享依赖的版本策略，最后给构建与部署的最佳实践。</p>https://plumephp.com/vite-build-cache/Mon, 28 Sep 2026 10:00:00 +0800https://plumephp.com/vite-build-cache/<h2 id="引言">引言</h2> <p>Vite 的&quot;快&quot;很大程度建立在<strong>缓存</strong>上：依赖预构建缓存、esbuild 缓存、Rollup 的模块图缓存——但缓存用错就会<strong>命中了不该命中的、失效了不该失效的</strong>。本文把 Vite 的缓存体系拆开：先讲三层缓存的职责与存放位置（<code>node_modules/.vite</code>、<code>node_modules/.cache</code>、内存），再讲<strong>命中与失效判定</strong>（为什么改了 package.json 缓存就没了、为什么没改却没命中），接着讲生产构建缓存的现实（<code>vite build</code> 每次重跑 vs 增量工具）、CI 里的持久化缓存配置（关键！见 /vite-ci-cd-optimization/）、常见坑（<code>.vite</code> 被误清、缓存目录进 Git），最后给一套缓存治理清单。</p>https://plumephp.com/vite-framework-integration/Mon, 28 Sep 2026 10:00:00 +0800https://plumephp.com/vite-framework-integration/<h2 id="引言">引言</h2> <p>Vite 能成为各框架的「默认构建器」，靠的是<strong>框架插件把 Vite 的通用能力转译成框架语法</strong>——<code>.vue</code> 单文件、JSX/TSX、<code>.svelte</code> 组件、Solid 的响应式编译。本文系统讲框架集成：先说明框架插件做什么（语法转译 + HMR 注入 + 配置预设），再逐个拆解 React / Vue / Svelte / Solid 的集成要点与常见坑，最后给出「选框架插件 + 从零集成」的决策清单，让你能快速为任何框架搭好 Vite 工程。</p>https://plumephp.com/vite-vitest-testing/Mon, 28 Sep 2026 10:00:00 +0800https://plumephp.com/vite-vitest-testing/<h2 id="引言">引言</h2> <p>测试是前端工程化的最后一公里。Vitest 由 Vite 团队打造，<strong>直接复用 Vite 的配置、转换与模块图</strong>——无需另起炉灶就能为你的 Vite 项目配好单元测试、组件测试与 E2E 测试。本文按「单测 → 组件测 → E2E」三层递进：先讲 Vitest 的核心能力（断言、参数化、快照、Mock），再讲 Vue/React 组件测试的挂载与交互，最后用 Playwright 打通浏览器端到端链路，并给出覆盖率与 CI 集成方案。</p>https://plumephp.com/vite-compatibility-legacy/Mon, 28 Sep 2026 10:00:00 +0800https://plumephp.com/vite-compatibility-legacy/<h2 id="引言">引言</h2> <p>&ldquo;为什么老 IE/旧浏览器打开是白屏？&quot;——Vite 默认的 <code>build.target</code> 是 <strong>现代浏览器</strong>（原生 ESM、较新语法），意味着<strong>旧浏览器直接打不开</strong>。本文讲清 Vite 的兼容策略：先讲 <code>build.target</code> 与 esbuild 转译的关系（Vite 到底&quot;降级&quot;了什么、没降级什么），再讲现代 vs 遗留的<strong>双构建方案</strong>（<code>@vitejs/plugin-legacy</code>：给新浏览器发新包、给老浏览器发兼容包），接着讲 polyfill 的取舍（core-js、Polyfill.io、按需注入），最后给 browserslist 配置、兼容性测试方法（caniuse/真实设备）与一套决策清单。</p>https://plumephp.com/vite-env-production-best-practices/Mon, 28 Sep 2026 10:00:00 +0800https://plumephp.com/vite-env-production-best-practices/<h2 id="引言">引言</h2> <p>把 Vite 项目从「本地跑通」推到「生产稳跑」，绕不开三个工程问题：<strong>① 环境变量怎么按环境切分（开发/测试/生产/灰度）② 构建模式与 base 路径怎么配（子路径部署、CDN）③ 产物怎么优化（体积、加载、缓存）</strong>。本文以这三个问题为主线，讲透 <code>import.meta.env</code> 的完整体系、<code>.env</code> 文件与模式、<code>vite build</code> 的模式差异、sourcemap 与产物分析，最后给出一套可落地的生产构建最佳实践清单。</p>https://plumephp.com/vite-asset-processing/Mon, 28 Sep 2026 10:00:00 +0800https://plumephp.com/vite-asset-processing/<h2 id="引言">引言</h2> <p>Vite 里的静态资源（图片、字体、SVG、Worker）有一套<strong>看似自动、实则有很多开关</strong>的处理管线：为什么小图会被内联成 Base64、大图会被加 hash、<code>public/</code> 下的文件又完全不处理？本文把 Vite 的资产管线讲透：先讲 <code>assetsInlineLimit</code> 与资源哈希的内联/外链决策，再讲图片的正确姿势（<code>publicDir</code> vs <code>import</code>、懒加载、压缩），接着讲字体（格式、子集化、<code>font-display</code>）、SVG（文件 vs 组件 vs 雪碧图）、Worker 的加载（<code>new Worker</code> 的 Vite 原生支持、模块 Worker），最后给一套资源治理清单与常见排查。</p>https://plumephp.com/vite-ssr-frameworks/Sun, 27 Sep 2026 10:00:00 +0800https://plumephp.com/vite-ssr-frameworks/<h2 id="引言">引言</h2> <p>SPA 的「白屏等待 JS」让首屏体验与 SEO 始终受制于客户端渲染。Vite 之所以成为新一代全栈框架的地基，正是因为它原生支持 <strong>SSR（服务端渲染）</strong>——开发期以模块图为驱动提供即时的 SSR + HMR，生产期把同一套源码编译为服务端可执行的 bundle。</p>https://plumephp.com/vite-monorepo-architecture/Sun, 27 Sep 2026 10:00:00 +0800https://plumephp.com/vite-monorepo-architecture/<h2 id="引言">引言</h2> <p>当组织内有多个前端应用（管理后台、官网、营销页），且它们共享组件库、工具函数、类型定义时，<strong>Monorepo</strong> 是公认的工程解。但 Monorepo + Vite 组合也有自己的坑：共享包是「源码」还是「产物」？依赖预构建如何避免重复？多应用并行构建如何隔离与缓存？</p>https://plumephp.com/vite-plugin-development/Sun, 27 Sep 2026 10:00:00 +0800https://plumephp.com/vite-plugin-development/<h2 id="引言">引言</h2> <p>当 Vite 的配置选项无法满足团队的自定义构建需求时，<strong>插件（Plugin）</strong> 是唯一的正解。无论是注入构建信息、自动生成路由、解析自定义文件格式，还是拦截与改写模块源码，插件的钩子体系都提供了标准化的接入点。理解插件机制，是「会用 Vite」到「掌控 Vite」的分水岭。</p>https://plumephp.com/vite-build-optimization/Sun, 27 Sep 2026 10:00:00 +0800https://plumephp.com/vite-build-optimization/<h2 id="引言">引言</h2> <p>开发体验的「快」由 esbuild 与原生 ESM 带来，而生产质量的「优」则由 <strong>Rollup 构建管线</strong>兑现。很多项目「能跑」但首屏缓慢、加载过多请求、chunk 巨大——根因往往是对构建优化策略的理解不足。Tree Shaking 不是默认魔法，代码分割也不是随便写个 <code>manualChunks</code> 就完事。</p>https://plumephp.com/vite-config-guide/Sun, 27 Sep 2026 10:00:00 +0800https://plumephp.com/vite-config-guide/<h2 id="引言">引言</h2> <p>Vite 的「零配置可用」是一种体验，而真正让一个项目适应不同团队、不同环境、不同部署拓扑的，是它<strong>灵活而分层</strong>的配置体系。很多人把 <code>vite.config.ts</code> 当成一份「抄来的样板」，遇到代理失效、环境变量注入失败、生产路径不对时只能靠猜。</p>https://plumephp.com/vite-scaffold-engineering/Sun, 27 Sep 2026 10:00:00 +0800https://plumephp.com/vite-scaffold-engineering/<h2 id="引言">引言</h2> <p>新建一个前端项目的瞬间，开发者通常面临两难：手动搭脚手架要面对「配置地狱」，而全盘依赖模板又容易得到一个难以维护的黑盒。<strong>Vite 的 create-vite</strong> 提供了一条中间路径——它足够快、足够小，生成的骨架几乎无配置即可运行，同时又足够透明，让开发者可以一步步理解并改造它。</p>