1. 先按你会在哪一层用到把这 15 个项目分个类聊开源项目最容易犯的毛病就是一上来铺开一张清单从 A 念到 Z读者看完只记得几个名字真到项目里还是不知道该装哪个。所以我不打算按热度排而是按你手上的活儿在链路的哪一层来分。字节跳动这几年前端开源铺得很开但真正在社区里反复被用的是这么几块构建链路、工程框架、组件与设计系统、以及跨端/微前端/富文本这类偏垂直的能力。先把话说明白这份清单是我自己在做项目和带团队时反复会打开的那一批热度是参考能不能解决实际问题才是标准。我把它压成四组第一组是构建与工程化底座包括 Rspack、Rsbuild、Rspress、Rslib、Modern.js第二组是组件库与设计系统代表是 Arco Design 和 Semi Design外加它们各自的移动端版本第三组是跨端与微前端Garfish 和 Lynx 是主力第四组是编辑器与素材工具Syllepsis、ByteMD、IconPark 这几个。加起来正好覆盖了 15 个左右的常用仓库。这么分的意义在于你选型的时候是自顶向下还是自底向上会得出完全不同的结论。如果你是在做一个新项目通常是先定框架Modern.js 或自己的脚手架再定构建Rspack/Rsbuild最后挑组件库如果你是在维护一个存量项目顺序刚好反过来——组件库和微前端往往先动构建工具是最后才敢碰的。我见过不少团队一上来就想把 webpack 换成 Rspack组件库还在用三套混着写结果性能没提上去业务先乱了。提示判断一个开源项目值不值得进你的技术栈先问三个问题——它的维护节奏跟不跟得上你的迭代、它的文档能不能让你在不看源码的情况下解决 80% 的问题、它的社区里有没有人踩过你现在正要踩的坑。这三个都想清楚了再谈引入。第一组里我特别想强调一点Rspack、Rsbuild、Rspress、Rslib 它们不是四个平级的东西而是同一条技术路线上的不同切面。Rspack 是内核Rsbuild 是面向应用的上层封装Rspress 是做文档站的Rslib 是打包组件库的。很多人不知道这个关系结果把 Rspress 当成又一个构建工具去装用起来当然别扭。这部分我会在第二节展开讲。组件库这一层是新手和面试都绕不开的。前端面试题里你了解哪些企业级组件库怎么设计一个组件库的主题系统这类问题出现频率极高而 Arco 和 Semi 恰好是两个很好的答题素材——它们的设计理念、主题方案、按需加载策略都不一样能讲清楚差异本身就说明你动过手。第三组和第四组则是拉开差距的地方微前端qiankun、Garfish和跨端在面试里属于进阶题能说清楚隔离机制和渲染原理的人不多。2. 构建与工程化这条线这几个项目到底解决什么真问题2.1 Rspack为什么值得用 Rust 把打包重写一遍先讲 Rspack因为它是这条线的地基。传统 webpack 的问题不是配置难而是在大项目里慢。一个几千模块的中后台项目冷启动一两分钟、热更新几秒开发者一天要等几十次这个损耗是实打实的。Rspack 的思路不是把 webpack 配置再优化优化而是换一套执行引擎——用 Rust 重写核心的模块解析、依赖图构建和产物生成把 CPU 密集的部分从 JS 挪到原生代码里同时保留 webpack 那套配置心智。为什么保留 webpack 的心智这是我认为它最聪明的地方。前端社区对 webpack 的 loader、plugin、resolve、optimization 这些概念已经形成了肌肉记忆如果 Rspack 搞一套全新的 API迁移成本会劝退绝大多数人。它选择兼容大部分常用配置意味着你原来的webpack.config.js很多时候改个入口就能跑。我实测过一个中等规模的 React 项目冷启动从原来的四十多秒降到十秒出头热更新基本在一秒内这个体感差距是很明显的。但要说清楚它不是什么。快是有代价的一些非常冷门的 loader、依赖 webpack 内部私有 API 的插件、还有那种深度依赖compiler.hooks时序的定制逻辑在 Rspack 上可能不完全等价。所以我的建议是存量项目迁移前先用真实配置跑一遍别只看官方兼容性列表。// rspack.config.js 的基本骨架和 webpack 很像但不是照搬 const { defineConfig } require(rspack/cli); module.exports defineConfig({ entry: { main: ./src/index.js }, resolve: { extensions: [.js, .jsx, .ts, .tsx] }, module: { rules: [ { test: /\.(j|t)sx?$/, use: builtin:swc-loader }, ], }, optimization: { minimize: true }, });注意上面 loader 那里用的是builtin:swc-loader这是 Rspack 内置的 SWC 转译能力不是社区的 swc-loader。这个细节很多人第一次会写错写了外部的 loader 反而变慢。2.2 Rsbuild站在 Rspack 之上的开箱即用Rspack 给了你引擎但没给你一套配好的车。Rsbuild 干的就是这件事。它把 React、TypeScript、CSS 预处理器、图片处理、环境变量、构建产物分析这些常见的诉求都预置好了你新建一个项目基本不用写构建配置就能跑。我更愿意把它理解成Rspack 的官方应用级封装类比一下就是 Vite 和它的底层 Rollup 的关系只不过这里上层和内核是同一个团队在维护。它的价值在中小团队里格外明显。不是每个团队都有专职的构建工程师配 webpack 配到半夜的痛点大家都懂。Rsbuild 把默认值调得比较合理target、polyfill、browserslist这些默认就帮你处理了你只需要在rsbuild.config.ts里改少数几项。我见过一个三人小团队从零搭项目用 Rsbuild 半小时就跑通了开发和生产两条链路换在以前配 webpack 至少要一天。维度直接上 Rspack用 Rsbuild配置量需要自己组装 loader/plugin默认几乎为零按需覆盖适合团队有构建经验、定制需求多中小团队、想快速起步迁移存量需逐项对齐 webpack 配置多数场景换入口即可可扩展性强但需要自己兜底强且默认闭环表格里最后一行可扩展性值得多说一句。有人担心用了封装就失去了自由其实 Rsbuild 保留了完整的 Rspack 配置透传能力比如tools.rspack就能拿到底层配置去改。所以它是默认帮你配好但没把你锁死这个设计取向我认为是对的。2.3 Rspress 与 Rslib文档站和组件库打包的两把专用刀Rspress 是做文档站的。你去看很多新兴开源项目的官网底下那套左侧导航、右侧锚点、顶部搜索的布局有不少就是 Rspress 生成的。为什么不用通用的建站工具因为文档站有一堆特殊需求Markdown 里的代码块要能高亮、要能跑 demo、搜索要支持全文索引、多语言要能切。Rspress 基于 Rspack构建快、默认集成这些能力写docs目录就是写完一本书的感觉。我拿它做过一个内部组件库的文档最大的感受是约定优于配置。你把.md和.mdx放进docs目录路由自动就出来了根本不写路由表。缺点也有就是当你想大改主题的时候得顺着它的主题机制来硬改 CSS 容易和升级打架。Rslib 则是打包库的。这里有个很多人忽略的关键区别打应用和打库的目标完全不同。应用要的是产物小、加载快、代码分割库要的是干净、无副作用、依赖正确外置。库如果不小心把 React 打进去了用你库的项目就会出现两个 React 实例报错能查一整天。Rslib 默认就把 peer 依赖外置、把 ES Module 和 CommonJS 双产物都出一份还会校验package.json的exports字段。做组件库、工具函数包的人应该重点看看这个。2.4 Modern.js一套更完整的工程体系而非工具Modern.js 的定位和前几个不太一样它是一整套方案包含应用框架、构建、路由、数据获取、插件体系。你可以理解成字节内部工程实践的对外版本。它同时支持 React 和部分场景下的 Vue提供了比较完整的约定式路由和 SSR/SSG 支持。它适合什么人适合想要一套端到端一致体验的团队——一个仓库里既能写 CSR 的中后台也能写 SSR 的内容页构建配置、插件、部署适配都是统一的。代价是学习曲线比 Rsbuild 陡概念多一些。我的看法是小项目、纯工具库不用碰它中大型、对 SSR 有真实需求、又不想自己拼装 Next 之外方案的团队值得花时间评估。3. 组件库选型Arco 和 Semi 到底该怎么挑3.1 先看设计语言和业务基因再看代码选组件库最容易踩的坑就是只看文档好不好看组件全不全结果用起来发现设计风格和自己的产品根本不搭。Arco Design 和 Semi Design 风格差异其实挺明显的Arco 更偏中规中矩的企业级、克制、中性Semi 的视觉更细腻一些动效和细节处理更讲究背后是抖音那套业务沉淀。这不是说谁更好而是说你得先确定产品要什么调性。做后台管理系统、数据平台Arco 的沉稳更省事做偏 C 端、偏内容的产品Semi 的精致度可能更对路。我见过团队因为某篇文章推荐了 Semi就全量换掉结果设计同学提了一堆还原度问题来回改主题改了两周。从工程角度看两者的接入方式倒是都很规范都提供了 npm 包、按需加载方案、TypeScript 类型。React 和 Vue 都有对应版本这一点比某些只支持单一框架的库要友好。3.2 主题定制能力才是长期使用的胜负手组件库用半年之后你一定会遇到我要改主题的需求。这里两者的差异就体现出来了。它们都支持通过设计变量design token来定制颜色、圆角、间距这些东西但具体的导出方式、覆盖粒度、以及和 CSS 变量的结合程度不完全一样。我的实操建议是选型阶段就做一次主题改造实验。别等系统长到几十个页面才想起来换主题。你就拿一个按钮、一个表格、一个表单试试把主色调、圆角、字号全改一遍看看顺不顺手、有没有要写一堆覆盖样式的恶心情况。/* 以 CSS 变量覆盖的思路示意具体变量名以对应库文档为准 */ :root { --primary-color: #165dff; --border-radius-medium: 6px; }按需加载也得实测。两者都推荐配合现代构建工具做 tree-shaking但如果你在 Rsbuild/Vite 之外的老环境里用可能要靠 babel 插件。这里偷懒的代价是包体积——一个只用了几十个组件的后台如果全量引入多出来几百 KB 是很常见的。3.3 移动端和周边生态决定你走多远如果只做 PC 后台两边差别不大但如果你还要做移动端 H5就要看它们的移动端版本。Arco 和 Semi 都有对应的移动组件库提供适配手机交互的组件。这里的经验是PC 端和移动端最好用同源的设计体系不然两套设计语言会让你的产品显得割裂而且设计和前端都要维护两套视觉规范。除了组件本身周边也很关键。图标、图表、表单方案、低代码适配这些外挂能力齐不齐直接影响你后期要不要再引第三方。我一般会看这个库的图标是不是自成体系、有没有配套的表单/表格增强组件、社区里有没有成熟的二次封装。这些细节单个不起眼攒起来就是几个月的开发量。4. 微前端、跨端、富文本那些看起来远其实很近的项目4.1 Garfish微前端接入的实操与隔离的真相微前端这两年热度一直很高关键词里 qiankun 入门、微前端框架反复出现说明这是很多人正在学或者正在用的东西。Garfish 是字节系微前端方案里比较有代表性的一套。它要解决的核心问题很朴素多个团队想把自己开发的应用拼成一个整体但不想互相拖累。它的基本机制是运行时加载子应用的资源、挂载到指定的容器里并处理路由、沙箱、通信这些事情。和同类方案比Garfish 在沙箱隔离和路由管理上做得比较细支持子应用单独开发、单独部署。但我要提前泼盆冷水微前端不是银弹它带来的是架构复杂度。样式隔离、全局变量污染、多框架共存、公共依赖重复加载这些坑一个都躲不掉。注意微前端的第一原则是能不用就不用。如果你只是想让系统分模块开发用 monorepo 加合理的构建分层往往更简单。只有当团队确实独立、要独立发布、要技术栈自由时微前端才划算。实测下来接入 Garfish 时最容易出问题的是样式冲突。两个子应用都用了全局的 reset加载顺序一变页面就乱。常见的处理是给每个子应用的根节点加命名空间前缀配合沙箱把样式限定在容器内。另外公共依赖React 之类最好在基座里以 external 的方式共享否则每个子应用各带一份内存和加载时间都会上去。4.2 Lynx跨端渲染的另一条路Lynx 是字节在跨端方向上比较有代表性的开源项目目标是让你用一套前端写法在不同端上渲染出原生体验。它和常见的WebView 套壳思路不同走的是自绘渲染的路子性能上更接近原生。对前端开发者来说这类框架的吸引力在于用熟悉的 JS 和类 CSS 写但跑出原生的顺滑度。它的难点也在这一旦涉及原生能力、复杂动画、和宿主环境的交互学习成本会陡增调试也比纯 Web 麻烦。我的建议是如果你做的是交互复杂、对流畅度要求高的场景值得研究如果只是普通展示页WebView 方案成本更低没必要为了原生感硬上。4.3 Syllepsis、ByteMD、IconPark编辑器与素材类工具Syllepsis 是富文本编辑器方向的项目来自飞书那套编辑器实践的沉淀。富文本编辑器是前端出了名的深坑光标、选区、撤销重做、协同每一项都能写一本书。如果你要自己造一个编辑器先去看它的架构和数据模型设计比自己从 contenteditable 硬撸强太多。ByteMD 是 Markdown 编辑器基于它做二次开发做过内容类工具。它的好处是把 Markdown 解析、预览、工具栏这些东西都封好了还支持插件扩展。我拿它做过一个内部文档工具接入成本很低缺点是深度定制比如自定义语法、和协同编辑结合时需要读懂它的插件机制。IconPark 是图标库提供多套主题的图标支持按需引入和自定义属性。这类工具单个价值不高但一个项目里图标风格不统一是高频问题有一个成熟图标库能省掉很多和设计来回对齐的时间。它和组件库搭配使用体验最好颜色、大小沿同一套 token。5. 常见问题与排查技巧实录这一节是踩坑攒出来的我在带项目和做技术评审时反复遇到整理成速查形式可能比大段叙述有用。5.1 构建相关的典型报错与处理先说移植到新构建工具时最容易撞上的几类问题。第一类是loader 不匹配尤其是一些老项目用到的自定义 loader在新工具里可能没有对应实现表现为文件解析不了或者产物里语法不对。排查方法是先把 loader 关掉用最简单的入口跑一遍确认是 loader 的问题还是别的。第二类是环境变量注入方式变了。老的写法是process.env.XXX通过 DefinePlugin 注入新工具往往提供了更简洁的define或环境前缀机制。如果代码里读了没注入的变量运行时才会炸而且报的是undefined很难定位。我的习惯是构建完成后全局搜一遍process.env确认没有漏网的。第三类是产物体积不降反升。这通常不是工具的问题而是 tree-shaking 没生效或者公共依赖被重复打包。用产物分析看哪个 chunk 异常大顺着找是哪个包没被正确 external。现象可能原因快速定位方式启动报模块解析失败loader/插件不兼容关掉自定义 loader 最小复现运行时变量为 undefined环境变量未注入全局搜 process.env 逐一核对产物体积异常增大tree-shaking 失效/依赖重复产物分析定位大 chunk热更新不生效路径大小写/软链检查 import 路径与实际文件5.2 组件库引入与体积控制的实战组件库引入最经典的问题就是我只用了一点点为什么打出来这么大。共同的根因是按需加载没配好整包被引了进来。排查步骤先看产物分析里组件库占了多大再用极简引入验证——只引一个 Button如果体积还是很大说明按需机制没生效。另一个高频坑是样式丢失。有的库样式是 CSS 文件有的是 CSS-in-JS按需加载方案如果只处理了组件没处理样式就会出现组件在了但没样式。这类问题在开发环境被缓存一盖可能看不出一上生产就暴露。还有一点经验不要把组件库当成万能模板。企业级组件库给的是基础能力和规范业务里的复杂表格、表单、穿梭框几乎都要二次封装。我一般会在项目里建一层components/biz把组件库的原子组件包一层统一处理业务默认值、埋点、权限。这样将来换库或者升级改动面可控。5.3 微前端与跨端的隔离问题速查微前端的坑集中在隔离上我整理成一张表方便你出问题时对着查。样式隔离、JS 沙箱、路由冲突、公共依赖这四类基本覆盖了八成的故障场景。问题类型典型表现处理思路样式污染子应用加载后基座样式变了根节点加命名空间限定作用域全局变量冲突一个应用的变量影响另一个启用沙箱避免挂 window路由错乱切换应用 URL 和视图不一致统一 base基座接管路由依赖重复内存高、加载慢公共依赖 external 由基座提供通信混乱事件多发、状态不同步收敛通信协议少用全局事件跨端这边最容易被低估的是调试成本。Web 上你 F12 就能看到的东西跨端环境里可能要连真机、看宿主日志。我的习惯是在项目早期就把日志和异常上报打通别等到出问题才加。另外一点跨端框架的版本和宿主 App 的版本往往强绑定升级要同步评估不能像升级个工具库那么随意。在带团队时我还发现一个现象很多人学这些项目是从文档倒着学——先背 API再去找场景。这样学出来的知识很脆弱面试时能说两句真用就露馅。更稳的路径是带着一个真实小需求去用想练构建就搭个多页应用想练微前端就拆两个小应用拼一起想练组件库就做一套自己的主题。需求驱动下你会主动去看源码、查 issue那些才是真正长在身上的东西。我个人在实际操作中的体会是这些开源项目最大的价值不是省了写代码的时间而是把别人踩过的坑变成了你的默认值。Rspack 把构建性能的坑填了组件库把设计和可访问性的坑填了微前端把隔离的坑填了一部分。但你得清楚哪些坑是它填的、哪些还得自己填。选型的时候多花两小时做好实测比上线后花两周填坑划算得多。