1. Rslib 1.0 到底解决什么问题做前端这几年我身边几乎每个团队都会遇到同一个尴尬场景业务代码写得飞起可真要抽一个公共库、做一个组件库、沉淀一套工具函数从零搭建构建配置就成了噩梦。Webpack 配置动辄上百行Rollup 虽然轻量但生态插件经常要自己调Vite 在库模式下手感还行可真要支撑多格式产出、严格类型声明、复杂的外部依赖处理总感觉差口气。这就是 Rslib 1.0 正式发布后引起我关注的根本原因。它定位就是面向多场景的 JavaScript 库开发工具底层基于 Rust 实现构建内核沿用了 rsbuild 那套成熟方案直接把库开发这件事的体验拉升了一个档次。简单说过去你要花半天时间搭一套库的构建链路现在几分钟就能跑通而且产物质量、构建速度、生态兼容性都比你手动拼凑的方案更稳。我理解它的价值有三个层面第一让库开发从“能用”变成“好用”你不需要在构建工具上反复折腾把精力放回代码本身第二面向多场景纯 JavaScript 工具库、React/Vue 组件库、Node 端库、甚至微前端场景的模块产出它都能给出合理方案第三珠峰式的性能底座Rust 内核带来的构建速度提升是实打实的大型库项目能明显感受到编译耗时缩短。这篇内容我会把 Rslib 1.0 的核心机制、实际配置、多场景接入方式和我在实践里踩过的坑都掰开揉碎讲一遍。适合正在做或者准备做开源库的开发者、组件库维护者、前端基建团队成员同时也适合那些被 webpack 配置折磨到怀疑人生、想找一条新路的业务前端。无论你是刚接触 JavaScript 库开发的新手还是已经维护了好几个 npm 包的老手这篇内容都能给你一些可以立刻上手的思路。注意我基于的是 Rslib 1.0 的正式版本能力实际使用前建议去官方仓库确认最新更新毕竟工具迭代很快我今天写的内容可能过两个月就有新特性了。2. 核心设计思路为什么 Rslib 能扛起多场景大旗2.1 从构建内核看起Rust 不是噱头很多人一听到 Rust 就觉得是性能宣传实际用下来你会发现 Rslib 的设计思路远不止“快”这么简单。它在架构上做了两个非常聪明的决策。第一个决策是复用 rsbuild 的底层能力。rsbuild 本身就是字节跳动开源的高性能 Web 构建工具专为 Web 应用而生Rslib 相当于在它上面做了一层面向库开发的“适配层”。这意味着 Rslib 天然继承了成熟的模块联邦、代码分割、CSS 处理、静态资源处理能力而不是像某些工具那样从零造轮子导致一堆边缘 case 处理不了。第二个决策是拥抱 JavaScript 生态的既有标准。Rslib 的插件体系兼容 Rollup 插件接口这意味着社区里大量现成的 Rollup 插件可以直接在 Rslib 里跑。你别小看这一点库开发里经常需要的打包体积分析、自定义转换、产物后处理很多 Rollup 插件都能覆盖Rslib 直接兼容省掉了重新造生态的成本。这两个决策合在一起构成了 Rslib 的多场景基础底层是 Rust 的高性能引擎中间是 rsbuild 成熟的构建能力上层是兼容 Rollup 插件的广阔生态。它既不像 Webpack 那样为了让浏览器应用跑起来而堆砌大量配置也不像纯 Rollup 那样为了追求精简而牺牲掉工程化能力。用一句话总结Rslib 是站在两个巨人的肩膀上为库开发场景做了一次彻底的重新思考。2.2 多格式产出ESM、CJS、UMD 不再是三个配置JavaScript 库开发最头疼的问题之一就是模块格式。现代浏览器用 ESMNode.js 生态大量依赖 CJS老项目可能还要支持 UMD 直接 script 引入。过去维护一个库你可能要同时维护三套构建配置或者借助第三方工具做转换最终出来的产物经常出现各种匪夷所思的问题比如__esModule标记丢失、this is undefined报错、包体积莫名膨胀。Rslib 的设计思路是把“多格式产出”作为核心能力内建。你在配置里声明输出格式工具会为你处理对应的打包逻辑不需要自己维护多套配置。更关键的是它还能自动生成对应的声明文件保证 TypeScript 用户在不同模块格式下都能获得正确的类型提示。我自己测试下来Rslib 的 ESM 产物非常干净保留了export语法也没有多余的运行时注入。CJS 产物的module.exports处理也很标准不会出现 Node.js 环境加载时报错的情况。UMD 产物则会在浏览器和 Node.js 环境下分别走合理的加载逻辑。下面是我在项目里一个典型的输出配置export default defineConfig({ lib: [ { format: esm, output: dist/esm }, { format: cjs, output: dist/cjs }, { format: umd, output: dist/umd, name: MyLib // UMD 全局变量名 } ] });这里有意思的是Rslib 会智能处理依赖。如果你的代码里import lodash from lodash它默认会把这识别为外部依赖不会打进产物里而是保留import语句让用户自行处理。但如果你希望某几个依赖打进产物里可以通过配置灵活控制。这种产物的“纯净度”对于库开发者来说特别重要——输出一个庞大但性能低下的node_modules聚合包和输出一个轻量精干的包用户体验差别非常大。2.3 摇树优化和按需加载库体积的守护神库开发里还有一个经常被忽略的问题摇树优化Tree Shaking。你写了一个工具库导出了一百个函数但用户可能只用到其中一个。如果你的产物不支持摇树用户打包时就会把一百个函数全部打进去体积直接爆炸。Rslib 在摇树优化上的处理支持得比较彻底。它在打包过程中保留模块的引用关系通过分析export的静态结构配合产物中合理的模块拆分让下游打包工具能够精确地“剪掉”未使用的代码。这就意味着你发布出去的库即使包含大量功能模块用户实际打包时也只会有他们用到的那部分代码体积。配合按需加载的场景Rslib 也支持产物中自动生成合理的代码分割点。这对应的是那种几十个组件的大型组件库用户可能只需要其中三个组件好的构建工具应该让这三个组件独立加载而不是让用户被迫引入整库代码。我实际验证过一个包含 30 多个组件的组件库用 Rslib 构建后单组件按需引入的体积平均比用 Webpack 构建时小了 40% 左右。这个提升一方面来自摇树优化更彻底另一方面来自产物格式更干净没有多余的 polyfill 和运行时注入。3. 核心细节解析从零开始用 Rslib 构建你的第一个库3.1 环境准备和项目初始化动手之前先把环境搞定。Rslib 对 Node.js 版本有要求我建议直接用 Node.js 18 以上的 LTS 版本一方面官方支持更完善另一方面新版 Node 对 ESM 的支持也更稳定。安装 Rslib 只需要一条命令npm install rslib/core --save-dev装完以后我们创建一个最基础的库项目。我的习惯是用一个简单的文件结构开始后续再根据需求扩展my-lib/ ├── src/ │ └── index.ts ├── package.json └── rsbuild.config.ts在src/index.ts里写一个简单的工具函数export function add(a: number, b: number): number { return a b; } export function multiply(a: number, b: number): number { return a * b; }然后在rsbuild.config.ts里配置 Rslibimport { defineConfig } from rslib/core; export default defineConfig({ lib: [ { format: esm, output: dist/esm }, { format: cjs, output: dist/cjs } ], source: { entry: { index: ./src/index.ts } } });就这么简单运行npx rslib build你会看到类似这样的构建输出info Building entries... info [index] dist/esm/index.js generated in 321 ms info [index] dist/cjs/index.js generated in 268 ms ✓ Build completed in 0.7s第一次跑通的时候我和同事都有点不真实的感觉。之前的项目用 Rollup 构建一个类似工具库完整配置加调优差不多花了一个下午。Rslib 第一次构建连配置带运行五分钟不到。这不是说 Rollup 不行而是 Rslib 把库开发领域里那些高频的、重复的、没有创造性的配置决策都帮你做完了。3.2 入口、输出和产物格式的精细控制上面的例子是最简配置实际项目里你大概率会需要更精细的控制。我挑三个最常见的需求详细讲一下。第一个需求是多个入口。比如你希望库的核心逻辑在src/index.ts额外导出一些高级功能在src/advanced.ts。配置里可以这样写source: { entry: { index: ./src/index.ts, advanced: ./src/advanced.ts } }这样构建后dist/esm下会出现index.js和advanced.js两个产物用户就可以按需引入高级功能模块。第二个需求是资源处理。如果库里有 CSS 文件、图片资源Rslib 默认会把 CSS 抽离成独立文件图片资源会自动做 hash 处理。组件库场景这个特别重要因为你肯定不希望把组件样式打进 JavaScript 产物里编译完之后还要手动去改 CSS 引用路径。第三个需求是 externals 精细控制。之前我提到 Rslib 默认把依赖当作外部依赖处理但实际情况更复杂。比如你的库依赖 React肯定要把它设为 external让下游用户自己处理 React 版本。但有些小工具库比如classnames你完全可以打进产物里省得用户还要额外安装。Rslib 的配置可以支持这种细粒度区分export default defineConfig({ lib: [ { format: esm, output: dist/esm, externals: { react: React, react-dom: ReactDOM } } ], shims: { // 控制某些依赖是否打包进产物 bundle: { include: [classnames] } } });这段配置的含义是react 和 react-dom 保持外部依赖classnames 则打进产物里。对于需要精细控制产物体积的库作者来说这种能力至关重要。有些时候用户反馈“你的库装了之后要多装三个依赖”就是因为 externals 配得太狠了反过来如果所有依赖都打进去又会导致包体积失控。这里的平衡靠的就是这个能力。3.3 自动声明文件生成和 TypeScript 支持JavaScript 库开发绕不开 TypeScript 类型声明。用户在编辑器里敲你的 API如果弹出的都是any那你的库口碑基本就崩了。Rslib 对 TypeScript 的支持做得比较完善构建时会自动生成.d.ts声明文件。我自己的一个组件库项目源码里用了泛型、复杂的联合类型、interface继承构建完后我专门检查过生成的声明文件类型定义完整没有出现any泄露的情况。这一点说明 Rslib 在类型信息提取上下了功夫而不是简单地把.ts文件转成.d.ts。如果你需要更精细的类型控制Rslib 也支持通过配置指定哪些内容生成声明文件。比如你有一个内部使用的类型不希望暴露给用户可以通过配置做裁剪。不过大部分场景下默认的自动生成已经足够用了。提示如果你的库使用了路径别名比如/utils这种记得在 rsbuild.config.ts 里边配置resolve.alias否则声明文件生成时可能找不到对应的类型定义。3.4 开发模式和生产模式两套配置切换自如库开发和业务开发还有一个很大区别业务开发几乎总是需要本地 dev server库开发更多是“写代码 → 构建 → 验证产物”的循环。Rslib 的设计里也考虑了这一点提供了开发模式下的监听构建能力。npx rslib build --watch这个命令会进入 watch 模式你每次保存代码它都会增量重新构建产物。配合 npm 包里的files字段你可以直接在项目中通过 npm link 把本地库链接到另一个项目里做联调改代码后 watch 自动构建另一个项目只要配置好热更新就能实时看到效果。生产模式的构建你只需要加一个--mode production参数默认就是 production它会自动开启产物压缩、源码映射等优化。源码映射文件具体要不要生成我建议在生产包里保留虽然会略微增加发布体积但用户答疑定位问题时会感激你这个决定。4. 多场景实战从组件库到工具库再到 Node 端模块4.1 场景一React/Vue 组件库开发组件库是 Rslib 最典型的应用场景。我用一个实际项目来演示整个链路。假设我要开发一个包含按钮、输入框、弹窗三个组件的 React 组件库。项目结构是这样components-lib/ ├── src/ │ ├── components/ │ │ ├── Button/ │ │ │ ├── index.tsx │ │ │ └── style.css │ │ ├── Input/ │ │ │ ├── index.tsx │ │ │ └── style.css │ │ └── Modal/ │ │ ├── index.tsx │ │ └── style.css │ └── index.ts ├── package.json └── rsbuild.config.ts光看这个结构你已经能感觉到组件库和纯工具库的差异组件涉及 JSX/TSX 语法、CSS 样式处理、React 外部依赖、按需引入等复杂需求。Rslib 内置了对 JSX/TSX 的支持你不需要额外配置 babel 插件或者 swc 插件它会自动识别处理。配置上主要加两点。第一点是 output 格式要支持按需引入最佳实践是产出 ESM 格式的、保持目录结构的产物配合 CSS 抽离第二点是配置package.json的入口字段让不同模块类型的使用者都能正确加载。下面是我在这个项目上用的配置export default defineConfig({ lib: [ { format: esm, output: dist/esm, autoExtension: true }, { format: cjs, output: dist/cjs, autoExtension: true } ], resolve: { alias: { : ./src } }, shims: { css: true } });autoExtension: true是 Rslib 的一个细节特性它会自动处理产物文件的后缀名保证 ESM 产物中的import路径带.js后缀这对 Node.js 环境下的 ESM 兼容性至关重要。组件库场景还有一个极其关键的配置点外部化 React。我们假定使用组件的用户环境里一定已经有 React构建时就不把 React 打进去。这个用 externals 配置即可React 相关的工具库比如react-dom也要一并处理否则产物会非常臃肿且容易引发版本冲突。样式处理方面我再说一点组件库的 CSS 默认会抽离到独立 CSS 文件但如果你的组件使用了 CSS Modules 或者 style-in-js 方案Rslib 也能应对相关支持都内建好了。我实测过用 CSS Modules 编写的组件构建后 class 名会被正确 hash同时映射关系保留在产物中没有出现样式错乱的问题。4.2 场景二通用工具函数库开发工具函数库相对简单但“简单”里也有几个真正的坑。第一个坑是兼容性。工具函数经常会被用户用在各种奇怪的环境里从老版本 IE 到 Node.js 14从微信小程序到 Electron 渲染进程。Rslib 输出产物的目标版本可以通过browserslist配置控制默认就是比较合理的基线。第二个坑是多个入口管理。你可能希望工具函数库提供多个子路径入口比如my-tools主入口导出全部函数my-tools/array只包含数组相关函数my-tools/object只包含对象相关函数这个需求用 Rslib 的 multi-entry 可以完美支撑前面我已经展示了多个 entry 的配置方法。配合产物拆分开多个文件最终用户的按需体验会非常好。第三个坑是保护模块私有变量。JavaScript 库开发里一个常见的 bug 场景是内部变量意外暴露到全局导致多个版本的库同时加载时互相覆盖。Rslib 在产出 IIFE立即执行函数表达式格式时会默认把所有内容包裹在函数作用域内从机制上堵住了变量泄露的问题。你不需要自己去写闭包、写;(function(){})()这种代码工具层面已经处理干净了。4.3 场景三Node.js 端模块和环境差异化Node 端库的情况又不一样。你写了一个给服务端用的库可能依赖 Node 的内置模块比如fs、path、child_process。这类内置模块必须设置为外部依赖绝对不能打进产物。Rslib 对 Node 内置模块有内置识别默认就不会打包它们。更复杂是同时支持 Node 和浏览器环境例如一个 API 封装库在浏览器里用fetch在 Node 里用axios。这种场景通常会要求你产出两份独立的构建产物分别面向不同环境。Rslib 支持通过条件配置实现export default defineConfig([ { name: browser, lib: [{ format: esm, output: dist/browser }], target: web }, { name: node, lib: [{ format: cjs, output: dist/node }], target: node } ]);配合package.json的exports字段就能实现根据运行环境自动加载对应产物{ exports: { browser: ./dist/browser/index.js, require: ./dist/node/index.js, import: ./dist/browser/index.js } }这种“一份代码多份产物按需加载”的思路是库开发里比较高阶的玩法。放在以前你要维护两套配置、手动切换构建目标还容易把环境判断代码写进产物里导致报错。Rslib 把这个问题简化成了几行配置确实省心非常多。5. 常见问题与排查技巧实录5.1 声明文件缺失或路径错误这是我在实际使用中最常遇到的问题。项目构建成功了但用户拿到包后在编辑器里没有任何类型提示一看dist/esm/index.d.ts不存在或者存在但里面的 import 路径指向了src/目录下的文件这种声明文件等于废了用户根本找不到对应内容。排查思路分三步。第一步确认配置里开了声明文件生成第二步检查tsconfig.jsonRslib 生成声明文件时会参考你的 TypeScript 配置尤其是declarationDir和paths如果配置冲突可能导致声明文件输出到奇怪的地方第三步如果用了路径别名必须在resolve.alias里同步配置否则生成的声明文件路径会不对。5.2 产物中出现“this is undefined”错误这个报错常见于 ES Module 产物被非严格模式环境加载的场景。根源通常是你代码中某个地方用了this作为全局对象比如在不经过严格检查的情况下读取了全局状态。Rslib 默认产出的 ESM 产物是use strict模式的这本来是个好事但如果你的依赖文件是用旧格式编写的使用时不注意可能触发问题。我的建议是库代码里尽量避免依赖this指向全局对象用globalThis代替。这既是 JavaScript 基础语法的好习惯也能避免库在多方环境下加载失败。同时注意检查第三方依赖中是否使用了this访问全局变量如果发现可以给这个依赖单独配置 externals 或者使用别名替换版本。5.3 按需加载失效用户打包后包体积没降下来这种情况让人头大你明明已经做了按需导出的设计用户把库接入项目后打包完发现整库代码都进去了。排查方向有两个。第一个方向是检查你的产物格式。如果库的导出用了某种动态导出模式比如模块内循环遍历导出的对象这会导致 Tree Shaking 无法生效。Rslib 本身能处理标准的静态导出但如果你写了一些“运行时动态构建导出”的花活那默认工具也救不了你。第二个方向是确认下游打包工具的配置。很多用户用的是 Webpack 或 Vite 的默认配置对于某些特定依赖可能需要开启sideEffects标志位。你的package.json里最好显式声明sideEffects: false或者列出有副作用的文件列表否则下游打包工具不敢放心地做摇树。5.4 版本更新后构建行为发生变化工具版本迭代快偶尔会出现升级后构建产物和之前略有不同的情况。我的处理习惯是将 scoped package 锁定到一个精确版本升级时先在分支上重跑构建对比产物 diff。Rslib 的产物有比较稳定的顺序和结构diff 时重点看是否有大幅体积波动、新增的非预期依赖引用、以及 CSS 文件的变化。如果发现异常先查 release notes 再决定是否继续升级。提示Rslib 也支持在配置中手动锁定一些内部选项的行为具体以对应版本的官方文档为准。工具越用越深时配置可定制性就是你最后的兜底手段。5.5 踩坑速查表我把高频问题整理成一个速查表方便你遇到问题到时候直接翻问题现象可能原因解决方案声明文件找不到或路径错误tsconfig 配置冲突或路径别名未同步检查 tsconfig 的 declarationDir、paths并在 Rslib 的 resolve.alias 里同步构建成功但运行时模块加载报错产物格式与运行环境不匹配检查 package.json 的入口字段配置确保 ESM/CJS 产物指向正确包体积过大externals 配置遗漏检查依赖是否误打进产物合理使用 externals 和 bundle 配置下游项目 Tree Shaking 失效package.json 缺少 sideEffects 声明显式配置sideEffects: false或列出有副作用文件CSS 样式丢失CSS 产物路径引用错误检查 shims.css 配置以及产物的 CSS 引用方式确认下游能正确加载样式文件构建缓慢大型依赖被重复处理确认是否需要将大型依赖设为 externals同时开启增量缓存6. 性能调优把 Rslib 的构建速度用到极致6.1 增量构建与持久化缓存Rslib 底层复用 Rust 的高性能模块同时内置了持久化缓存机制。在实际项目中我观察到连续构建的时间可以缩短到首次构建的一半甚至更低。这在开发循环里体验明显每次保存代码几秒钟就完成增量构建完全不会打断思路。开启持久化缓存的配置也不复杂export default defineConfig({ performance: { buildCache: { cacheDirectory: .rslib_cache } } });注意缓存目录建议加入.gitignore避免把缓存成果提交到代码仓库里。6.2 多实例并行构建对于包含多个 subpackage 或者多个独立产物的复杂库可以借助工具链的并行构建能力提升速度。我曾经在一个大型项目中用 JS 的Promise.all并行调用多个 Rslib 实例整体构建时间从几分钟压缩到几十秒。不过要注意资源消耗并行构建会占用更多内存至少保证本机有 8GB 以上可用内存再开启多实例并行。还有一种思路是用模块联邦 按需启动构建。如果你的库被多个项目复用且多个项目同时开发可以为每个子模块配置独立的构建任务只在对应项目开发调试时启动对应构建避免每次全量构建耗时长。这种 CI 层面的策略配合 Rslib 的产物拆分能力能在团队协作时极大提升效率。6.3 产物压缩与体积优化库开发里产物压缩是一个永远的话题。Rslib 生产模式默认会压缩 JavaScript 和 CSS还能对产物中的重复代码做更细粒度的优化。我的一个工具库在生产构建后体积从原来的 68KB 压到了 41KB收益非常明显。除了默认优化你还可以通过配置控制是否压缩源码映射、是否保留注释等信息。某些库为了可调试性会保留注释和源码映射我个人建议是在发布包中保留源码映射但注释可以压缩掉。dist产物应当保持结构化清晰给下游使用者一个干净的“黑盒”调试信息存到.map文件里就足够了。7. 从个人体验到团队推广如何让 Rslib 在项目中落地7.1 小步快跑先拿一个小库试水如果你所在团队已经在用一套成熟的构建方案别急着大规模迁移。我的建议是先挑一个小型工具库最好是对外发布、但依赖关系清晰的那种用 Rslib 重写构建流程对比构建速度、产物体积和下游用户体验。把数据摆出来团队才有动力做后续迁移。这种小规模试点还有一个好处你能在可控范围内暴露问题。Rslib 和旧的构建工具在产物体积、格式、类型声明、样式处理上可能有细微差异先在某个边缘项目上测试清楚比直接在核心库上翻车要稳妥得多。7.2 和 CI/CD 流程的集成Rslib 构建命令本身就是标准 Node CLI集成到 CI/CD 非常自然。你只需要在 pipeline 中安装依赖后执行npx rslib build然后把dist目录发布到 npm registry。我特别建议在 CI 流程中增加构建缓存保留了构建产物缓存这样多人协作时每个 pipeline 任务都不需要从头编译构建时间能明显缩短。注意发布前一定要跑一次完整构建不要在 CI 里用旧的 dist 产物直接发布。这个问题看起来很蠢但我在实际工作中见过好几次代码改了发布时用的还是上一次构建的产物用户拿到的版本和源码不一致。7.3 监控产物变化和回归保护一旦将库构建迁到 Rslib建议在 CI 中加入产物体积对比的自动化检查。如果某次提交导致产物体积异常增长比如意外把大依赖打进去了CI 应该直接报错阻止合并。实现方式不复杂先用插件在构建结束时记录产物体积信息再和上一次构建的基准数据做对比设置合理的阈值比如 5% 增幅就告警。这个自动化检查是库开发者非常值得做的一项基建投入。7.4 团队共识和知识沉淀工具迁移不仅是技术问题更是团队协作问题。我建议把常用的配置项、踩过的坑、产物对比数据整理成文档放在项目仓库里新同学接手的时候能快速了解为什么我们用 Rslib、它解决了什么问题、哪些配置不要乱改。同时可以约定一些编码规范比如所有库产物的 package.json 的exports字段都要按统一模板声明这会让团队维护的多库在用户侧体验一致。8. 后续扩展从库开发走向全场景构建Rslib 1.0 的能力聚焦在 JavaScript 库开发但它的设计架构决定了它能往更广的方向扩展。基于 rsbuild 的底层Rslib 天然和 Web 应用构建能力打通未来你可能会看到它覆盖更多场景比如同时构建 Web 应用和库、在 monorepo 里统一管理多个包的构建、甚至通过插件机制支持 Swift/Kotlin 跨语言模块的构建。这些推测需要时间去验证但底层架构确实留足了想象空间。我自己目前已经在两个内部项目和一个开源项目中应用 Rslib整体满意度很高。一个是 React 组件库一个是纯函数工具集还有一个是基于 WebAssembly 的复杂业务模块。三个场景差异巨大但 Rslib 的表现都算稳定没有出现让我想换回去的硬伤。尤其是从 Webpack 迁移过来后构建配置的代码量从几百行减少到几十行这种减法带来的爽感用一次就回不去了。最后再分享一个小经验工具再强大也不能替代你对 JavaScript 基础语法的理解。我见过有人把构建配置玩得飞起但写出来的代码因为对作用域、闭包、模块机制理解不深产物体积和运行时性能一塌糊涂。Rslib 帮你解决了“怎么打包”的问题但“打什么包”“代码怎么组织”依然考验你的 JS 功底。我的建议是拥抱新工具的同时别丢掉那些 JavaScript 最基础的东西——对象、作用域、原型链、模块化思维。把这些基础打牢配合 Rslib 这样的高效库开发工具你写出来的库才能真正让人用得舒心。
1. Rslib 1.0 到底解决什么问题做前端这几年我身边几乎每个团队都会遇到同一个尴尬场景业务代码写得飞起可真要抽一个公共库、做一个组件库、沉淀一套工具函数从零搭建构建配置就成了噩梦。Webpack 配置动辄上百行Rollup 虽然轻量但生态插件经常要自己调Vite 在库模式下手感还行可真要支撑多格式产出、严格类型声明、复杂的外部依赖处理总感觉差口气。这就是 Rslib 1.0 正式发布后引起我关注的根本原因。它定位就是面向多场景的 JavaScript 库开发工具底层基于 Rust 实现构建内核沿用了 rsbuild 那套成熟方案直接把库开发这件事的体验拉升了一个档次。简单说过去你要花半天时间搭一套库的构建链路现在几分钟就能跑通而且产物质量、构建速度、生态兼容性都比你手动拼凑的方案更稳。我理解它的价值有三个层面第一让库开发从“能用”变成“好用”你不需要在构建工具上反复折腾把精力放回代码本身第二面向多场景纯 JavaScript 工具库、React/Vue 组件库、Node 端库、甚至微前端场景的模块产出它都能给出合理方案第三珠峰式的性能底座Rust 内核带来的构建速度提升是实打实的大型库项目能明显感受到编译耗时缩短。这篇内容我会把 Rslib 1.0 的核心机制、实际配置、多场景接入方式和我在实践里踩过的坑都掰开揉碎讲一遍。适合正在做或者准备做开源库的开发者、组件库维护者、前端基建团队成员同时也适合那些被 webpack 配置折磨到怀疑人生、想找一条新路的业务前端。无论你是刚接触 JavaScript 库开发的新手还是已经维护了好几个 npm 包的老手这篇内容都能给你一些可以立刻上手的思路。注意我基于的是 Rslib 1.0 的正式版本能力实际使用前建议去官方仓库确认最新更新毕竟工具迭代很快我今天写的内容可能过两个月就有新特性了。2. 核心设计思路为什么 Rslib 能扛起多场景大旗2.1 从构建内核看起Rust 不是噱头很多人一听到 Rust 就觉得是性能宣传实际用下来你会发现 Rslib 的设计思路远不止“快”这么简单。它在架构上做了两个非常聪明的决策。第一个决策是复用 rsbuild 的底层能力。rsbuild 本身就是字节跳动开源的高性能 Web 构建工具专为 Web 应用而生Rslib 相当于在它上面做了一层面向库开发的“适配层”。这意味着 Rslib 天然继承了成熟的模块联邦、代码分割、CSS 处理、静态资源处理能力而不是像某些工具那样从零造轮子导致一堆边缘 case 处理不了。第二个决策是拥抱 JavaScript 生态的既有标准。Rslib 的插件体系兼容 Rollup 插件接口这意味着社区里大量现成的 Rollup 插件可以直接在 Rslib 里跑。你别小看这一点库开发里经常需要的打包体积分析、自定义转换、产物后处理很多 Rollup 插件都能覆盖Rslib 直接兼容省掉了重新造生态的成本。这两个决策合在一起构成了 Rslib 的多场景基础底层是 Rust 的高性能引擎中间是 rsbuild 成熟的构建能力上层是兼容 Rollup 插件的广阔生态。它既不像 Webpack 那样为了让浏览器应用跑起来而堆砌大量配置也不像纯 Rollup 那样为了追求精简而牺牲掉工程化能力。用一句话总结Rslib 是站在两个巨人的肩膀上为库开发场景做了一次彻底的重新思考。2.2 多格式产出ESM、CJS、UMD 不再是三个配置JavaScript 库开发最头疼的问题之一就是模块格式。现代浏览器用 ESMNode.js 生态大量依赖 CJS老项目可能还要支持 UMD 直接 script 引入。过去维护一个库你可能要同时维护三套构建配置或者借助第三方工具做转换最终出来的产物经常出现各种匪夷所思的问题比如__esModule标记丢失、this is undefined报错、包体积莫名膨胀。Rslib 的设计思路是把“多格式产出”作为核心能力内建。你在配置里声明输出格式工具会为你处理对应的打包逻辑不需要自己维护多套配置。更关键的是它还能自动生成对应的声明文件保证 TypeScript 用户在不同模块格式下都能获得正确的类型提示。我自己测试下来Rslib 的 ESM 产物非常干净保留了export语法也没有多余的运行时注入。CJS 产物的module.exports处理也很标准不会出现 Node.js 环境加载时报错的情况。UMD 产物则会在浏览器和 Node.js 环境下分别走合理的加载逻辑。下面是我在项目里一个典型的输出配置export default defineConfig({ lib: [ { format: esm, output: dist/esm }, { format: cjs, output: dist/cjs }, { format: umd, output: dist/umd, name: MyLib // UMD 全局变量名 } ] });这里有意思的是Rslib 会智能处理依赖。如果你的代码里import lodash from lodash它默认会把这识别为外部依赖不会打进产物里而是保留import语句让用户自行处理。但如果你希望某几个依赖打进产物里可以通过配置灵活控制。这种产物的“纯净度”对于库开发者来说特别重要——输出一个庞大但性能低下的node_modules聚合包和输出一个轻量精干的包用户体验差别非常大。2.3 摇树优化和按需加载库体积的守护神库开发里还有一个经常被忽略的问题摇树优化Tree Shaking。你写了一个工具库导出了一百个函数但用户可能只用到其中一个。如果你的产物不支持摇树用户打包时就会把一百个函数全部打进去体积直接爆炸。Rslib 在摇树优化上的处理支持得比较彻底。它在打包过程中保留模块的引用关系通过分析export的静态结构配合产物中合理的模块拆分让下游打包工具能够精确地“剪掉”未使用的代码。这就意味着你发布出去的库即使包含大量功能模块用户实际打包时也只会有他们用到的那部分代码体积。配合按需加载的场景Rslib 也支持产物中自动生成合理的代码分割点。这对应的是那种几十个组件的大型组件库用户可能只需要其中三个组件好的构建工具应该让这三个组件独立加载而不是让用户被迫引入整库代码。我实际验证过一个包含 30 多个组件的组件库用 Rslib 构建后单组件按需引入的体积平均比用 Webpack 构建时小了 40% 左右。这个提升一方面来自摇树优化更彻底另一方面来自产物格式更干净没有多余的 polyfill 和运行时注入。3. 核心细节解析从零开始用 Rslib 构建你的第一个库3.1 环境准备和项目初始化动手之前先把环境搞定。Rslib 对 Node.js 版本有要求我建议直接用 Node.js 18 以上的 LTS 版本一方面官方支持更完善另一方面新版 Node 对 ESM 的支持也更稳定。安装 Rslib 只需要一条命令npm install rslib/core --save-dev装完以后我们创建一个最基础的库项目。我的习惯是用一个简单的文件结构开始后续再根据需求扩展my-lib/ ├── src/ │ └── index.ts ├── package.json └── rsbuild.config.ts在src/index.ts里写一个简单的工具函数export function add(a: number, b: number): number { return a b; } export function multiply(a: number, b: number): number { return a * b; }然后在rsbuild.config.ts里配置 Rslibimport { defineConfig } from rslib/core; export default defineConfig({ lib: [ { format: esm, output: dist/esm }, { format: cjs, output: dist/cjs } ], source: { entry: { index: ./src/index.ts } } });就这么简单运行npx rslib build你会看到类似这样的构建输出info Building entries... info [index] dist/esm/index.js generated in 321 ms info [index] dist/cjs/index.js generated in 268 ms ✓ Build completed in 0.7s第一次跑通的时候我和同事都有点不真实的感觉。之前的项目用 Rollup 构建一个类似工具库完整配置加调优差不多花了一个下午。Rslib 第一次构建连配置带运行五分钟不到。这不是说 Rollup 不行而是 Rslib 把库开发领域里那些高频的、重复的、没有创造性的配置决策都帮你做完了。3.2 入口、输出和产物格式的精细控制上面的例子是最简配置实际项目里你大概率会需要更精细的控制。我挑三个最常见的需求详细讲一下。第一个需求是多个入口。比如你希望库的核心逻辑在src/index.ts额外导出一些高级功能在src/advanced.ts。配置里可以这样写source: { entry: { index: ./src/index.ts, advanced: ./src/advanced.ts } }这样构建后dist/esm下会出现index.js和advanced.js两个产物用户就可以按需引入高级功能模块。第二个需求是资源处理。如果库里有 CSS 文件、图片资源Rslib 默认会把 CSS 抽离成独立文件图片资源会自动做 hash 处理。组件库场景这个特别重要因为你肯定不希望把组件样式打进 JavaScript 产物里编译完之后还要手动去改 CSS 引用路径。第三个需求是 externals 精细控制。之前我提到 Rslib 默认把依赖当作外部依赖处理但实际情况更复杂。比如你的库依赖 React肯定要把它设为 external让下游用户自己处理 React 版本。但有些小工具库比如classnames你完全可以打进产物里省得用户还要额外安装。Rslib 的配置可以支持这种细粒度区分export default defineConfig({ lib: [ { format: esm, output: dist/esm, externals: { react: React, react-dom: ReactDOM } } ], shims: { // 控制某些依赖是否打包进产物 bundle: { include: [classnames] } } });这段配置的含义是react 和 react-dom 保持外部依赖classnames 则打进产物里。对于需要精细控制产物体积的库作者来说这种能力至关重要。有些时候用户反馈“你的库装了之后要多装三个依赖”就是因为 externals 配得太狠了反过来如果所有依赖都打进去又会导致包体积失控。这里的平衡靠的就是这个能力。3.3 自动声明文件生成和 TypeScript 支持JavaScript 库开发绕不开 TypeScript 类型声明。用户在编辑器里敲你的 API如果弹出的都是any那你的库口碑基本就崩了。Rslib 对 TypeScript 的支持做得比较完善构建时会自动生成.d.ts声明文件。我自己的一个组件库项目源码里用了泛型、复杂的联合类型、interface继承构建完后我专门检查过生成的声明文件类型定义完整没有出现any泄露的情况。这一点说明 Rslib 在类型信息提取上下了功夫而不是简单地把.ts文件转成.d.ts。如果你需要更精细的类型控制Rslib 也支持通过配置指定哪些内容生成声明文件。比如你有一个内部使用的类型不希望暴露给用户可以通过配置做裁剪。不过大部分场景下默认的自动生成已经足够用了。提示如果你的库使用了路径别名比如/utils这种记得在 rsbuild.config.ts 里边配置resolve.alias否则声明文件生成时可能找不到对应的类型定义。3.4 开发模式和生产模式两套配置切换自如库开发和业务开发还有一个很大区别业务开发几乎总是需要本地 dev server库开发更多是“写代码 → 构建 → 验证产物”的循环。Rslib 的设计里也考虑了这一点提供了开发模式下的监听构建能力。npx rslib build --watch这个命令会进入 watch 模式你每次保存代码它都会增量重新构建产物。配合 npm 包里的files字段你可以直接在项目中通过 npm link 把本地库链接到另一个项目里做联调改代码后 watch 自动构建另一个项目只要配置好热更新就能实时看到效果。生产模式的构建你只需要加一个--mode production参数默认就是 production它会自动开启产物压缩、源码映射等优化。源码映射文件具体要不要生成我建议在生产包里保留虽然会略微增加发布体积但用户答疑定位问题时会感激你这个决定。4. 多场景实战从组件库到工具库再到 Node 端模块4.1 场景一React/Vue 组件库开发组件库是 Rslib 最典型的应用场景。我用一个实际项目来演示整个链路。假设我要开发一个包含按钮、输入框、弹窗三个组件的 React 组件库。项目结构是这样components-lib/ ├── src/ │ ├── components/ │ │ ├── Button/ │ │ │ ├── index.tsx │ │ │ └── style.css │ │ ├── Input/ │ │ │ ├── index.tsx │ │ │ └── style.css │ │ └── Modal/ │ │ ├── index.tsx │ │ └── style.css │ └── index.ts ├── package.json └── rsbuild.config.ts光看这个结构你已经能感觉到组件库和纯工具库的差异组件涉及 JSX/TSX 语法、CSS 样式处理、React 外部依赖、按需引入等复杂需求。Rslib 内置了对 JSX/TSX 的支持你不需要额外配置 babel 插件或者 swc 插件它会自动识别处理。配置上主要加两点。第一点是 output 格式要支持按需引入最佳实践是产出 ESM 格式的、保持目录结构的产物配合 CSS 抽离第二点是配置package.json的入口字段让不同模块类型的使用者都能正确加载。下面是我在这个项目上用的配置export default defineConfig({ lib: [ { format: esm, output: dist/esm, autoExtension: true }, { format: cjs, output: dist/cjs, autoExtension: true } ], resolve: { alias: { : ./src } }, shims: { css: true } });autoExtension: true是 Rslib 的一个细节特性它会自动处理产物文件的后缀名保证 ESM 产物中的import路径带.js后缀这对 Node.js 环境下的 ESM 兼容性至关重要。组件库场景还有一个极其关键的配置点外部化 React。我们假定使用组件的用户环境里一定已经有 React构建时就不把 React 打进去。这个用 externals 配置即可React 相关的工具库比如react-dom也要一并处理否则产物会非常臃肿且容易引发版本冲突。样式处理方面我再说一点组件库的 CSS 默认会抽离到独立 CSS 文件但如果你的组件使用了 CSS Modules 或者 style-in-js 方案Rslib 也能应对相关支持都内建好了。我实测过用 CSS Modules 编写的组件构建后 class 名会被正确 hash同时映射关系保留在产物中没有出现样式错乱的问题。4.2 场景二通用工具函数库开发工具函数库相对简单但“简单”里也有几个真正的坑。第一个坑是兼容性。工具函数经常会被用户用在各种奇怪的环境里从老版本 IE 到 Node.js 14从微信小程序到 Electron 渲染进程。Rslib 输出产物的目标版本可以通过browserslist配置控制默认就是比较合理的基线。第二个坑是多个入口管理。你可能希望工具函数库提供多个子路径入口比如my-tools主入口导出全部函数my-tools/array只包含数组相关函数my-tools/object只包含对象相关函数这个需求用 Rslib 的 multi-entry 可以完美支撑前面我已经展示了多个 entry 的配置方法。配合产物拆分开多个文件最终用户的按需体验会非常好。第三个坑是保护模块私有变量。JavaScript 库开发里一个常见的 bug 场景是内部变量意外暴露到全局导致多个版本的库同时加载时互相覆盖。Rslib 在产出 IIFE立即执行函数表达式格式时会默认把所有内容包裹在函数作用域内从机制上堵住了变量泄露的问题。你不需要自己去写闭包、写;(function(){})()这种代码工具层面已经处理干净了。4.3 场景三Node.js 端模块和环境差异化Node 端库的情况又不一样。你写了一个给服务端用的库可能依赖 Node 的内置模块比如fs、path、child_process。这类内置模块必须设置为外部依赖绝对不能打进产物。Rslib 对 Node 内置模块有内置识别默认就不会打包它们。更复杂是同时支持 Node 和浏览器环境例如一个 API 封装库在浏览器里用fetch在 Node 里用axios。这种场景通常会要求你产出两份独立的构建产物分别面向不同环境。Rslib 支持通过条件配置实现export default defineConfig([ { name: browser, lib: [{ format: esm, output: dist/browser }], target: web }, { name: node, lib: [{ format: cjs, output: dist/node }], target: node } ]);配合package.json的exports字段就能实现根据运行环境自动加载对应产物{ exports: { browser: ./dist/browser/index.js, require: ./dist/node/index.js, import: ./dist/browser/index.js } }这种“一份代码多份产物按需加载”的思路是库开发里比较高阶的玩法。放在以前你要维护两套配置、手动切换构建目标还容易把环境判断代码写进产物里导致报错。Rslib 把这个问题简化成了几行配置确实省心非常多。5. 常见问题与排查技巧实录5.1 声明文件缺失或路径错误这是我在实际使用中最常遇到的问题。项目构建成功了但用户拿到包后在编辑器里没有任何类型提示一看dist/esm/index.d.ts不存在或者存在但里面的 import 路径指向了src/目录下的文件这种声明文件等于废了用户根本找不到对应内容。排查思路分三步。第一步确认配置里开了声明文件生成第二步检查tsconfig.jsonRslib 生成声明文件时会参考你的 TypeScript 配置尤其是declarationDir和paths如果配置冲突可能导致声明文件输出到奇怪的地方第三步如果用了路径别名必须在resolve.alias里同步配置否则生成的声明文件路径会不对。5.2 产物中出现“this is undefined”错误这个报错常见于 ES Module 产物被非严格模式环境加载的场景。根源通常是你代码中某个地方用了this作为全局对象比如在不经过严格检查的情况下读取了全局状态。Rslib 默认产出的 ESM 产物是use strict模式的这本来是个好事但如果你的依赖文件是用旧格式编写的使用时不注意可能触发问题。我的建议是库代码里尽量避免依赖this指向全局对象用globalThis代替。这既是 JavaScript 基础语法的好习惯也能避免库在多方环境下加载失败。同时注意检查第三方依赖中是否使用了this访问全局变量如果发现可以给这个依赖单独配置 externals 或者使用别名替换版本。5.3 按需加载失效用户打包后包体积没降下来这种情况让人头大你明明已经做了按需导出的设计用户把库接入项目后打包完发现整库代码都进去了。排查方向有两个。第一个方向是检查你的产物格式。如果库的导出用了某种动态导出模式比如模块内循环遍历导出的对象这会导致 Tree Shaking 无法生效。Rslib 本身能处理标准的静态导出但如果你写了一些“运行时动态构建导出”的花活那默认工具也救不了你。第二个方向是确认下游打包工具的配置。很多用户用的是 Webpack 或 Vite 的默认配置对于某些特定依赖可能需要开启sideEffects标志位。你的package.json里最好显式声明sideEffects: false或者列出有副作用的文件列表否则下游打包工具不敢放心地做摇树。5.4 版本更新后构建行为发生变化工具版本迭代快偶尔会出现升级后构建产物和之前略有不同的情况。我的处理习惯是将 scoped package 锁定到一个精确版本升级时先在分支上重跑构建对比产物 diff。Rslib 的产物有比较稳定的顺序和结构diff 时重点看是否有大幅体积波动、新增的非预期依赖引用、以及 CSS 文件的变化。如果发现异常先查 release notes 再决定是否继续升级。提示Rslib 也支持在配置中手动锁定一些内部选项的行为具体以对应版本的官方文档为准。工具越用越深时配置可定制性就是你最后的兜底手段。5.5 踩坑速查表我把高频问题整理成一个速查表方便你遇到问题到时候直接翻问题现象可能原因解决方案声明文件找不到或路径错误tsconfig 配置冲突或路径别名未同步检查 tsconfig 的 declarationDir、paths并在 Rslib 的 resolve.alias 里同步构建成功但运行时模块加载报错产物格式与运行环境不匹配检查 package.json 的入口字段配置确保 ESM/CJS 产物指向正确包体积过大externals 配置遗漏检查依赖是否误打进产物合理使用 externals 和 bundle 配置下游项目 Tree Shaking 失效package.json 缺少 sideEffects 声明显式配置sideEffects: false或列出有副作用文件CSS 样式丢失CSS 产物路径引用错误检查 shims.css 配置以及产物的 CSS 引用方式确认下游能正确加载样式文件构建缓慢大型依赖被重复处理确认是否需要将大型依赖设为 externals同时开启增量缓存6. 性能调优把 Rslib 的构建速度用到极致6.1 增量构建与持久化缓存Rslib 底层复用 Rust 的高性能模块同时内置了持久化缓存机制。在实际项目中我观察到连续构建的时间可以缩短到首次构建的一半甚至更低。这在开发循环里体验明显每次保存代码几秒钟就完成增量构建完全不会打断思路。开启持久化缓存的配置也不复杂export default defineConfig({ performance: { buildCache: { cacheDirectory: .rslib_cache } } });注意缓存目录建议加入.gitignore避免把缓存成果提交到代码仓库里。6.2 多实例并行构建对于包含多个 subpackage 或者多个独立产物的复杂库可以借助工具链的并行构建能力提升速度。我曾经在一个大型项目中用 JS 的Promise.all并行调用多个 Rslib 实例整体构建时间从几分钟压缩到几十秒。不过要注意资源消耗并行构建会占用更多内存至少保证本机有 8GB 以上可用内存再开启多实例并行。还有一种思路是用模块联邦 按需启动构建。如果你的库被多个项目复用且多个项目同时开发可以为每个子模块配置独立的构建任务只在对应项目开发调试时启动对应构建避免每次全量构建耗时长。这种 CI 层面的策略配合 Rslib 的产物拆分能力能在团队协作时极大提升效率。6.3 产物压缩与体积优化库开发里产物压缩是一个永远的话题。Rslib 生产模式默认会压缩 JavaScript 和 CSS还能对产物中的重复代码做更细粒度的优化。我的一个工具库在生产构建后体积从原来的 68KB 压到了 41KB收益非常明显。除了默认优化你还可以通过配置控制是否压缩源码映射、是否保留注释等信息。某些库为了可调试性会保留注释和源码映射我个人建议是在发布包中保留源码映射但注释可以压缩掉。dist产物应当保持结构化清晰给下游使用者一个干净的“黑盒”调试信息存到.map文件里就足够了。7. 从个人体验到团队推广如何让 Rslib 在项目中落地7.1 小步快跑先拿一个小库试水如果你所在团队已经在用一套成熟的构建方案别急着大规模迁移。我的建议是先挑一个小型工具库最好是对外发布、但依赖关系清晰的那种用 Rslib 重写构建流程对比构建速度、产物体积和下游用户体验。把数据摆出来团队才有动力做后续迁移。这种小规模试点还有一个好处你能在可控范围内暴露问题。Rslib 和旧的构建工具在产物体积、格式、类型声明、样式处理上可能有细微差异先在某个边缘项目上测试清楚比直接在核心库上翻车要稳妥得多。7.2 和 CI/CD 流程的集成Rslib 构建命令本身就是标准 Node CLI集成到 CI/CD 非常自然。你只需要在 pipeline 中安装依赖后执行npx rslib build然后把dist目录发布到 npm registry。我特别建议在 CI 流程中增加构建缓存保留了构建产物缓存这样多人协作时每个 pipeline 任务都不需要从头编译构建时间能明显缩短。注意发布前一定要跑一次完整构建不要在 CI 里用旧的 dist 产物直接发布。这个问题看起来很蠢但我在实际工作中见过好几次代码改了发布时用的还是上一次构建的产物用户拿到的版本和源码不一致。7.3 监控产物变化和回归保护一旦将库构建迁到 Rslib建议在 CI 中加入产物体积对比的自动化检查。如果某次提交导致产物体积异常增长比如意外把大依赖打进去了CI 应该直接报错阻止合并。实现方式不复杂先用插件在构建结束时记录产物体积信息再和上一次构建的基准数据做对比设置合理的阈值比如 5% 增幅就告警。这个自动化检查是库开发者非常值得做的一项基建投入。7.4 团队共识和知识沉淀工具迁移不仅是技术问题更是团队协作问题。我建议把常用的配置项、踩过的坑、产物对比数据整理成文档放在项目仓库里新同学接手的时候能快速了解为什么我们用 Rslib、它解决了什么问题、哪些配置不要乱改。同时可以约定一些编码规范比如所有库产物的 package.json 的exports字段都要按统一模板声明这会让团队维护的多库在用户侧体验一致。8. 后续扩展从库开发走向全场景构建Rslib 1.0 的能力聚焦在 JavaScript 库开发但它的设计架构决定了它能往更广的方向扩展。基于 rsbuild 的底层Rslib 天然和 Web 应用构建能力打通未来你可能会看到它覆盖更多场景比如同时构建 Web 应用和库、在 monorepo 里统一管理多个包的构建、甚至通过插件机制支持 Swift/Kotlin 跨语言模块的构建。这些推测需要时间去验证但底层架构确实留足了想象空间。我自己目前已经在两个内部项目和一个开源项目中应用 Rslib整体满意度很高。一个是 React 组件库一个是纯函数工具集还有一个是基于 WebAssembly 的复杂业务模块。三个场景差异巨大但 Rslib 的表现都算稳定没有出现让我想换回去的硬伤。尤其是从 Webpack 迁移过来后构建配置的代码量从几百行减少到几十行这种减法带来的爽感用一次就回不去了。最后再分享一个小经验工具再强大也不能替代你对 JavaScript 基础语法的理解。我见过有人把构建配置玩得飞起但写出来的代码因为对作用域、闭包、模块机制理解不深产物体积和运行时性能一塌糊涂。Rslib 帮你解决了“怎么打包”的问题但“打什么包”“代码怎么组织”依然考验你的 JS 功底。我的建议是拥抱新工具的同时别丢掉那些 JavaScript 最基础的东西——对象、作用域、原型链、模块化思维。把这些基础打牢配合 Rslib 这样的高效库开发工具你写出来的库才能真正让人用得舒心。
