企业官网建设流程全解析

1. 从一次构建提速说起：Rstack 那四件套凭什么出圈

去年手上一个中后台项目，webpack 冷启动 40 多秒，改一行样式 HMR 要等三秒才刷新，团队里谁都懒得动构建配置，怕改坏。后来把 webpack 换成 Rspack，冷启动掉到 5 秒以内，热更新几乎是即时的，那次之后我才认真去翻字节跳动开源的那一批前端项目，发现它们早就不是零散的小工具，而是一整条从构建、设计系统到可视化、跨端的完整链路。这篇就按用途把 15 个项目拆开讲清楚：各自解决什么问题、适合多大规模的项目、上手要躲哪些坑，以及我实际用下来的体感。刚入门工程化的同学可以当路线图看，做中后台、大屏或跨端的朋友，里面大概率有几套能直接替掉你现在手里的轮子。

1.1 Rspack：用 Rust 重写打包，意义到底在哪

Rspack 是字节 Web Infra 团队用 Rust 写的打包器，核心卖点是兼容 webpack 的配置与插件生态，同时把构建速度拉上一个数量级。它的做法是把最耗时的模块解析、依赖图构建、代码生成这些环节放进 Rust 里做多线程并行，JS 侧只保留插件调用的胶水层。

为什么这件事值得单独拎出来说？因为在此之前，前端换打包器的成本极高。Vite 走的是 dev 阶段不打包、生产仍用 Rollup 的路子，很多重度依赖 webpack loader 的老项目根本换不过去。Rspack 的策略是"你别动配置，我帮你跑快"——webpack 的 loader、plugin 大部分能直接复用，迁移成本被压得很低。

实测里要留意的点：Rspack 对 webpack 的兼容是"绝大多数"而不是"全部"。凡是依赖 webpack 内部私有 API（比如compiler.hooks深处、NormalModule的私有字段）的插件，基本会挂。我踩过一次是某个老旧的 CSS 处理插件，最后换成 Rspack 内置的builtin:swc-loader才跑通。迁移前先跑一遍官方的兼容性检查清单，比改完再一个个排错省事得多。

1.2 Rsbuild 与 Rslib：把"应用"和"库"的构建分开治

Rsbuild 建立在 Rspack 之上，定位是开箱即用的构建工具。Rspack 是引擎，Rsbuild 是整车：帮你把 HTML 生成、CSS 处理、环境变量、代理、资源压缩这些默认配置一次性配好，只暴露少量语义化配置项。以前搭一个 React 项目要手写几十行 webpack config，现在rsbuild.config.ts里几行就够。

Rslib 则是专门为"库"打造的构建工具，基于 Rspack 但补上了库打包特有的东西：多格式产物（ESM/CJS）、类型声明生成（走dts插件）、external依赖处理、按需产物。为什么库和应用要分开？因为应用只关心"能不能跑起来"，库要关心"别人怎么引、会不会把 React 一起打进去、类型声明全不全"。这两套诉求混在一个配置里，最后一定是互相将就。

我的经验是，发 npm 包的仓库直接上 Rslib，省掉自己拼 Rollup + tsc 的功夫；业务应用用 Rsbuild。两者配置文件风格接近，团队里不用记两套心智模型，这点对多人协作很友好。

1.3 Rspress：文档站也能吃到构建红利

Rspress 是基于 Rsbuild 的静态站点生成器，对标的是 VitePress / Docusaurus 这一类。它的优势是和 Rstack 生态共用构建内核——如果你的组件库本身用 Rspack 构建，文档站用 Rspress，构建缓存、依赖版本、插件行为都是一致的，不会出现"组件能编译、文档站编译报错"这种割裂。

用下来的感受：MDX 支持、主题定制、全文搜索、国际化这些常见需求它都覆盖了。要注意的是它的主题扩展点和 VitePress 不完全一样，从 VitePress 迁过来的自定义组件需要改一改挂载方式。对新建文档站来说，它是个很省心的选择。

2. 设计系统怎么选：Arco、Semi 与 IconPark 的定位差异

中后台项目的组件库选型，几乎是每个团队都会纠结一轮的事。字节在这个方向上有两套主流方案，外加一个图标库，经常被放在一起比较，但其实它们的基因完全不同。

2.1 Arco Design：中后台组件密度的代表

Arco Design 是字节较早开源的企业级设计系统，同时提供 React 和 Vue 两个版本，这点在国内组件库里不算常见。它的组件密度偏高，表格、表单、穿梭框这类"数据密集型"组件的功能和可配置项非常全，天生就是冲着中后台、数据管理平台去的。

为什么密度重要？因为中后台一个页面里往往要塞十几个筛选项、几十列数据，组件如果留白太大，一屏信息量就上不去。Arco 在这一点上做得比较克制，默认尺寸偏紧凑。它的主题系统走的是 design token + less 变量的路子，换主题色、调圆角、改间距都比较直接。

需要留意的是，Arco 的 Vue 版本和 React 版本在部分 API 上并非 100% 对齐，跨技术栈复用时别假设它们一模一样，以对应版本文档为准。

2.2 Semi Design：从抖音设计语言长出来的组件库

Semi Design 来自抖音前端团队，主打 React。它的设计语言比 Arco 更"现代"一些，圆角、间距、动效都更接近 C 端产品的观感，所以它不只做中后台，也能撑起偏消费级的界面。它的主题方案用 CSS 变量（design token）驱动，换肤、暗色模式切换是运行时就能生效的，不需要重新编译。

Semi 有个比较讨喜的设计：组件 API 的语义命名比较统一，onChange、value、disabled这类通用属性在各组件间保持一致，学习成本低。它还提供了配套的 D2C（设计稿转代码）和主题商店，设计到开发的链路是打通了的。

两套怎么选？我的判断标准很朴素：偏重数据密度和 Vue 技术栈，看 Arco；偏 React、想要更现代的视觉和更顺畅的换肤，看 Semi。当然如果团队已经有一套设计规范，谁的 token 体系更容易对齐就选谁。

2.3 IconPark：一个被低估的图标方案

IconPark 是个图标库，单看名字容易觉得"图标库有什么好讲的"。但它解决了一个真实的痛点：同一套图标的多主题、多风格复用。传统做法是每个风格一套 SVG，改一次设计要改好几套；IconPark 的思路是"一个 SVG 源文件，通过配置变换出线框、填充、双色、多色四种主题"，改一处就能全体生效。

它还提供在线定制平台，可以在网页上实时调线宽、端点、颜色，导出 React/Vue/SVG 组件。做设计系统的时候，把图标和组件库用同一套视觉参数管理，一致性上省心很多。唯一要注意的是按需引入，整包引入会明显增大体积，用它的 babel/vite 插件做按需加载即可。

3. 数据可视化这条线：VisActor 里的 VChart、VTable、VMind

大屏和数据报表是前端绕不开的场景，VisActor 就是字节在这个方向上的开源套件，包含 VChart、VTable、VMind、VGrammar、VRender 等多个包。这里挑三个最有代表性的讲。

3.1 VChart：用"语法"描述图表而不是堆配置

VChart 是一套图表库，覆盖常见的折线、柱状、饼图、地图、桑基图等几十种图表类型。它和 ECharts 那种"配置驱动"最大的区别是引入了**图形语法（Grammar of Graphics）**的思路：你先声明数据的维度和度量，再声明用哪些视觉通道（位置、颜色、大小）去映射，图表形态是"推导"出来的。

这个思路的好处是可组合。比如想在一张图里叠加柱状和折线、做双轴、做自定义标注，用语法描述会比在 ECharts 里翻文档找对应的 option 更顺。代价是学习曲线略陡，第一次接触要花点时间理解"标记 + 通道"这套概念。

实际项目里，我一般先用官方示例找到最接近的图，再在它的 spec 上改，比从零写快得多。它的跨端能力也值得一提，同一份 spec 在 Web 和移动端（通过对应的渲染方案）能复用。

3.2 VTable：百万行数据下的表格性能边界

VTable 是高性能表格组件，主打的是大数据量 + 复杂表头 + 单元格自定义渲染。中后台最怕的就是表格卡，几万行数据一渲染浏览器直接失去响应。VTable 用的是虚拟滚动 + 按需渲染 + canvas/DOM 混合渲染的方案，官方宣传能撑到百万级单元格。

我自己测过几万行的场景，滚动确实顺。要注意的是：一旦用上 canvas 渲染，单元格内的自定义组件（比如下拉框、富文本）就得走它提供的自定义渲染接口，不能像普通 DOM 表格那样随便往单元格里塞 React 组件。这是性能换来的代价，选型时要评估业务对单元格交互复杂度的要求。

3.3 VMind：把自然语言变成图表的尝试

VMind 是套件里偏"智能"的一块，定位是用自然语言生成图表 spec。你给它一句"按月展示各地区的销售额趋势"，它尝试输出一份可用的图表配置，再交给 VChart 渲染。

它适合什么场景？数据看板里让非技术同学自己"说一句就出图"，或者做 BI 类的产品。但我的建议是别把它当成万能入口——复杂业务口径的数据，语言描述很容易有歧义，生成的图未必对。比较务实的用法是：把它当"初稿生成器"，生成的 spec 开发者再校准，比从零配省时间。这块还在快速迭代，接口以官方文档为准。

4. 框架与运行时：Modern.js、Garfish、Lynx 各自解决什么

除了组件和图表，字节在"应用怎么组织、怎么跑起来"这件事上也有几个项目，覆盖了 Web 工程体系、微前端和跨端三条线。

4.1 Modern.js：约定优于配置的 Web 工程体系

Modern.js 是字节 Web Infra 团队推出的 Web 工程框架，基于 Rsbuild，主打约定式路由和一体化开发。它把路由、数据获取、状态管理这些东西按一套约定组织起来，目录结构定的规矩，减少团队里"每个人写法都不一样"的混乱。

它和 Next.js 的定位有重叠，差异在于它对国内场景的适配更细，比如对微前端、SSR、BFF 的支持都有现成方案。用它的心智负担主要在于"要接受它的约定"——如果你习惯一切配置自己说了算，会觉得它管得有点多；但如果团队人来人往、需要统一规范，约定式反而省沟通成本。我建议先拿它跑一个中等规模的 SSR 项目试试水，再决定要不要全量上。

4.2 Garfish：微前端的沙箱怎么做

Garfish 是字节的微前端框架，解决的是"一个页面里嵌多个独立开发、独立部署的子应用"的问题。它最核心的部分是JS 沙箱和样式隔离：子应用的全局变量、定时器、事件监听都要被框在自己的作用域里，卸载时清理干净，不能污染主应用。

为什么要这么讲究？因为微前端最容易出的问题就是"子应用一卸载，主应用某处就报错"，根源往往是全局变量冲突或者事件没解绑。Garfish 在这块的成熟度还不错，支持运行时注册和构建时注册两种模式，路由、通信也有对应 API。

要提醒的是：微前端不是银弹，它带来的是部署解耦，代价是运行时的复杂度。如果子应用数量少于三个、团队本身协作顺畅，老老实实做单体可能更划算。Garfish 更适合"多个团队、多个技术栈、需要独立发布"的组织。

4.3 Lynx：跨端方向上的新布局

Lynx 是字节在跨端方向上的开源框架，思路和 React Native 那类"JS 驱动原生渲染"接近，但更强调双线程模型：JS 逻辑和 UI 渲染分在不同线程，避免 JS 卡顿直接拖累渲染帧率。它的目标是让一套代码跑在移动端多个平台上，同时保留原生的体验。

跨端框架的选型，我一向建议先问三个问题：团队有没有原生能力维护？业务对性能的要求是不是接近纯原生？有没有大量依赖系统能力？Lynx 这类方案适合"需要跨端但又不满足于纯 WebView 体验"的场景。它相对新，生态还在成长，上手前务必先看官方当前支持的能力清单和版本节奏，别按宣传文案做技术决策。

5. 三个容易被忽略的工具：ByteMD、Vine 和它们的真实使用场景

大框架之外，字节还有几个小体量但用起来很顺的库，平常不太上热搜，但在具体场景里能省不少事。

5.1 ByteMD：为内容场景准备的 Markdown 编辑器

ByteMD 是个 Markdown 编辑器组件，同时提供 React 和 Vue 版本。它的特点是基于插件化的设计：核心只负责编辑，语法高亮、代码块、目录、数学公式这些都是插件，用哪个装哪个。

为什么值得用？因为很多项目的富文本需求其实没那么复杂，只是要个能写 Markdown、能预览、能粘图片的地方。自己拿 textarea 拼一个简陋版本，或者硬上一个重型富文本编辑器，都不划算。ByteMD 体量适中，SSR 也支持，做博客、评论、文档系统挺合适。

要注意的是它的所见即所得模式（WYSIWYG）和纯源码模式行为不完全一样，涉及自定义语法时要两个模式都测一遍。另外图片上传这类能力得自己接，它只提供钩子。

5.2 Vine：Vue 生态里的表单校验方案

Vine 是面向 Vue 的表单校验库，走的是组合式 API的风格：用useForm声明表单结构，字段的校验规则和值绑在一起，交给它管理。相比手写一堆if-else或者用通用校验库再自己拼，它在 Vue 项目里的手感更顺。

表单校验的坑其实都在细节：异步校验怎么处理并发、字段联动怎么触发、错误信息怎么按语言切换。Vine 对这些常见场景都有对应设计。我的经验是，表单字段超过十几个之后，一定要有统一的校验层，否则逻辑会散落在各个组件里，改一个规则要找半天。Vine 是 Vue 项目里实现这层的一个轻量选择。

6. 一份能直接抄的选型思路，以及几个我踩过的坑

把上面 15 个项目按用途归一下类，选型会清楚很多。

先说最大的一个坑：别为了用而用。看到 Rspack 快就把所有项目都迁过去，结果某些依赖 webpack 私有 API 的插件挂了，工期全耗在排错上。我的做法是先在边缘项目试，跑通了再推核心项目，迁移前一定把兼容性清单过一遍。

第二个坑是版本节奏。字节这些项目迭代很快，尤其像 Lynx、VMind 这种较新的，API 变动不算小。锁版本、看 changelog、别直接吃主分支，这是基本纪律。我有次贪方便用了某库的 beta，结果线上样式错位，回滚折腾了半宿。

第三个是生态耦合。Rstack 那几个包共用内核，一起用很顺；但如果你的项目里同时混着 Vite 和 Rspack 两套构建，缓存和插件行为会互相打架。规划的时候，一个仓库尽量统一到一套构建内核上。

最后分享个实操心法：这些项目里，凡是带"在线定制/可视化配置"的（IconPark、VChart 这类），先去官网把示例调到最接近你需求的样子，再把导出的配置粘进项目改，比对着文档一行行写快得多。文档讲的是"能力边界"，示例给的是"能用起点"，后者才是你真正的跳板。