Webpack 在前端构建里统治了很多年但它的冷启动速度和配置心智一直是痛点。这次我们直接换一套思路TypeScript 写源码tsup 打包库Vite 接管开发服务器Rolldown 作为下一代的构建内核。这套组合拳最大的价值不是“取代 Webpack”这个口号而是把打包这件事拆成三块各干各的底层用 Rust 提速中间层保持 Rollup 生态兼容上层业务代码开发直接用 Vite 的 ESM 开发服务器。如果你正在被 Webpack 的编译速度和复杂配置消耗耐心这篇文章可以接着往下看。先说结论这套方案适合三类人。第一类是维护工具库、组件库、SDK 的开发者tsup 可以用极简配置产出 ESM/CJS/d.ts第二类是业务应用团队想用 Vite 提升开发体验又对后续 Rolldown 的生态兼容性保持关注第三类是正在做构建工具选型想提前评估新工具链的架构师。本文会从核心能力拆解开始依次走完整的环境准备、安装部署、功能测试、产物分析、性能观察和问题排查流程最后给出迁移和落地建议。整个过程不需要写一行 Webpack 配置也不需要处理复杂的 loader 链。1. 核心能力速览在动手之前先把这套组合拳的能力边界和适用场景整理清楚。能力项说明项目类型前端应用 JavaScript/TypeScript 库构建主要工具TypeScript、tsup、Vite、Rolldown通过 rolldown-vite 接入tsup 定位基于 esbuild 的 TS/JS 库打包器零配置产出 ESM、CJS、d.tsVite 定位开发服务器 应用打包基于原生 ESM按需编译Rolldown 定位Rust 重写的 Rollup 内核兼容 Rollup 插件生态可替代 Vite 底层打包器典型功能库模式双格式输出、Tree Shaking、代码分割、HMR、sourcemap、压缩混淆环境要求Node.js LTS建议 18 或 20包管理器可用 pnpm/npm/yarn启动方式命令行启动通过 package.json scripts 管理无需 GUI是否支持批量任务支持tsup 支持多入口批量构建CI 环境中可配合 pnpm -r 串行/并行执行是否提供 API不直接提供 HTTP 接口但提供 Node.js 编程式 APIbuild 函数可集成到脚本适合场景库开发、组件库构建、应用开发环境、构建工具选型评估不适合场景需要复杂 Webpack loader 链的存量大型应用需要深度定制打包流程的老项目需要强调一点Rolldown 在材料中属于新一代构建内核它的核心策略是“兼容 Rollup API但用 Rust 重写性能关键路径”。所以它不是从零设计的全新工具而是在保留生态兼容的前提下做性能替换。这决定了它的迁移成本相对可控但仍然要以实际项目验证为准。2. 适用场景与使用边界把这套组合拳放进实际工作流能解决的技术问题集中在四个方面。第一库打包配置爆炸的问题。维护一个 TS 工具库通常要同时考虑 ESM 输出、CJS 输出、类型声明文件、sourcemap、压缩产物。在 Webpack 时代这些需求往往需要一堆 loader 和插件换成 tsup 之后入口路径和格式声明就能覆盖大部分场景。第二开发冷启动慢的问题。Vite 的核心优势是开发服务器按需编译浏览器请求哪个模块Vite 才编译哪个模块而不是一次性构建整个项目。第三构建效率的长期担忧。Rolldown 用 Rust 重写 Rollup核心思路是用性能换时间它保留了 Rollup 的插件机制降低团队迁移时的生态摩擦。第四类型安全的工程化链路。整条工具链从源码到产物都围绕 TypeScript 展开api-extractor 之类的辅助工具也可以接进来做类型声明收敛。但使用边界同样要清楚。存量大型应用如果深度依赖 webpack 的 html-webpack-plugin、image-webpack-loader、自定义 DefinePlugin 逻辑或者有一批老旧的 webpack loader这套组合拳不建议一步到位迁移。它的切入路径更稳妥的是从“新模块、新库、新服务”开始逐渐替换边界而不是大爆炸式重写。业务应用从 Vite 切换到底层 rolldown-vite 时也需要关注依赖版本和插件兼容性。合规层面也要提一句构建工具和生成的代码都是开源依赖的组合上线前要做依赖许可检查尤其当产物对外分发时。项目内如果有设计素材、图片、字体等资源注意授权边界。这些和构建速度无关但属于工程化落地的必要条件。3. 环境准备与前置条件在跑通整套流程之前先检查本机环境。下面是一份通用清单具体版本号需要按你的实际系统确认。检查项要求操作系统Windows / macOS / Linux 均可命令行工具需正常工作Node.js建议使用 LTS 版本18 或 20如果使用 pnpm注意 pnpm 与 Node 版本匹配包管理器pnpm、npm、yarn 任选其一本文示例使用 pnpmGit可选用于版本管理不影响构建流程终端与权限需要能在项目目录执行依赖安装和构建命令磁盘空间需要预留 node_modules 空间依赖安装量不大但版本较多环境检查完成后初始化一个实验项目。目录结构建议保持干净方便后面观察不同构建工具的产物差异。# 创建项目目录并进入 mkdir build-toolbox-demo cd build-toolbox-demo # 初始化 package.json使用 -y 跳过交互 npm init -y如果你打算用 pnpm需要先开启全局工具# 安装 pnpm按需执行 npm install -g pnpm关于 Node 版本如果本机装了多个版本推荐用 nvm 或 fnm 管理。项目内部也可以加入 .nvmrc固定团队开发环境。# 固定 Node 版本示例按实际版本调整 echo 20 .nvmrc然后安装基础依赖。这里先安装 TypeScript、tsup、Vite后续测试 rolldown-vite 时再单独安装。# 使用 pnpm 安装依赖 pnpm add -D typescript tsup vite如果项目已有 package.json并且里面有旧的 webpack 相关依赖本文的示例从零开始不做迁移兼容说明。先在一个干净环境验证工具链再考虑迁移。4. 安装部署与启动方式这一步把四种工具串成一条可运行链路。我们先给项目一个最小可运行配置再做验证。4.1 初始化 TypeScript 配置创建 tsconfig.json。这里的关键是模块解析策略和声明文件输出。tsup 会读这个配置来生成 d.ts 文件。{ compilerOptions: { target: ES2020, module: ESNext, moduleResolution: Bundler, strict: true, declaration: true, esModuleInterop: true, skipLibCheck: true, forceConsistentCasingInFileNames: true }, include: [src], exclude: [node_modules, dist] }tsup 在打包时会自动使用 tsconfig.json生成类型声明文件时也依赖这里的 declaration 配置。需要注意的是moduleResolution 使用 Bundler 模式在现代构建工具中更常见但如果你需要兼容老版本 Node可能需要调整为 Node16 等更保守的模式。4.2 编写一个待打包的 TS 模块在 src 目录下创建一个函数库示例包含类型定义和工具函数方便后面验证 ESM、CJS、d.ts 三种产物。// src/index.ts export interface UserInfo { id: string; name: string; email: string; } export function formatUserName(user: UserInfo): string { return ${user.name} ${user.email}; } export function isEmailValid(email: string): boolean { const emailRegex /^[^\s][^\s]\.[^\s]$/; return emailRegex.test(email); }4.3 配置 tsup 库打包创建 tsup.config.ts。这里写上多入口、双格式输出、d.ts 生成、sourcemap 等常见库发布需求。// tsup.config.ts import { defineConfig } from tsup; export default defineConfig({ entry: [src/index.ts], format: [esm, cjs], dts: true, sourcemap: true, clean: true, treeshake: true, splitting: false, outDir: dist, });这个配置的含义入口是 src/index.ts同时输出 ESM 和 CJS生成类型声明文件保留 sourcemap每次构建前清空 dist开启 tree shaking。配置完成后在 package.json 里添加脚本。{ scripts: { build:lib: tsup, dev:app: vite, build:app: vite build, typecheck: tsc --noEmit } }4.4 启动 Vite 开发服务器在项目根目录创建 index.html 和 src/main.ts作为应用入口。这里的 main.ts 可以直接引用刚才的库模块。!-- index.html -- !DOCTYPE html html langzh-CN head meta charsetUTF-8 / titleBuild Toolbox Demo/title /head body div idappBuild Toolbox Demo/div script typemodule src/src/main.ts/script /body /html// src/main.ts import { formatUserName, isEmailValid, type UserInfo } from ./index; const user: UserInfo { id: 1, name: Alice, email: aliceexample.com, }; const app document.querySelectorHTMLDivElement(#app); if (app) { app.innerHTML pUser: ${formatUserName(user)}/p pEmail valid: ${isEmailValid(user.email)}/p ; }接下来启动 Vite 开发服务器pnpm dev:app启动后终端会输出本地访问地址默认是 http://localhost:5173。打开浏览器如果页面上能看到 Alice 的用户信息和邮箱校验结果说明 TS 模块已经被 Vite 正确编译并加载。4.5 接入 Rolldown 内核Rolldown 目前最常见的接入方式是通过 rolldown-vite。它是对 Vite 的一层替换把内部打包器从 Rollup 换成 RolldownAPI 设计上尽量保持兼容。先安装再切换。pnpm add -D rolldown-vite在没有具体版本要求的情况下可以先看看安装后的 rolldown-vite 包版本然后通过以下方式启动测试。如果你希望保留原来的 Vite可以用参数切换。更简单的方式是直接在 package.json 里加一条脚本。{ scripts: { dev:rolldown: rolldown-vite, build:rolldown: rolldown-vite build } }启动命令pnpm dev:rolldownrolldown-vite 在启动时会加载项目根目录的 vite.config.ts接口风格与 Vite 基本一致。如果项目里没有复杂插件通常不需要改动配置就能跑起来。这里的关键验证点是开发服务器是否正常启动、页面是否正常访问、构建产物是否正常输出。启动后看到和 Vite 一致的地址输出就说明内核替换没有破坏基本链路。5. 功能测试与效果验证工具链跑通之后需要做系统的功能验证。不能只看“能启动”还要验证产物质量、开发体验、配置生效情况。5.1 测试 tsup 库构建执行构建命令。pnpm build:lib构建完成后检查 dist 目录预期会出现这些文件dist/ index.js index.cjs index.d.ts index.js.map index.cjs.map验证点有三个。第一index.js 是 ESM 格式文件内容里不应该出现 require而是使用 import/export第二index.cjs 是 CommonJS 格式应该使用 require 和 module.exports第三index.d.ts 文件里应该能导出 UserInfo 接口和两个函数的类型声明。如果这三项都符合说明库模式构建成功。5.2 测试 Vite 应用构建执行应用构建。pnpm build:app构建完成后检查 dist 目录预期会出现 assets 目录和 index.html。assets 里是经过压缩的 JS 文件页面入口被正确引用。Vite 默认生成的 JS 文件名带有 hash用于浏览器缓存。如果 index.html 中能正确引用 assets 目录下的 JS 文件说明产物有效。验证方式可以执行npx vite preview然后访问终端输出的地址页面应该和开发环境一样显示用户信息。5.3 测试 rolldown-vite 构建执行构建命令观察是否使用 Rolldown 内核完成打包。pnpm build:rolldown构建完成后同样检查 dist 目录。这里最重要的是观察产物是否正常生成页面能否用 preview 服务正确访问。如果项目配置了 vite.config.ts还需要确认其中的插件和别名在这个内核下是否仍然生效。5.4 测试 TypeScript 类型检查构建工具的配置可以很顺滑但类型错误是另一回事。单独执行类型检查。pnpm typecheck如果代码有类型错误这里会直接报错。这一步可以和 CI 集成作为提交前的检查项。它的价值是让构建工具不再承担类型检查职责职责拆分更清晰。5.5 验证 HMR 开发体验在 Vite 开发服务器运行状态下修改 src/main.ts 中的用户名字符串保存后观察浏览器页面是否自动更新。Vite 的 HMR 是模块级别的热替换修改代码后组件状态不会完全丢失。如果只是修改了静态文本或函数实现页面一般会快速刷新。这个验证只需要几秒钟但能很直观地体现开发效率差异。判断标准页面自动更新无需手动刷新浏览器且控制台没有报错。如果 HMR 失败优先检查是否有插件拦截了模块更新或者依赖版本不兼容。5.6 验证压缩与混淆配置在生产构建阶段Vite 默认使用 esbuild 进行压缩。如果你有额外的代码混淆需求可以在 vite.config.ts 里调整 esbuild 配置。常见的配置是 drop console 和 debugger// vite.config.ts import { defineConfig } from vite; export default defineConfig({ esbuild: { drop: [console, debugger], }, build: { target: es2020, }, });这里的 drop 配置可以把 console.log 和 debugger 语句从产物中移除。验证方式是构建后搜索产物文件确认没有 console.log 字符串。需要注意的是drop console 会删除所有 console 调用实际项目中如果用 console 做日志上报需要改成条件编译或使用独立的日志库。5.7 验证代理转发与接口联调开发环境中常见需求是接口代理。Vite 和 rolldown-vite 都能在 vite.config.ts 中配置 server.proxy把 /api 前缀的请求转发到后端服务。// vite.config.ts export default defineConfig({ server: { proxy: { /api: { target: http://localhost:3000, changeOrigin: true, }, }, }, });验证方式在前端代码中请求一个接口例如fetch(/api/user/list) .then((res) res.json()) .then((data) console.log(data));当后端服务没有启动时可能遇到 HTTP 代理错误。这是开发调试中的常见问题不一定代表前端配置错误也有可能是后端服务没启动或代理目标地址不对。排查时需要分两步先确认后端服务是否可访问再确认代理地址是否写对。6. 构建产物与代码分割分析构建产物是判断构建工具是否正常工作的重要依据。这里分别分析 tsup 和 Vite 的产物然后说明多入口库的批量构建方式。6.1 tsup 产物分析tsup 的双格式输出设计目标是兼容不同消费场景。ESM 产物给现代打包器使用CJS 产物给 Node.js 老环境或老打包器使用。实际发布到 npm 时package.json 里需要声明 exports 字段让工具能正确选择产物格式。{ name: your-lib-name, version: 1.0.0, main: ./dist/index.cjs, module: ./dist/index.js, types: ./dist/index.d.ts, exports: { .: { types: ./dist/index.d.ts, import: ./dist/index.js, require: ./dist/index.cjs } } }这种 exports 配置是 Node.js 现代包解析规范的一部分。它让 import 语法加载 ESM 产物require 语法加载 CJS 产物类型系统自动找到 d.ts。在 Webpack 时代这块往往需要手动配置或者依赖插件现在可以更显式地管理。6.2 Vite 应用产物分析Vite 的应用构建产物以 assets 目录为核心index.html 只负责引用入口文件。默认配置下Vite 会把动态 import 的模块拆分为独立的 chunk利用浏览器原生 ESM 能力实现按需加载。对于代码分割注意点在于配置 manualChunks把体积大且不变的依赖单独拆分提高浏览器缓存命中率。// vite.config.ts export default defineConfig({ build: { rollupOptions: { output: { manualChunks(id) { if (id.includes(node_modules)) { return vendor; } }, }, }, }, });这段配置是 Rollup 风格的 manualChunks 写法。在 rolldown-vite 中它仍然可以被解析因为 Rolldown 保持了 Rollup API 兼容。这正是 Rolldown 的一个优势不需要完全重写配置就能获得新的构建内核。6.3 tsup 多入口批量构建库项目经常需要同时打包多个入口比如按功能模块拆分。tsup 的 entry 可以接收数组或对象批量处理。// tsup.config.ts import { defineConfig } from tsup; export default defineConfig({ entry: { index: src/index.ts, utils: src/utils.ts, types: src/types.ts, }, format: [esm, cjs], dts: true, clean: true, });构建时会为每个入口生成对应的产物文件。这种方式常用于组件库每个组件一个入口使用方可以按需引用。批量构建时tsup 还会自动开启多线程编译充分利用 CPU 资源。6.4 monorepo 场景下的批量构建如果项目使用 monorepo且每个子包都需要 tsup 构建可以在根目录使用包管理器的递归执行能力把多个包的构建任务串起来或并行起来。根目录 package.json{ scripts: { build:packages: pnpm -r run build:lib } }-p 参数可以并行构建但需要注意包之间的依赖关系。如果包 A 依赖包 B 的构建产物需要先构建 B。这时候用拓扑排序# 按依赖顺序构建--sort 是 pnpm 默认行为 pnpm -r run build:lib这个批量任务的价值在 CI 环境里非常明显一条命令可以构建整个 monorepo 的全部包产物和日志会按包分开输出定位问题更快。7. 资源占用与性能观察性能是这套组合拳吸引人的核心原因但不同工具的资源占用和性能表现差异很大以下给出的是观察方法和判断标准具体数据以实际环境为准。7.1 观察 Vite 开发服务器启动速度Vite 的开发服务器启动速度往往比 Webpack 快原因是它不会在启动时全量编译整个项目而是先启动一个静态服务器等浏览器请求模块时才编译。验证方法比较直观在终端记录执行命令到出现访问地址的时间同时用系统监控工具查看 CPU 和内存占用。启动后修改一个源文件观察 HMR 更新时间。终端会输出类似hmr update /src/main.ts的日志和一些耗时信息。如果项目模块数量很大HMR 可能会比 Webpack 快很多但这也是有条件的和项目复杂度、模块依赖图深度有关。7.2 观察 tsup 库构建耗时tsup 构建的耗时主要来自 TypeScript 类型检查和 esbuild 转译。执行构建时终端会输出每个步骤的耗时。如果构建时间过长优先检查是否所有 sourcemap 和 d.ts 生成都开启这两项会显著增加构建时间。第一次构建之后tsup 会缓存部分结果后续构建会更快。观察时还要注意 CPU 核数。tsup 默认会使用多线程编译核心数越多的机器构建越快。如果 CI 环境的 CPU 核数较少构建耗时可能和本地有明显差异。7.3 观察 rolldown-vite 构建耗时rolldown-vite 的构建耗时方法是执行pnpm build:rolldown后记录终端输出的总耗时。这份数据最适合和普通 Vite 做对照实验。对照实验要保证同一份代码、同一份配置、同一台机器只切换内核这样看到的差异才有说服力。如果构建耗时表现不稳定重点看三方面CPU 调度、磁盘 IO、依赖安装状态。Rust 重写后的代码在大部分场景下应该表现出更好的编译效率但极端场景下可能有插件兼容性问题导致回退。7.4 如何降低构建资源占用资源占优化可以从几个方向入手。第一减少转译范围在 tsconfig 里设置 include只编译 src 目录不包含 test、node_modules 等目录。第二关闭不必要的 sourcemap本地开发可以开启方便调试生产构建如果不需要可以关掉。第三按需开启 dts 生成库项目需要应用项目可以不开。第四拆分构建任务高频构建走 esbuild 或 tsup低频完整构建走完整类型检查和打包。第五避免在开发服务器上开启大型插件链每个插件都会增加启动和热更新开销。7.5 防范端口冲突与进程残留Vite 默认使用 5173 端口rolldown-vite 也会使用类似策略。如果端口被占用Vite 会自动尝试下一个可用端口终端会输出最终访问地址。但有时旧进程残留会导致端口被占需要先确认并停止旧进程。# 查看端口占用macOS/Linux lsof -i :5173 # 查看端口占用Windows PowerShell netstat -ano | findstr :5173 # 停止指定 PID 进程 kill -9 PID需要按实际系统选用对应命令。如果项目需要固定端口可以在 vite.config.ts 中通过 server.port 声明并开启 strictPort端口被占用时直接报错而不是自动换端口。export default defineConfig({ server: { port: 5173, strictPort: true, }, });8. 常见问题与排查方法工具链切换中最容易出问题的不是新工具本身而是老配置的遗留心智。下面按场景整理常见问题。问题现象可能原因排查方式解决方案启动时提示 cannot find package vite当前目录没有安装 vite或包管理器解析不上来检查 node_modules 是否存在检查是否在项目根目录执行命令重新安装依赖确认包管理器版本启动 Vite 后接口代理 500/502代理目标服务未启动或代理地址写错用 curl 直接请求代理目标地址启动后端服务核对 target 地址和 changeOrigin 配置build:lib 后产物只有 ES 格式tsup 配置里 format 没写 cjs或写错了值打开 tsup.config.ts 检查 format 数组补上 cjs重新构建d.ts 文件没有生成tsconfig 的 declaration 被关闭或 tsup dts 配置为 false检查 tsconfig 和 tsup 配置开启 declarationtsup 设置 dts: true构建产物里还有 console.log生产构建未配置 drop或配置未生效查看 vite.config.ts 中 esbuild.drop 是否写对补上 drop 配置重新构建旧项目从 Webpack 迁移后图片/字体路径错误Webpack 的 publicPath 逻辑和 Vite 的 base 配置不同对比两个工具的产物路径规律设置 Vite base 为 ./ 或按部署路径调整页面能启动但部分模块加载失败路径别名未配置或配置不一致检查 vite.config.ts 的 resolve.alias 和 tsconfig paths统一别名配置存量 webpack loader 在高版本 Node 下报错Webpack loader 与新版 Node 兼容性问题先用低版本 Node 重现评估替代 loader或先用 LTS 版本过渡rolldown-vite 加载插件后构建失败插件对 Rollup 旧 API 依赖过深查看插件报错栈更换为兼容 Rolldown 的插件或暂时回退到 Vitetsup 构建速度突然变慢增量缓存失效或 TypeScript 类型检查任务过重查看构建日志观察卡在哪个阶段清理 node_modules/.cache 和 dist必要时拆分构建任务这里单独展开几个容易踩的坑。8.1 http proxy error 不等于前端配置错误很多团队在 Vite 开发环境遇到http proxy error第一反应是改前端代理配置。这个现象往往有两个来源后端服务没启动或者代理目标地址写错。排查顺序应该是先确认后端能否直接访问再对比代理配置。如果后端服务正常检查 changeOrigin 是否开启。如果代理配置正常但错误仍然存在观察错误是持续出现还是偶发超时。突发流量或后端响应过慢也会导致代理报错这时候要看后端日志而不是前端配置。8.2 Webpack 静态资源提示与产物路径问题Webpack 在某些场景下会提示content not from webpack is served from public。这是因为 public 目录或静态资源目录被直接拷贝而没有走构建流程。迁移到 Vite 后public 目录的语义仍然存在但处理方式不同。Vite 会把 public 下的文件原样拷贝到构建产物根目录在代码中需要以绝对路径或 base 前缀引用。如果你在迁移后发现图片路径不对优先检查 base 配置。8.3 依赖安装成功后仍然报无法解析error [ERR_MODULE_NOT_FOUND]: Cannot find package vite imported from这类报错经常出现在升级 Node 版本或切换包管理器之后。原因通常是 node_modules 结构不兼容或锁定文件过期。处理思路是清理安装缓存重新安装。# 删除 node_modules 和锁文件 rm -rf node_modules pnpm-lock.yaml package-lock.json yarn.lock # 重新安装 pnpm install如果项目里有 workspace还需要确认工作区配置是否正确避免子包依赖无法提升到根目录。8.4 Vite 打包代码混淆的正确姿势热搜词里经常出现“vite打包代码混淆”这个需求其实要拆开看。Vite 默认的 esbuild 压缩已经包含了一部分代码混淆效果变量名被缩短、空白被删除、注释被移除。如果你需要更高强度的混淆比如控制流平坦化、字符串加密那就需要引入独立的混淆工具。不过对于大多数业务项目默认压缩已经足够过度混淆反而会增加产物体积和构建时间。在引入额外混淆工具之前先确认你的核心诉求是体积控制、代码保护还是兼容旧环境。8.5 TS 类型导出问题用 tsup 打包 TS 库时最容易遇到的问题不是构建而是 d.ts 导出不全。如果一个接口没有显式在源码入口导出即使它被内部函数使用生成的 d.ts 也可能不包含完整类型。这时候可以先用 TypeScript 自身的类型检查确认接口导出再看 tsup 的 dts 生成结果。如果 d.ts 缺失优先检查所有对外 API 是否都有显式 export。9. 最佳实践与使用建议工具链落地不是把命令改一下就行真正重要的是工程化的节奏和边界控制。第一先小参数测试再做全量替换。第一次接入 tsup 时先用一两个入口验证产物格式和类型声明再扩展到完整库。第一次使用 rolldown-vite 时先挑一个简单服务做对照再决定是否推广到全部项目。不是所有项目都适合一条命令切换关键看插件依赖。第二保留一套最小可运行配置。把 tsup.config.ts 或 vite.config.ts 精简到不能再精简遇到问题可以快速回退到最简配置确认是配置问题还是工具问题。这个最小配置建议放到团队文档里作为新成员上手的起点。第三模型文件和产物目录分目录管理。这里主要是通用工程习惯源码放 src构建产物放 dist类型声明放 dist 根目录静态资源放 public。目录清晰之后CI 缓存和发布脚本会更容易编写。第四批量任务必须加日志和失败重试。tsup 多入口构建和 pnpm -r 批量构建都要保证日志里能区分每个子包的成功与失败。CI 脚本里可以加 continue-on-error 或者用 pnpm --filter 精确控制构建范围避免一个包构建失败中断整个链路。第五接口和开发服务器要限制访问范围。Vite 开发服务器默认监听 localhost如果要用局域网访问设置 host 选项但要注意网络安全边界。接口代理只给需要联调的路径配置不要把所有请求都转发到后端减少故障排查范围。第六涉及资产、代码、素材的分发要明确权限。构建产物发布前检查依赖许可、设计素材授权。如果项目是商业项目这一条尤其重要。第七发布前做效果复核。tsup 产物发布到 npm 之前最好用一个新的 Node.js 项目做一次从安装到使用的完整验证。这一步能提前发现 exports 配置错误、d.ts 路径错误、CJS/ESM 加载错误。同样应用构建上线前也需要在 preview 模式下检查页面加载、接口代理、资源引用。第八利用 tsconfig 的 paths 和 Vite 的 alias 统一模块路径。这条建议的价值在于减少深度相对路径引入提高代码可读性。配置完成后IDE 和构建工具需要保持一致否则编辑器能识别但构建工具不识别。10. 总结与下一步这套组合拳最值得尝试的点是把 Webpack 时代“一个工具解决所有问题”的思路拆分成了“每个环节用最合适的工具”。tsup 解决库构建的配置负担Vite 解决开发效率和开发体验Rolldown 解决未来构建性能的增长空间TypeScript 贯通整个链路。建议第一次验证时先用一个干净的 TS 项目跑通三条链路tsup 打库、Vite 开发、rolldown-vite 构建。这三条链路能跑通说明基本功能没问题。然后把项目里的一个小型工具模块切到 tsup 构建观察产物格式和类型声明是否符合预期。如果一个模块验证通过再讨论逐步迁移到更大范围。最容易踩的坑有两个。一是把 Webpack 的配置心智直接套到新工具上比如抱着 plugin 不放手、追求和 webpack.config.js 一模一样的配置二是忽略生态兼容性检查尤其是 rolldown-vite 刚接入时的插件兼容问题。每一个新工具都应该先在隔离环境做验证再做技术选型决策。后续可以扩展的方向包括把 tsup 和多包发布工具集成配合 changesets 做版本管理和发布流程把 Vite 的构建流程和 CI 流水线对接加入缓存策略把 rolldown-vite 作为单独的性能测试基准持续观察构建耗时如果团队有组件库或设计系统需求可以基于 tsup 建立统一的组件构建规范。建议收藏备用。整套工具链的迁移难度不在工具本身而在于如何用最小成本验证替换收益再逐步扩大落地范围。