前端工具生态选型手册：构建、测试、状态与依赖治理

把 awesome-f2e-libs 固定快照中的 25 个分类逐项展开，结合现代官方资料讲清工具边界、场景选择、安全门槛和落地验收。

本文围绕 sorrycc/awesome-f2e-libs 做原创工程整理。项目来自 腾讯新闻前端团队 2022 年的 25 个 Awesome 项目推荐；README 固定到 commit 70185bda5a415a40f858772e4d142e8d868d0893：18,261 字节、305 行、25 个顶层分类、213 条链接清单项和 214 个 HTTP(S) 链接引用（213 个不同目标）；根目录 LICENSE 返回 404，仓库未声明 SPDX 许可。 下方保留固定版本入口。

仓库内容地图

• 构建链：打包工具、Webpack 扩展、Bundless、非 JS 编译和包管理
• 语言与测试：Babel、宏、测试框架与性能优化
• 应用层：React/Vue 相关库、数据流与 Redux 扩展
• 开发体验：文档、工程、编辑器/Cloud IDE、字体、CSS、命令行
• 数据与内容：请求处理、压缩解压、语法解析、Markdown 和相关资源

怎么读才有收获

读此仓库时把“解决的问题”和“工具名称”分开记。先确认当前项目的构建链是否已经提供同等能力，再看候选库是否会与现有框架和升级路径冲突。

这份工具库地图的范围

固定快照为 sorrycc/awesome-f2e-libs 的 README（commit 70185bda5a415a40f858772e4d142e8d868d0893）：18,261 字节、305 行、25 个二级分类、213 条带链接的清单项和 214 个 HTTP(S) 链接引用（其中有一项附带第二个项目链接）。仓库根目录没有 LICENSE 文件，也没有可确认的 SPDX 许可声明；因此本文不逐行复制原清单，而是把 25 类全部映射出来，重新解释它们解决的问题、今天如何选型和怎样验证。单个项目及其文档仍有各自的许可证。

清单里的包名只是历史索引，不是维护状态、质量、兼容性或安全背书。尤其要分清“曾经有用”“现在仍可维护”和“适合我的项目”是三个不同判断。比如 React 官方已经明确将 Create React App 标记为新应用不再推荐的弃用方案；旧清单可以用来理解生态演进，但不能当作今天的脚手架推荐。

25 个分类逐项对照

原 README 中的三个构建子类是 Webpack 辅助工具/Loader/插件、Bundless 和非 JavaScript 编译；Babel 下面有宏分类，数据流下面有 Redux 扩展。它们已经计入“打包工具”或对应父类的统计，不另加到 25 个顶层分类。

先画项目边界，再选工具

选型前先回答四个问题：这是网站应用、可复用 npm 包、组件文档，还是开发者工具？运行环境是纯浏览器、Node、SSR、桌面 WebView，还是多端宿主？团队已经维护哪套构建/测试链？谁会在半年后负责升级、漏洞处理和迁移？把答案写进决策记录，避免“因为大家都在用”变成唯一理由。

工具只应承担一个能测量的职责。开发服务器负责本地反馈，bundler 建立模块/资产依赖图，转换器改写语法，类型检查器验证类型，测试运行器执行断言，CI 负责把这些检查变成合并门槛。把这些职责混成“构建工具”会让失败定位和升级变得困难。

构建链：应用、库和编译器不是同一件事

Webpack 官方将自身描述为静态模块打包器：从入口建立依赖图，再由 Loader 转换特定模块，由 Plugin 扩展更广泛的构建过程。历史清单中的 Webpack Dev Server/Middleware、配置合并、进度条、Bundle Analyzer、重复依赖检查和 TypeScript 检查插件，分别落在开发服务、配置、观测、产物分析和校验层。引入插件前先确认当前 Webpack 版本是否已内建同等能力，并观察插件是否仍兼容 Node 与 loader API。

Vite 的现代工作方式也不应被简化成“永不打包”：开发阶段利用原生 ESM 和开发服务器提供快速反馈，生产构建则会生成适合部署的优化静态产物；当前文档说明生产构建采用 Rolldown。Bundless 是一种开发/模块交付取舍，不是免除依赖解析、兼容处理、代码分割和生产优化。

应用构建与库构建关注点不同。应用有 HTML 入口、路由分块、资源哈希、浏览器兼容目标和部署 base path；库还要考虑 ESM/CommonJS 消费方式、类型、peer dependencies、CSS 导出、tree-shaking 和语义化版本。package.json 的 exports 可以明确公共入口并阻止消费者依赖未承诺的内部路径：

{
  "name": "@example/ui-kit",
  "type": "module",
  "exports": {
    ".": {
      "types": "./dist/index.d.ts",
      "import": "./dist/index.js",
      "require": "./dist/index.cjs"
    }
  }
}

发布前用打包产物在 ESM 与 CommonJS 消费端各做一次 smoke test；不要只测试源码 alias。若同时维护 main、module、types 和 exports，逐个验证工具链如何解析条件入口，并把目标 Node/浏览器范围写清楚。Node 官方文档将 exports 作为现代包的公开入口机制，也指出它会封装未导出的子路径。

Babel、SWC、esbuild、Sucrase 等名字容易被说成“互相替代”，但应比较语法支持、插件兼容、Source Map、目标环境、构建速度、类型检查和运行时差异。转译 TypeScript 语法不等于执行完整类型检查；让类型检查和产物生成成为可单独诊断的步骤。AST 工具适合处理嵌套语法和代码变换，禁止用脆弱的正则表达式替代解析器。

依赖管理与发布：可复现比命令习惯重要

npm、Yarn、pnpm 都能安装依赖，但团队应在仓库中选定一个 package manager 和唯一锁文件，固定 Node/package manager 版本并在 CI 用不可变安装。提交代码前检查依赖来源、安装脚本、可选依赖、peer dependency 冲突和锁文件变化。工作区能力解决多包安装与本地链接问题，版本策略和发布授权仍要单独设计。

工程分类里的 ESLint/Prettier、Yeoman、静态服务器、Husky/lint-staged、cross-env、nvm、发布脚本、Changelog 和并发命令不是越多越好。先明确“谁负责发现问题、在哪一步失败、失败信息谁能看懂”，然后将昂贵检查安排到合适阶段：编辑器快速反馈、提交前轻量检查、CI 权威检查、发布后验证。钩子可以被跳过，不能代替 CI。

安全发布至少记录：源代码 commit、依赖锁文件、构建 Node 版本、产物校验和、制品存储位置、发布人/工作流身份、回滚步骤。发 npm 包前检查 tarball 实际包含的文件、README/License、exports、files 白名单、源码映射是否泄露私有路径，以及预发布版本能否被测试项目安装。

测试：按真实风险分层

测试分类不能按仓库里的包名机械划分。纯函数用单元测试；浏览器 API 和 DOM 行为用合适的模拟环境；组件交互尽可能按角色、标签、按钮文本等用户可见语义查询；路由、网络、浏览器存储或多标签页协作要由集成/浏览器测试覆盖；登录、上传、支付入口等关键旅程再用端到端测试确认系统连接。

Enzyme 属于旧 React 生态里的组件测试方案；React Testing Library 强调从 DOM 与用户可见行为验证组件。Vitest 可运行 Vite 项目测试，也提供 Browser Mode；Playwright 是端到端浏览器测试框架，覆盖 Chromium、Firefox 与 WebKit。不要用 jsdom 单独证明真实布局、浏览器安全策略、CSS、下载、文件选择或跨浏览器行为。

一个可测试的异步 UI 还要处理取消和竞态。以下函数把 Fetch 实例注入，使单测能模拟响应；调用方卸载或查询变化时应传入 AbortSignal。解析 JSON 后仍须依据 schema 验证响应结构，HTTP 200 不代表业务数据正确。

async function fetchJson(url, { signal, fetchImpl = globalThis.fetch } = {}) {
  const response = await fetchImpl(url, { signal });
  if (!response.ok) throw new Error(`HTTP ${response.status}`);
  return response.json();
}

框架、状态与 UI：把服务器状态和界面状态分开

React、Vue、Next/Nuxt、Gatsby、Umi、Taro、Quasar 等条目不是同一层的竞争者：有的是 UI 库，有的是全栈/SSR 框架，有的是站点生成器或跨端方案。先确认目标是 CSR、SSR、静态生成还是原生宿主；再核对路由、数据加载、缓存失效、服务端授权、构建部署和升级路径。React 官方目前建议新应用优先选框架；小型嵌入交互或受限 SPA 可以自行组合构建工具，但要承认并补齐自己承担的路由、数据和切分职责。

React 相关库中，Router、UI、国际化、拖放、按需加载、页面元信息和 JSON Schema 表单关注完全不同的能力。Vue Router 也应按路由守卫、嵌套布局、URL 参数、懒加载和历史模式部署要求评估。优先选维护活跃且与框架版本兼容的方案；同一层尽量保留一个主方案，避免状态、路由或 UI 组件库并存造成重复模式。

把状态分成三类可避免过度引库：

• 局部交互状态：弹窗开关、当前输入、临时选中项，默认留在最近的组件。
• 客户端共享状态：跨页面工作流、编辑草稿或客户端偏好，才需要跨组件 store。
• 服务端状态：远程数据的加载、缓存、失效、重试和并发更新。优先复用框架数据层或专门的数据缓存，而不是把每个响应复制进全局 store。

Redux Toolkit、MobX、RxJS、Jotai、Zustand、XState、Vuex 等代表不同模型：集中 reducer、响应式 observable、流、原子状态、轻量 store、状态机、Vue 生态状态。不要只比较 API 长短；要比较状态所有权、调试时间线、异步副作用、SSR 请求隔离、序列化、持久化和迁移。服务端渲染时，不能把用户数据放进跨请求共享的单例 store；持久化也要兼容旧 schema 并处理敏感字段。

文档、样式、性能与内容安全

Storybook、组件文档站与 MDX 帮助组件在隔离场景展示；文档要同步展示可访问名称、键盘操作、错误/空状态和版本。字体需核对字符覆盖、授权、加载策略、fallback 和跨平台字形。CSS Modules 与 CSS-in-JS 是作用域和运行时取舍，不是天然的隔离/性能保证；测量注入样式、SSR、主题和构建产物。

Workbox 一类 PWA 工具需要精确写缓存规则：静态资源可按版本缓存，用户数据和敏感 API 通常不该被宽泛缓存；更新、离线状态、缓存失效和存储空间都要验证。Critical CSS 只应基于实际首屏测量，避免把所有样式重复内联。性能验收同时看真实设备 LCP/INP/CLS、JS 执行与传输大小，不以本地开发服务器速度代替用户感受。

Markdown、富文本和语法高亮尤其需要安全审查。Markdown parser 只负责语法，不自动保证生成 HTML 安全；默认关闭危险 HTML 或经过严格净化，检查链接 scheme、图片来源、外链 rel、代码块大小和渲染耗时。AST 插件若可以执行任意作者脚本，就不能被当作普通内容配置。

请求、文件、压缩包与命令行

浏览器 Fetch 与 Node 请求库有不同的运行时能力、cookie、代理、TLS 和流处理行为。请求层至少统一超时/取消、错误类型、重试策略、幂等性、凭证范围和日志脱敏；不要对非幂等写请求盲目自动重试。响应 JSON 需要 schema 验证。跨域是服务端 CORS 策略，不靠更换客户端库解决。

压缩/解压库要用恶意归档测试：拒绝绝对路径、.. 路径穿越、符号链接逃逸、超大展开比、文件数耗尽和重复条目；对上传流设压缩前/后的大小阈值与时间预算。CLI 库可改善交互、参数和终端展示，但执行子进程仍要传参数数组、限定可执行文件和环境变量，不把用户输入拼成 shell 命令。

在线 IDE、桌面容器和多语言入口

VS Code/IDEA 是本地开发环境，CodeSandbox/StackBlitz 是在线复现或分享环境，CloudIDE 更接近工作区服务。选型要看导入仓库权限、私有代码处理、持久化、依赖安装、网络出口、构建容器隔离和服务条款。不要把私有项目或令牌粘贴进公开沙箱。

Electron 等桌面框架能访问更广泛系统 API，攻击面也随之增加。区分主进程、预加载层和渲染进程；默认关闭渲染器 Node 集成，启用 context isolation 与 sandbox，校验 IPC sender，限制导航/权限和外链，避免对远程内容开放任意桥接。桌面方案的体积、升级、签名、自动更新与平台测试应计入长期维护成本。

TypeScript 是常见的静态类型层，Flow 是另一种类型检查路线，GraphQL 是 API 查询语言及 schema/工具生态，不应放在同一个“编译器”抽屉里。选择时写清静态分析覆盖哪些代码、运行时校验由谁负责、服务端 schema 如何演进，以及客户端生成代码如何跟 CI 对齐。

安全与维护门槛清单

每个进入生产的依赖都要有一张短记录：

1. 当前版本、最近 release/commit、支持的 Node/浏览器/框架主版本与迁移说明。
2. 根包和传递依赖许可证、维护者/发布权限、安装脚本、二进制下载与供应链公告。
3. 实测生产 bundle、冷启动、长任务、内存、手机/辅助技术和失败降级。
4. 数据处理位置、权限、网络访问、上传内容和日志是否会带入隐私或凭证。
5. 锁文件复现、依赖升级测试、回滚办法、替代路线与负责人。

出现许可证不兼容、未修复高危漏洞、目标平台不支持、维护权不清晰、不可控的数据出境或无法回滚时，应先停下来，不用评分表的平均分冲淡硬性风险。

一周内完成一次选型验证

第 1 天写出使用场景、设备/浏览器矩阵、数据敏感级别和明确的验收指标。第 2 天从原生平台能力开始，再筛出最多三个候选，逐个核对官方文档、兼容与许可。第 3 天在隔离分支做最小纵向原型，包含一条完整用户路径，而不是只跑 Hello World。第 4 天加入真实组件/数据和错误/取消/空状态。第 5 天测低端移动设备、产物体积、可访问性和安全边界。第 6 天验证 CI、锁文件、包导出与回滚。第 7 天写决策记录：选择什么、为什么淘汰其它方案、哪些条件变化时要重新评估。

当前官方资料

• Vite Getting Started 与 Production Build
• Webpack Concepts
• React：Creating a React App
• React：Sunsetting Create React App
• Node.js Packages：main、exports 与模块入口
• Vitest Browser Mode
• React Testing Library
• Playwright 安装与端到端测试

动手路线

1. 为一次构建性能优化记录冷启动、增量构建、产物体积三项基线。
2. 给选中的 Markdown 或语法解析库加输入恶意 HTML 的安全测试。
3. 把重复出现的 UI/工程需求抽成选型记录而不是无序安装插件。

使用边界

固定快照没有根目录 LICENSE，也没有可确认的 SPDX 许可声明；本文是按 25 个分类撰写的原创工程指南，没有复制原 README 或第三方资源正文。上游包名与链接只作为发现线索，实际选用前要独立核验其当前版本、维护、安全和许可证。

原始入口

• 固定版本 README 与仓库入口
• 发现这份资源的原始推荐
• 返回 25 个开源项目专题目录