Rolldown 中的 Barrel Module从概念到 Lazy Barrel 优化实战【免费下载链接】rolldownFast Rust bundler for JavaScript/TypeScript with Rollup-compatible API.项目地址: https://gitcode.com/GitHub_Trending/ro/rolldownBarrel Module桶模块是 JavaScript 生态中常见的一种模块组织模式它通过集中转发导出为包或目录提供统一的公共 API。本文围绕 Rolldown 官方术语表对 barrel module 的定义展开完整覆盖其写法、优缺点并结合 lazy barrel 优化 与 Rolldown 模块加载器源码 深入讲解 Rolldown 如何规避传统打包器在此场景下的性能陷阱帮助你掌握组件库等大型代码库的构建提速方案。什么是 Barrel ModuleRolldown 官方术语表对 barrel module 的定义是一个从其他模块重新导出功能的模块通常用于为某个包或目录创建一个更干净的公共 API。典型的 barrel module 长这样// components/index.js (barrel module) export { Button } from ./Button; export { Card } from ./Card; export { Modal } from ./Modal; export { Tabs } from ./Tabs; // ... 还有几十个组件这样的组织方式让使用方可以从单一入口导入import { Button, Card } from ./components;这种模式在开源生态中极为常见例如组件库的index.js、工具库的utils/index.js等。它带来的好处很直接调用方不需要知道内部文件如何组织只需要面向一个稳定的入口同时库作者可以自由重构内部文件结构而不破坏对外 API。为什么 Barrel Module 会带来性能问题定义中特别强调了一个关键痛点barrel module 会导致性能问题因为打包器传统上需要编译所有被重新导出的模块即使其中只有一小部分被真正使用。原因在于barrel 文件的导出语句如export { Button } from ./Button本质上是模块依赖关系打包器在解析依赖图时无法轻易跳过这些模块。以 Ant Design 这类大量使用 barrel 的组件库为例当你只import { Button } from antd时传统流程仍然可能把数千个模块全部拉入编译管线而其中绝大多数模块的产物最终会被摇树删除——编译它们是纯粹的浪费。这个问题的严重程度可以用 Rolldown 官方 lazy barrel 文档 中的实测数据直观感受环境为仅导入Button的 antd 场景指标未启用 lazy barrel启用 lazy barrel编译模块数2986250构建耗时macOS~65ms~28ms构建耗时Windows~210ms~50ms启用优化后Rolldown 将编译模块数减少了约92%构建速度提升2-4 倍。Rolldown 的解法Lazy Barrel Optimization针对上述问题Rolldown 提供了 lazy barrel 优化在无副作用的 barrel module上跳过未被使用的重新导出模块的编译从而显著提升包含大量 barrel 的大型代码库的构建性能。工作原理启用后Rolldown 会分析哪些导出被真正使用只编译这些模块其余未使用的重新导出模块被跳过。以最简单的场景为例// barrel/index.js export { a } from ./a; export { b } from ./b; // main.js import { a } from ./barrel; console.log(a);在 lazy barrel 优化下barrel/index.js被加载并分析由于只导入了a只有a.js被编译b.js因为未被使用而不会被编译。源码级实现依据这一逻辑在 Rolldown 的模块加载器中真实存在。在 module_task.rs 中当实验性配置is_lazy_barrel_enabled()开启时会调用try_extract_lazy_barrel_info(ecma_view, raw_import_records)提取 barrel 信息据此决定后续加载哪些模块// Build lazy barrel info if the experimental flag is enabled let barrel_info if self.flat_options.is_lazy_barrel_enabled() { try_extract_lazy_barrel_info(ecma_view, raw_import_records) } else { None };相关的懒加载信息提取与利用还分布在 module_loader.rs、prepare_build_context.rs 以及 impl_bundler_testing.rs 中共同构成完整的 lazy barrel 实现链路。支持哪些导出模式lazy barrel 优化适用于多种导出写法Rolldown 官方文档按类别给出了完整清单星号重导出Star re-exportsexport * from ./components;具名重导出Named re-exportsexport { Component } from ./Component; export { helper as utils } from ./helper; export { default as Button } from ./Button; export { Button as default } from ./Button;命名空间重导出Namespace re-exportsexport * as ns from ./module;先导入再导出Import-then-export// 等价于 export { a } from ./a import { a } from ./a; export { a }; // 等价于 export { a as default } from ./a import { a } from ./a; export { a as default }; // 等价于 export * as ns from ./module import * as ns from ./module; export { ns }; // 等价于 export { default as b } from ./b import b from ./b; export { b };混合导出Mixed exportsexport { a } from ./a; export * as ns from ./b; export * from ./others; export * from ./more;在混合场景下Rolldown 的查找策略是当在具名导出中找到导入项时不再搜索星号导出避免不必要的模块加载如果具名导出中找不到则会加载所有星号重导出以解析该导入且如果这些星号导出的模块本身也是 barrel则只会按具体导入说明符从它们中加载对应项。关键语义Re-export 与 Own export 的区别export { Button as default } from ./Button.js与import { Button } from ./Button.js; export default Button并不等价这一点直接决定优化能否生效前者导出的是Button.js中同一个变量的引用两者始终同步后者export default ...会创建一个新变量导出值与Button.js内的值不同步。官方示例可以验证这种差异// main.js import { Button, increment } from ./Button.js; import ExportDefaultButton, { ReExportedButton } from ./re-exporter.js; console.log(Button); // 1 console.log(ReExportedButton); // 1 console.log(ExportDefaultButton); // 1 increment(); console.log(Button); // 2 console.log(ReExportedButton); // 2 console.log(ExportDefaultButton); // 1// re-exporter.js import { Button } from ./Button.js; export default Button; export { Button as ReExportedButton } from ./Button.js;// Button.js export let Button 1; export const increment () { Button; };正因如此export default ...被视为 barrel 自身的导出own export可能阻止优化详见下文Own exports一节。高级场景的行为lazy barrel 在以下复杂场景中也有明确定义的行为自重导出Self re-export支持 barrel 从自身重新导出的情况。// barrel/index.js export { a } from ./a; export { a as b } from ./index; // self re-export循环导出Circular exports正确支持 barrel 之间的循环引用。// barrel-a/index.js export { a } from ./a; export * from ../barrel-b; // barrel-b/index.js export { b } from ./b; export { a as c } from ../barrel-a; // circular reference动态导入入口Dynamic import entry当 barrel 被动态导入时它会成为入口点其所有导出都必须可用// barrel/a.js export const a a; import(./index.js); // 使 barrel 成为入口点 // barrel/index.js export { a } from ./a; export { b } from ./b; // b.js 会被加载不过如果b.js本身也是 barrel其未使用的导出仍会被优化。未使用的导入说明符Unused import specifiers默认情况下即使导入的说明符未被使用其对应模块仍会被加载// barrel/index.js export { a } from ./a; export { b } from ./b; // main.js import { a } from ./barrel; // 即使 a 从未被使用a.js 仍会被加载Own exports非纯重导出 barrel当 barrel 有自己的导出不仅是重导出时只要任何 own export 被使用其所有导入记录都必须被加载// barrel/index.js import ./a; import { b } from ./b; import { e } from ./e; export { c } from ./c; export { d } from ./d; export { e }; console.log(b); export const index index; // own export export default b; // default 也是 own export // main.js import { index, c } from ./barrel; // 或 import b, { c } from ./barrel;当主模块导入index时a.js、b.js、c.js、d.js、e.js全部会被加载原因各不相同import ./a——a.js以空说明符集加载import { b } from ./b——b.js以b请求加载barrel 自身代码使用import { e } from ./e; export { e }先导入再导出——e.js以e请求加载因为 Rolldown 无法静态判断 barrel 自身代码是否也使用eexport { c } from ./c专用重导出——c.js以c请求加载主模块导入了cexport { d } from ./d专用重导出——d.js以空说明符集加载类似import ./d因为主模块未导入d。这里需要注意专用重导出记录export { .. } from ..、export * as ns from ..与先导入再导出模式产生的共享导入记录的区别当 barrel 的 own export 被主模块使用、barrel 必须执行时专用重导出记录可以在其绑定未被请求时回退为空说明符集而共享导入记录始终保持完整说明符因为其绑定可能被 barrel 自身代码引用。根本原因在于moduleSideEffects只能在 transform 钩子之后确定而 lazy barrel 的决策发生在 load 阶段。当 barrel 因 own export 被使用而必须执行时其所有导入都必须加载以保证行为正确。如果这些被加载的模块a.js、b.js等本身也是 barrellazy barrel 优化仍会根据是否有请求的说明符递归应用于它们。配置与启用方式lazy barrel 优化目前默认关闭需要在 Rolldown 配置中显式开启// rolldown.config.js export default { experimental: { lazyBarrel: true, }, };注意官方文档提示该选项计划在未来移除。如果需要退出该优化请在 GitHub 上提交 issue 描述你的使用场景以便团队在移除前处理。前置要求标记为无副作用要让 lazy barrel 优化生效barrel 模块必须被显式标记为无副作用side-effect-free有三种途径1. package.json 声明添加sideEffects: false。2. 插件钩子返回在resolveId、load或transform钩子中返回moduleSideEffects: false// rolldown.config.js export default { plugins: [ { name: mark-barrel-side-effect-free, transform(code, id) { if (id.includes(/barrel/)) { return { moduleSideEffects: false }; } }, }, ], };3. treeshake.moduleSideEffects 配置// rolldown.config.js export default { treeshake: { moduleSideEffects: [ // 用正则标记 barrel 模块为无副作用 { test: /\/barrel\//, sideEffects: false }, // 或标记特定路径 { test: /\/components\/index\.js$/, sideEffects: false }, ], }, };也可以使用函数实现更复杂的逻辑// rolldown.config.js export default { treeshake: { moduleSideEffects: (id) { // 将所有 index.js 标记为无副作用 if (id.endsWith(/index.js)) return false; return true; }, }, };大型 Barrel 模块与 LARGE_BARREL_MODULES 建议lazy barrel 会跳过未使用的重导出的加载、解析与转换但resolve解析步骤仍然会对每个导入记录执行。解析器会对每条导入记录调用resolveId插件钩子因此一个包含数千条重导出的 barrel 即使只有少数被使用其 resolve 开销仍可能主导构建时间。典型例子是mui/icons-material/esm/index.js它包含超过 10,000 条重导出。加载该文件时Rolldown 仍会对每一条发起 resolve尽管 lazy barrel 保证了之后只有被请求的图标才会被加载和转换。当experimental.lazyBarrel启用且 barrel 的重导出超过5000条时Rolldown 会输出一条 info 级别的建议错误码为LARGE_BARREL_MODULESadvice[LARGE_BARREL_MODULES]: node_modules/mui/icons-material/esm/index.js has 10611 re-exports. Eagerly resolving every entry can significantly slow down the build. Consider using rolldown/plugin-transform-imports to rewrite imports at the source level so the barrel file is never loaded.这一阈值逻辑在源码中有明确实现module_task.rs 中定义了LARGE_BARREL_IMPORT_THRESHOLD: usize 5000当导入记录数超过阈值时调用BuildDiagnostic::large_barrel_modules(id, import_record_count)生成诊断事件并通过on_log以 Info 级别输出同时受checks选项中的LargeBarrelModules开关控制。要关闭该建议可将checks.largeBarrelModules设为false或在 CLI 上传入--no-checks.large-barrel-modules。为什么用插件而不是内置行为官方文档解释在 Rolldown 内部推迟 resolve 步骤会改变moduleParsed的触发时机以及ModuleInfo的填充时机这是对 Rollup 兼容插件语义的可见偏离。为了在 Rolldown 1.0 发布前保持插件契约稳定官方选择在源码层解决这类问题。除了图标包这类极端情况外典型 barrel几十到几百条重导出的 resolve 开销可以忽略不计。rolldown/plugin-transform-imports通过源码级重写导入来规避 resolve 成本使 barrel 文件根本不被加载// 之前 import { Home, Search } from mui/icons-material; // 之后由插件重写 import Home from mui/icons-material/esm/Home; import Search from mui/icons-material/esm/Search;适用场景与已知限制lazy barrel 优化在以下情况下收益最大代码库包含大量 barrel 模块组件库中很常见barrel 重导出了很多模块但使用者通常只用到其中少数几个。同时需要了解其已知限制带副作用的 barrel 模块无法优化无法匹配的具名导入需要加载所有星号重导出以完成解析入口文件、import * as ns、import(..)、require(..)等会导致 barrel 加载其全部导出当 barrel 拥有自己的导出不仅是重导出时使用任何 own export 都会导致其所有导入记录被加载。总结barrel module 是组件库和工具库中广泛使用的 API 组织模式但其集中重导出的特性天然带来全量编译的性能负担。Rolldown 通过 lazy barrel 优化——在模块加载阶段分析实际使用的导出、跳过未使用模块的编译——将组件库构建从编译数千模块降为只编译真正需要的模块实测可将编译模块数减少约 92%、构建提速 2-4 倍。理解其支持的导出模式、own export 的语义边界与moduleSideEffects标记要求是在真实项目中安全启用该优化的前提。【免费下载链接】rolldownFast Rust bundler for JavaScript/TypeScript with Rollup-compatible API.项目地址: https://gitcode.com/GitHub_Trending/ro/rolldown创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Rolldown 中的 Barrel Module：从概念到 Lazy Barrel 优化实战
Rolldown 中的 Barrel Module从概念到 Lazy Barrel 优化实战【免费下载链接】rolldownFast Rust bundler for JavaScript/TypeScript with Rollup-compatible API.项目地址: https://gitcode.com/GitHub_Trending/ro/rolldownBarrel Module桶模块是 JavaScript 生态中常见的一种模块组织模式它通过集中转发导出为包或目录提供统一的公共 API。本文围绕 Rolldown 官方术语表对 barrel module 的定义展开完整覆盖其写法、优缺点并结合 lazy barrel 优化 与 Rolldown 模块加载器源码 深入讲解 Rolldown 如何规避传统打包器在此场景下的性能陷阱帮助你掌握组件库等大型代码库的构建提速方案。什么是 Barrel ModuleRolldown 官方术语表对 barrel module 的定义是一个从其他模块重新导出功能的模块通常用于为某个包或目录创建一个更干净的公共 API。典型的 barrel module 长这样// components/index.js (barrel module) export { Button } from ./Button; export { Card } from ./Card; export { Modal } from ./Modal; export { Tabs } from ./Tabs; // ... 还有几十个组件这样的组织方式让使用方可以从单一入口导入import { Button, Card } from ./components;这种模式在开源生态中极为常见例如组件库的index.js、工具库的utils/index.js等。它带来的好处很直接调用方不需要知道内部文件如何组织只需要面向一个稳定的入口同时库作者可以自由重构内部文件结构而不破坏对外 API。为什么 Barrel Module 会带来性能问题定义中特别强调了一个关键痛点barrel module 会导致性能问题因为打包器传统上需要编译所有被重新导出的模块即使其中只有一小部分被真正使用。原因在于barrel 文件的导出语句如export { Button } from ./Button本质上是模块依赖关系打包器在解析依赖图时无法轻易跳过这些模块。以 Ant Design 这类大量使用 barrel 的组件库为例当你只import { Button } from antd时传统流程仍然可能把数千个模块全部拉入编译管线而其中绝大多数模块的产物最终会被摇树删除——编译它们是纯粹的浪费。这个问题的严重程度可以用 Rolldown 官方 lazy barrel 文档 中的实测数据直观感受环境为仅导入Button的 antd 场景指标未启用 lazy barrel启用 lazy barrel编译模块数2986250构建耗时macOS~65ms~28ms构建耗时Windows~210ms~50ms启用优化后Rolldown 将编译模块数减少了约92%构建速度提升2-4 倍。Rolldown 的解法Lazy Barrel Optimization针对上述问题Rolldown 提供了 lazy barrel 优化在无副作用的 barrel module上跳过未被使用的重新导出模块的编译从而显著提升包含大量 barrel 的大型代码库的构建性能。工作原理启用后Rolldown 会分析哪些导出被真正使用只编译这些模块其余未使用的重新导出模块被跳过。以最简单的场景为例// barrel/index.js export { a } from ./a; export { b } from ./b; // main.js import { a } from ./barrel; console.log(a);在 lazy barrel 优化下barrel/index.js被加载并分析由于只导入了a只有a.js被编译b.js因为未被使用而不会被编译。源码级实现依据这一逻辑在 Rolldown 的模块加载器中真实存在。在 module_task.rs 中当实验性配置is_lazy_barrel_enabled()开启时会调用try_extract_lazy_barrel_info(ecma_view, raw_import_records)提取 barrel 信息据此决定后续加载哪些模块// Build lazy barrel info if the experimental flag is enabled let barrel_info if self.flat_options.is_lazy_barrel_enabled() { try_extract_lazy_barrel_info(ecma_view, raw_import_records) } else { None };相关的懒加载信息提取与利用还分布在 module_loader.rs、prepare_build_context.rs 以及 impl_bundler_testing.rs 中共同构成完整的 lazy barrel 实现链路。支持哪些导出模式lazy barrel 优化适用于多种导出写法Rolldown 官方文档按类别给出了完整清单星号重导出Star re-exportsexport * from ./components;具名重导出Named re-exportsexport { Component } from ./Component; export { helper as utils } from ./helper; export { default as Button } from ./Button; export { Button as default } from ./Button;命名空间重导出Namespace re-exportsexport * as ns from ./module;先导入再导出Import-then-export// 等价于 export { a } from ./a import { a } from ./a; export { a }; // 等价于 export { a as default } from ./a import { a } from ./a; export { a as default }; // 等价于 export * as ns from ./module import * as ns from ./module; export { ns }; // 等价于 export { default as b } from ./b import b from ./b; export { b };混合导出Mixed exportsexport { a } from ./a; export * as ns from ./b; export * from ./others; export * from ./more;在混合场景下Rolldown 的查找策略是当在具名导出中找到导入项时不再搜索星号导出避免不必要的模块加载如果具名导出中找不到则会加载所有星号重导出以解析该导入且如果这些星号导出的模块本身也是 barrel则只会按具体导入说明符从它们中加载对应项。关键语义Re-export 与 Own export 的区别export { Button as default } from ./Button.js与import { Button } from ./Button.js; export default Button并不等价这一点直接决定优化能否生效前者导出的是Button.js中同一个变量的引用两者始终同步后者export default ...会创建一个新变量导出值与Button.js内的值不同步。官方示例可以验证这种差异// main.js import { Button, increment } from ./Button.js; import ExportDefaultButton, { ReExportedButton } from ./re-exporter.js; console.log(Button); // 1 console.log(ReExportedButton); // 1 console.log(ExportDefaultButton); // 1 increment(); console.log(Button); // 2 console.log(ReExportedButton); // 2 console.log(ExportDefaultButton); // 1// re-exporter.js import { Button } from ./Button.js; export default Button; export { Button as ReExportedButton } from ./Button.js;// Button.js export let Button 1; export const increment () { Button; };正因如此export default ...被视为 barrel 自身的导出own export可能阻止优化详见下文Own exports一节。高级场景的行为lazy barrel 在以下复杂场景中也有明确定义的行为自重导出Self re-export支持 barrel 从自身重新导出的情况。// barrel/index.js export { a } from ./a; export { a as b } from ./index; // self re-export循环导出Circular exports正确支持 barrel 之间的循环引用。// barrel-a/index.js export { a } from ./a; export * from ../barrel-b; // barrel-b/index.js export { b } from ./b; export { a as c } from ../barrel-a; // circular reference动态导入入口Dynamic import entry当 barrel 被动态导入时它会成为入口点其所有导出都必须可用// barrel/a.js export const a a; import(./index.js); // 使 barrel 成为入口点 // barrel/index.js export { a } from ./a; export { b } from ./b; // b.js 会被加载不过如果b.js本身也是 barrel其未使用的导出仍会被优化。未使用的导入说明符Unused import specifiers默认情况下即使导入的说明符未被使用其对应模块仍会被加载// barrel/index.js export { a } from ./a; export { b } from ./b; // main.js import { a } from ./barrel; // 即使 a 从未被使用a.js 仍会被加载Own exports非纯重导出 barrel当 barrel 有自己的导出不仅是重导出时只要任何 own export 被使用其所有导入记录都必须被加载// barrel/index.js import ./a; import { b } from ./b; import { e } from ./e; export { c } from ./c; export { d } from ./d; export { e }; console.log(b); export const index index; // own export export default b; // default 也是 own export // main.js import { index, c } from ./barrel; // 或 import b, { c } from ./barrel;当主模块导入index时a.js、b.js、c.js、d.js、e.js全部会被加载原因各不相同import ./a——a.js以空说明符集加载import { b } from ./b——b.js以b请求加载barrel 自身代码使用import { e } from ./e; export { e }先导入再导出——e.js以e请求加载因为 Rolldown 无法静态判断 barrel 自身代码是否也使用eexport { c } from ./c专用重导出——c.js以c请求加载主模块导入了cexport { d } from ./d专用重导出——d.js以空说明符集加载类似import ./d因为主模块未导入d。这里需要注意专用重导出记录export { .. } from ..、export * as ns from ..与先导入再导出模式产生的共享导入记录的区别当 barrel 的 own export 被主模块使用、barrel 必须执行时专用重导出记录可以在其绑定未被请求时回退为空说明符集而共享导入记录始终保持完整说明符因为其绑定可能被 barrel 自身代码引用。根本原因在于moduleSideEffects只能在 transform 钩子之后确定而 lazy barrel 的决策发生在 load 阶段。当 barrel 因 own export 被使用而必须执行时其所有导入都必须加载以保证行为正确。如果这些被加载的模块a.js、b.js等本身也是 barrellazy barrel 优化仍会根据是否有请求的说明符递归应用于它们。配置与启用方式lazy barrel 优化目前默认关闭需要在 Rolldown 配置中显式开启// rolldown.config.js export default { experimental: { lazyBarrel: true, }, };注意官方文档提示该选项计划在未来移除。如果需要退出该优化请在 GitHub 上提交 issue 描述你的使用场景以便团队在移除前处理。前置要求标记为无副作用要让 lazy barrel 优化生效barrel 模块必须被显式标记为无副作用side-effect-free有三种途径1. package.json 声明添加sideEffects: false。2. 插件钩子返回在resolveId、load或transform钩子中返回moduleSideEffects: false// rolldown.config.js export default { plugins: [ { name: mark-barrel-side-effect-free, transform(code, id) { if (id.includes(/barrel/)) { return { moduleSideEffects: false }; } }, }, ], };3. treeshake.moduleSideEffects 配置// rolldown.config.js export default { treeshake: { moduleSideEffects: [ // 用正则标记 barrel 模块为无副作用 { test: /\/barrel\//, sideEffects: false }, // 或标记特定路径 { test: /\/components\/index\.js$/, sideEffects: false }, ], }, };也可以使用函数实现更复杂的逻辑// rolldown.config.js export default { treeshake: { moduleSideEffects: (id) { // 将所有 index.js 标记为无副作用 if (id.endsWith(/index.js)) return false; return true; }, }, };大型 Barrel 模块与 LARGE_BARREL_MODULES 建议lazy barrel 会跳过未使用的重导出的加载、解析与转换但resolve解析步骤仍然会对每个导入记录执行。解析器会对每条导入记录调用resolveId插件钩子因此一个包含数千条重导出的 barrel 即使只有少数被使用其 resolve 开销仍可能主导构建时间。典型例子是mui/icons-material/esm/index.js它包含超过 10,000 条重导出。加载该文件时Rolldown 仍会对每一条发起 resolve尽管 lazy barrel 保证了之后只有被请求的图标才会被加载和转换。当experimental.lazyBarrel启用且 barrel 的重导出超过5000条时Rolldown 会输出一条 info 级别的建议错误码为LARGE_BARREL_MODULESadvice[LARGE_BARREL_MODULES]: node_modules/mui/icons-material/esm/index.js has 10611 re-exports. Eagerly resolving every entry can significantly slow down the build. Consider using rolldown/plugin-transform-imports to rewrite imports at the source level so the barrel file is never loaded.这一阈值逻辑在源码中有明确实现module_task.rs 中定义了LARGE_BARREL_IMPORT_THRESHOLD: usize 5000当导入记录数超过阈值时调用BuildDiagnostic::large_barrel_modules(id, import_record_count)生成诊断事件并通过on_log以 Info 级别输出同时受checks选项中的LargeBarrelModules开关控制。要关闭该建议可将checks.largeBarrelModules设为false或在 CLI 上传入--no-checks.large-barrel-modules。为什么用插件而不是内置行为官方文档解释在 Rolldown 内部推迟 resolve 步骤会改变moduleParsed的触发时机以及ModuleInfo的填充时机这是对 Rollup 兼容插件语义的可见偏离。为了在 Rolldown 1.0 发布前保持插件契约稳定官方选择在源码层解决这类问题。除了图标包这类极端情况外典型 barrel几十到几百条重导出的 resolve 开销可以忽略不计。rolldown/plugin-transform-imports通过源码级重写导入来规避 resolve 成本使 barrel 文件根本不被加载// 之前 import { Home, Search } from mui/icons-material; // 之后由插件重写 import Home from mui/icons-material/esm/Home; import Search from mui/icons-material/esm/Search;适用场景与已知限制lazy barrel 优化在以下情况下收益最大代码库包含大量 barrel 模块组件库中很常见barrel 重导出了很多模块但使用者通常只用到其中少数几个。同时需要了解其已知限制带副作用的 barrel 模块无法优化无法匹配的具名导入需要加载所有星号重导出以完成解析入口文件、import * as ns、import(..)、require(..)等会导致 barrel 加载其全部导出当 barrel 拥有自己的导出不仅是重导出时使用任何 own export 都会导致其所有导入记录被加载。总结barrel module 是组件库和工具库中广泛使用的 API 组织模式但其集中重导出的特性天然带来全量编译的性能负担。Rolldown 通过 lazy barrel 优化——在模块加载阶段分析实际使用的导出、跳过未使用模块的编译——将组件库构建从编译数千模块降为只编译真正需要的模块实测可将编译模块数减少约 92%、构建提速 2-4 倍。理解其支持的导出模式、own export 的语义边界与moduleSideEffects标记要求是在真实项目中安全启用该优化的前提。【免费下载链接】rolldownFast Rust bundler for JavaScript/TypeScript with Rollup-compatible API.项目地址: https://gitcode.com/GitHub_Trending/ro/rolldown创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考