Rollup output深度解析
## 关于Rollup Output，一些你可能没细想的细节
最近在项目里又用到了Rollup，打包的时候盯着那个output配置看了半天，突然觉得这东西虽然天天用，但里面有些门道还真值得拿出来聊聊。不是那种照搬文档的说明，而是实际用久了之后的一些体会。
它到底是什么？
简单来说，Rollup的output配置，就是你告诉Rollup：“我这一堆源代码，请你按照这个规矩，打包成最终我能用的文件。” 它不是一个独立的工具，而是Rollup打包流程的最后一个环节——产出环节的规则说明书。
你可以把它想象成一家糕点厂的生产线。前端代码的模块、组件、库，就像是面粉、糖、黄油这些原料。Rollup的核心工作是把这些原料和面、搅拌、加工。而output配置，就是最后决定把这些面团做成什么形状的模具：是做成一大条吐司（一个bundle文件），还是切成独立的小饼干（多个chunk），或者做成无糖版本（不同的格式），都是它来定。
它能做什么？不止是“输出一个文件”
很多人觉得output就是配个文件名和路径，那就太小看它了。它的能力核心在于对“打包结果”的精细控制。
首先，最基础的是决定输出格式。比如format: 'es'，产出的是现代的ES模块，浏览器通过<script type="module">引用，或者给其他ESM环境用。format: 'cjs'产出CommonJS模块，主要给Node.js环境。format: 'umd'或者'iife'，则是为了兼容那些不支持模块化的老式浏览器环境，直接把所有东西打包成一个全局变量。选哪种格式，不光是技术选型，更是决定了你的代码将在什么样的生态里运行。
其次，它管理着代码的分割与合并。通过file属性可以输出单个文件，但更多时候，尤其是做应用，我们会用到dir属性配合代码分割。Rollup能自动识别动态导入（import()），然后把动态加载的模块拆分成独立的chunk文件，实现按需加载。这比手动去分割要智能和可靠得多。
还有一个容易被忽略但极其重要的点是对产出的修饰。比如sourcemap选项，决定是否生成以及生成什么类型的源码映射，这对调试至关重要。banner和footer可以在文件头尾添加注释信息。globals和external配合，可以处理外部依赖，告诉Rollup：“遇到lodash别打包，它已经在全局了，用_这个变量代替。” 这直接关系到打包体积和运行时的正确性。
怎么用？从一个实际场景说起
看文档配置项列表容易眼花，不如从一个典型场景入手。假设正在构建一个工具库，它既希望被现代项目通过import引用，也需要能放在浏览器里直接通过<script>标签使用。
配置可能就会分成两个输出目标：
// rollup.config.jsexportdefault{input:'src/index.js',output:[{file:'dist/my-lib.esm.js',format:'es',sourcemap:true},{file:'dist/my-lib.umd.js',format:'umd',name:'MyLib',// UMD格式需要一个全局变量名globals:{'lodash':'_'// 假设我们外部化了lodash},sourcemap:true}],external:['lodash']// 声明lodash为外部依赖，不打包};这里可以看到，一个input可以对应多个output。这是Rollup一个很强大的特性，能一次打包，多格式输出。name属性只在UMD或IIFE格式中需要，因为它对应了挂载在全局对象（如window）上的变量名。
对于大型应用，配置的重心会转向代码分割：
output:{dir:'dist/application',format:'es',chunkFileNames:'[name]-[hash].js',// 定义分割出的chunk文件名格式entryFileNames:'[name]-[entry].js',// 定义入口chunk文件名格式sourcemap:true}用dir代替file，Rollup就会自动把入口和动态导入的chunk文件生成到指定目录。[hash]占位符能很好地进行缓存控制。
一些值得琢磨的实践细节
关于最佳实践，文档和社区讨论已经很多，这里提几个不那么显眼但能提升体验的点。
关于文件命名：使用[hash]时，可以考虑用[hash:8]只取前8位，通常已经足够唯一，且文件名更短。清晰的文件名策略（比如用entryFileNames和chunkFileNames区分）能让构建结果更易于排查。
关于外部依赖：external的声明要尽可能精确。直接写['lodash']当然可以，但更稳妥的做法是用一个函数来判断，比如id => /^lodash/.test(id)，这样可以避免意外打包了lodash的某个子路径模块（如lodash/get）。处理Node.js内置模块时，external更是必不可少。
关于动态导入：Rollup对原生的import()语法支持得非常好。但如果你用了类似require.ensure这样的Webpack特有语法，那就需要插件先转换成标准语法。保持代码符合ES规范，能让打包过程更顺畅。
关于环境变量：在output配置里注入环境变量要小心。通常更推荐在打包阶段通过插件（如@rollup/plugin-replace）来处理，这样能更早地在代码中被优化，比如移除死代码。
关于源码映射：开发环境用sourcemap: true（默认是inline，信息包含在js文件内）没问题。生产环境可以考虑sourcemap: 'hidden'，生成独立的.map文件但不暴露给浏览器，仅供错误监控平台等内部工具使用，兼顾了安全性和可调试性。
和Webpack、Vite的Output对比
最后聊聊对比，这有助于理解为什么选它。
和Webpack相比，Rollup的output配置在概念上更“干净”和“专注”。Webpack的output配置项极其庞大，因为它承载了更多非标准的、历史遗留的打包概念（比如各种libraryTarget）。Rollup的output更贴近ES模块标准本身，它的多格式输出更像是将同一份标准模块化的代码，“适配”到不同的运行时环境。这种设计哲学使得Rollup的产出物通常更小巧、更可预测。Webpack在应对极其复杂应用场景（如热更新、魔法注释、各种devServer）时功能更全，但Rollup在产出库文件时的纯粹和高效是其显著优势。
和Vite相比，这有点像是降维对比。Vite在开发环境下根本不打包，直接使用ESM，因此没有传统意义上的output阶段。在生产构建时，Vite底层直接使用了Rollup。所以，可以理解为Vite继承了Rollup优秀的output能力，并在此基础上添加了更多针对现代前端应用的预设和优化（如更好的CSS代码分割、异步chunk加载优化等）。如果你在用Vite，那么你其实已经在享受Rollup output的好处了，只是界面更友好，预设更合理。
总的来说，Rollup的output配置体现了一种“约定大于配置”与“强大配置能力”的平衡。它没有试图满足所有稀奇古怪的需求，而是把ES模块体系下的打包产出这件事，做得足够深入和优雅。理解它，对于构建高质量的前端库，或者理解现代构建工具的工作机制，都很有帮助。