webpack入口配置全解析：从单页到多页的构建演进路径-北京尧图网络

聊webpack配置很多人第一反应是去逐条背module.rules和plugins可真正决定打包流程走向的往往是那个看起来不起眼的entry字段。它就像一张依赖地图的起始坐标webpack拿到它顺着import递归展开整棵依赖树最终才能生成一个个chunk和bundle。entry怎么写不仅决定了构建入口在哪更决定了产物怎么切分、公共代码能不能抽干净、多页面能不能各归各位。这个字段看似简单但实际项目里关于它的误解和踩坑比任何一个loader都多。这篇文章从一个长期和webpack打交道的人的视角把entry彻底拆开聊透。你会看到它的四种写法分别适用什么场景多入口之间怎么配合splitChunks玩出干净的打包结果还会给出一套从单页到多页项目的完整配置演进路线。无论你是刚开始学webpack的新手还是已经负责中大型项目构建的老手里面都有值得直接抄走的配置和排坑经验。1. entry的本质打包流程的“起点”与“地图”1.1 从起点到依赖图webpack到底在入口处做了什么entry的核心作用不是“指定一个文件被丢进打包”这么简单。webpack的执行引擎拿到entry后会做三件事定位入口模块、创建模块对象、从该模块开始解析依赖。解析依赖的过程是递归的入口文件里import了什么就拉进来被拉进来的文件里又import了别的文件继续拉。最终所有被触达的模块形成一张完整的模块依赖图这张图才是打包的真正输入。这里有一个容易忽略的点模块依赖图的形状完全取决于entry的起点选择。同一个项目入口指向src/index.js和指向src/main.js生成的依赖图可能天差地别。比如入口文件里没有引用polyfill那么polyfill就不会进入当前entry对应的bundle哪怕它在另一个入口里被引用了。这种“以entry为中心”的辐射逻辑决定了你在写入口时就必须考虑到整个项目的模块组织方式。从实现细节来看webpack对每个入口会创建一个compilation中的入口对象包含name、chunkGroup等信息。这个chunkGroup是后续所有chunk归类的依据多入口之间的公共模块抽取、异步模块拆分本质上都是在chunkGroup的维度上做调度。所以entry的命名不只是一个字符串它是整张依赖图的“根命名空间”。1.2 entry与module、chunk、bundle的关系图谱很多人会把module、chunk、bundle这三个概念混在一起。理清它们entry的作用就清晰了。module项目里的源文件一个文件就是一个modulewebpack能识别的模块类型包括js、jsx、ts、css、图片等。chunkwebpack在构建过程中生成的分组一个chunk包含一组相互引用关系的module。chunk是构建过程中的中间产物不直接输出。bundlechunk经过文件输出处理压缩、加hash后生成的真实静态文件也就是最终部署到服务器上的文件。entry和这三者的关系可以这样概括入口指向一个或多个module这些module被归入一个或多个chunkchunk经处理后输出为bundle。一个单入口项目通常所有同步模块都会归入一个chunk最终输出为一个bundle。而多入口项目每个入口都是一个独立的chunkGroup每个入口最终可能会输出自己的bundle同时公共模块也可能被抽成一个公共bundle。用一个生活化类比模块是仓库里的各种货物chunk是仓库工作人员临时分好的打包批次bundle是已经封箱贴上快递单的包裹。entry就是快递单上填写的发货地址——你填了几个发货地址仓库就按几个方向去配货封装但不同方向的订单里如果都有同一件货物仓库可能额外开一个“公共包裹”统一发送。1.3 为什么说entry选型决定项目架构走向技术选型层面entry的形态基本宣告了项目的前端架构形态。如果你用的是单个字符串入口那这是一个经典的单页应用SPA架构——所有路由、状态管理、业务模块都被收敛进同一棵依赖树最终打包出一个主bundle。随着业务膨胀主bundle会越来越大你会开始考虑代码分割于是把动态路由的import()引进来这时webpack会自动生成异步chunk但这些异步chunk的“上游归属”仍然绑在唯一的入口上。如果你用的是对象多入口那项目大概率是传统的多页应用形MPA——多个页面各自走独立的依赖树页面之间通过抽取公共chunk来优化体积。这种配置下每个页面都可以单独部署、单独更新非常适合偏静态的站点、后台系统或者强SEO需求的项目。如果你用了函数式动态入口那就说明你的入口不是固定的而是要结合文件系统、环境变量或者构建时的目录扫描来动态决定的。这在一些脚手架工具、低代码平台、或者需要按目录自动生成多页面的项目里非常常见。因此entry不该是随手一写的配置而是项目架构的“第一决策点”。后面所有的loader、plugin、splitChunks策略都要围绕着entry的选择来展开。2. entry的四种配置形态以及各自背后的场景密码2.1 字符串入口最基础的单页应用起点字符串入口是最常见、最基础的写法module.exports { entry: ./src/index.js, };注意这里传入的是一个相对路径字符串。webpack会基于context默认是process.cwd()来解析这个路径。更严谨的写法可以用绝对路径避免因为终端启动目录不一致导致解析错误const path require(path); module.exports { context: path.resolve(__dirname, .), entry: path.resolve(__dirname, src/index.js), };单字符串入口会生成一个默认名为main的chunk最终输出对应的bundle文件名由output.filename决定。如果你只写filename: bundle.js那就是固定名如果你写成filename: [name].[contenthash].js其中[name]就会被替换为main。这个写法适合纯SPA、项目结构清晰、不需要按页面拆分构建产物的场景。不过要注意字符串入口不代表你的最终代码只能有一个文件。只要在代码里使用动态import()webpack就会自动拆分出额外的异步chunk。那些异步chunk也归属于这个入口只是它们不会成为一个独立HTML入口而是被主入口在运行时按需加载。2.2 数组入口别把它当成多入口它是一组预加载依赖数组入口的写法是module.exports { entry: [./src/polyfill.js, ./src/index.js], };很多人第一次看到这个写法会误以为这是“多入口”。错了数组入口最终只生成一个bundle数组中的多个文件会被打包进同一个chunk里。它真正的作用是把入口依赖的多个模块“硬性”加入到入口chunk中并且按声明顺序排列。数组的第一个元素会最先被加载然后是后面的元素。这在实际中的典型用途是在需要保证某些代码先于业务代码执行的场景下比如必须优先引入polyfill、初始化埋点、设置全局环境变量等。你当然可以在index.js里第一行import ./polyfill但数组入口可以避免业务入口里“不自觉”的模块提升顺序问题同时让需求更显式、可读性更强。数组入口还有一个冷门用法配合output.library去开发一些库多入口文件共同组成一个UMD库的对外形态。不过这种情况很少见大多数时候我们只需要理解它是“单入口的增强版”。2.3 对象入口真正意义上的一对多打包控制对象入口是支持多页面、多bundle的基础module.exports { entry: { home: ./src/home.js, about: ./src/about.js, admin: ./src/admin.js, }, };每一个key就是一个入口名对应一个独立的chunkGroup。每个入口可以引用完全不同的依赖树但也可以引用公共模块。对象入口的价值在于你可以为每个入口独立配置输出、独立注入HTML并且通过splitChunks把多个入口共用的模块抽取到一个公共chunk里方便浏览器在页面间跳转时复用缓存。举个例子home页面和about页面都用了react和moment如果不抽取公共模块打包后的home.js和about.js里会各自包含一份react和moment的副本得白白浪费好几百KB。配置了splitChunks后公共部分会独立成vendors或commonchunkHTML中需要引入三个文件公共chunk home chunk about chunk才能让页面正常跑起来。对象入口的key名会直接成为[name]占位符的实际值也会成为HtmlWebpackPlugin中chunks参数的引用名。所以入口key的命名要语义化别写a、b这种毫无意义的短名否则后面查构建产物、定位问题时都是一场灾难。2.4 函数动态入口当入口需要“计算”时怎么玩函数入口是webpack 4.4.0版本支持的写法它接收一个函数返回值可以是字符串、数组或对象。函数形式最大的价值是让入口可以根据环境变量、构建上下文动态计算。比如按环境区分入口文件module.exports { entry: () { if (process.env.NODE_ENV development) { return { app: ./src/dev-entry.js, }; } return { app: ./src/prod-entry.js, }; }, };再比如自动扫描目录生成多页面的入口const fs require(fs); const path require(path); const pagesDir path.resolve(__dirname, src/pages); const entryMap {}; fs.readdirSync(pagesDir).forEach((dirName) { const entryPath path.join(pagesDir, dirName, index.js); if (fs.existsSync(entryPath)) { entryMap[dirName] entryPath; } }); module.exports { entry: entryMap, };函数入口还可以返回一个Promise允许你在扫描目录时做异步操作。这个特性为复杂的构建系统提供了解耦空间让插件和脚手架能更灵活地注入入口配置。不过要注意函数入口一般只影响“依赖图起点”的确定一旦函数执行完毕返回了具体的入口配置后续行为和静态配置完全一致。不要试图在函数里做过于耗时的工作比如大规模I/O否则每次构建的启动速度都会变慢。3. entry与chunk拆分那些“隐藏”的优化机会3.1 多入口条件下公共依赖的重复打包问题单入口项目不用太担心重复打包问题因为所有模块都汇集于一棵依赖树天然只有一份。一旦切换到多入口每个入口自己的依赖图里都可能包含react、lodash之类的公共库。如果不对公共部分做处理产物就重复了。更麻烦的是重复打包不只是体积变大还会破坏应用的状态共享。比如两个入口都引用了同一个第三方库的单例对象但每个bundle里各有一份独立的拷贝那它们之间的共享状态就完全割裂了。虽然多页面应用一般不共享内存状态但如果某两个入口在同一个页面中被同时引用这种割裂就会造成真实的功能异常。解决重复打包有两条路径一是用SplitChunksPlugin抽取公共chunk二是使用externals配置把公共库声明为外部依赖避免打进bundle。entry在这里的作用是定义抽取的“边界”。只有先有了多个entrysplitChunks才有分组的依据只有entry命名清晰splitChunks的cacheGroups规则才能准确地把想抽的内容抽出来。3.2 splitChunks配置与entry的配合要点先看一个典型的多入口配置module.exports { entry: { home: ./src/pages/home/index.js, about: ./src/pages/about/index.js, list: ./src/pages/list/index.js, }, optimization: { splitChunks: { chunks: all, cacheGroups: { vendors: { test: /[\\/]node_modules[\\/]/, name: vendors, priority: 10, }, common: { name: common, minChunks: 2, minSize: 0, priority: 5, }, }, }, }, };这里的核心逻辑是webpack会扫描所有entry的chunk找到它们之间共享的模块。chunks: all意味着无论模块是同步加载还是异步加载都会被纳入拆分范围。vendors组把来自node_modules的模块抽到vendors这个chunk中common组把被至少2个chunk引用的自有模块抽到common中。配合entry时要注意几个点cacheGroups里的name会在产物文件里成为实际文件名前缀和入口名没有必然关系但建议保持语义。如果在cacheGroups里不指定namewebpack会默认生成一个包含多个入口名的chunk名比如home~about这种命名在文件多了以后显得很乱。minChunks的数字指“被多少个chunk引用”。如果A和B两个入口都引用了同一个工具函数设置minChunks: 2就能抽出来但如果只有一个入口引用即使size很大也不满足条件不会抽取。minSize用来控制抽取的最小体积避免把很小的模块也抽出来。默认值是20KB左右如果你发现公共chunk里出现了一些几个字节的重复代码可以把minSize调小或置零让抽取逻辑更激进。在配置entry时还有一个和splitChunks强相关的优化选项entry的dependOn依赖关系。通过它可以让一个入口依赖另一个入口比如module.exports { entry: { main: ./src/index.js, vendor: ./src/vendor.js, admin: { import: ./src/admin.js, dependOn: vendor, }, }, };dependOn会告诉webpackadmin这个入口的运行依赖vendor入口里的模块。这可以避免splitChunks误把一些本应只由vendor提供的模块重复抽取同时让入口之间的依赖关系显式化。实际项目里如果你既想抽取公共依赖又希望保留入口的独立性这种配置方式非常有用。3.3 runtimeChunk入口里不写但必须懂的隐式chunk还有一种chunk虽然不直接由entry决定却和entry息息相关runtimeChunk。它承载的是webpack的运行时引导代码包括模块解析函数、热更新逻辑、异步加载逻辑等。不配置runtimeChunk时每个entry生成的bundle里都会内嵌一份完整或部分的runtime代码。如果你有多个entry每个bundle里的runtime就重复了。更重要的是runtime代码里经常包含chunk的id映射一旦任何一个异步chunk的内容变化入口bundle的hash就会跟着变导致浏览器缓存失效。把runtime单独抽成一个chunk可以让入口bundle的hash保持相对稳定。配置方式module.exports { optimization: { runtimeChunk: single, }, };或者更细致地每个入口都单独生成一个runtimemodule.exports { optimization: { runtimeChunk: true, // 或 { name: (entryPoint) runtime-${entryPoint.name} } }, };在实际中我通常建议多入口项目使用runtimeChunk: single把整个应用的运行时统一成一个文件配合splitChunks抽出的vendors、common能获得一个非常稳定的缓存策略。单入口项目如果追求极致缓存也建议把runtime单独抽出来否则修改一处业务代码可能导致主bundle的hash发生变化让用户重新下载整个主文件这对大项目来说是很亏的。4. 实战从单页到多页entry配置的完整演进路线4.1 单页应用的entry最小配置一个最小、够用的单页应用配置通常长这样const path require(path); module.exports { mode: production, context: __dirname, entry: ./src/index.js, output: { path: path.resolve(__dirname, dist), filename: [name].[contenthash:8].js, clean: true, }, };这里的entry是单字符串output.filename用了[name]实际会输出类似main.a1b2c3d4.js的文件名。配合HtmlWebpackPlugin时默认生成的HTML会自动引入这个bundle不需要额外手写script标签。在实际业务里单入口项目随着功能增多会引入代码分割于是入口代码里会出现大量动态importconst routes [ { path: /user, component: () import(./pages/User), }, ];webpack会为每个动态import生成独立的异步chunk这些chunk的命名默认来自webpack的magic comments或模块路径。你可以在import时手动添加/* webpackChunkName: user */来控制分包名。这个操作看似和entry无关但实际这些异步chunk都归属在main这个entry的chunkGroup下。所以即使是单入口你也不可能完全绕开对chunk的认知。4.2 多页应用MPA的entry自动生成方案多页应用最大的痛点不是“怎么写多个入口”而是“入口太多、不想手动维护”。手动维护意味着你每新增一个页面就要在webpack配置里加一行entry忘加了页面就构建不出来。为了根治这个问题我推荐用目录扫描的方式自动生成entry。假设你的目录结构如下src/ pages/ home/ index.js index.html about/ index.js index.html list/ index.js index.html那么可以用一个脚本自动生成entryMapconst fs require(fs); const path require(path); const pagesDir path.resolve(__dirname, src/pages); function getEntries() { const entries {}; fs.readdirSync(pagesDir).forEach((dirName) { const entryPath path.join(pagesDir, dirName, index.js); if (fs.existsSync(entryPath)) { entries[dirName] entryPath; } }); return entries; } module.exports { entry: getEntries(), };这样新页面只需要在pages目录下新建一个文件夹并放好index.js构建就能自动包含它。扩展性的代价是文件名必须严格遵循约定如果页面文件夹里缺少index.js它就会被静默跳过很可能构建产物少了一个页面而不自知。为了解决这个问题可以在扫描循环里加上日志输出把每个发现的entry打印出来或者在缺失时直接抛错避免静默失败。4.3 结合HtmlWebpackPlugin的多入口HTML分流多入口搭配HtmlWebpackPlugin时最直接的做法是每个页面一个plugin实例const HtmlWebpackPlugin require(html-webpack-plugin); const entries getEntries(); const htmlPlugins Object.keys(entries).map((name) { return new HtmlWebpackPlugin({ filename: ${name}.html, template: path.resolve(__dirname, src/pages/${name}/index.html), chunks: [name, vendors, common], }); }); module.exports { entry: entries, plugins: [...htmlPlugins], };这里的chunks字段非常关键。如果你不写chunks默认情况下HtmlWebpackPlugin会把所有entry生成的chunk以及所有split出来的chunk都注入到每一个HTML里。在多页面场景下这会导致home页面加载了admin页面的js既浪费流量又可能因为访问不存在的DOM而报错。手动指定chunks后每个HTML只加载自己需要的bundle。另一种写法是使用chunksSortMode来控制chunk的加载顺序比如chunksSortMode: manual加上数组顺序。不过现代浏览器支持ES Module和defer顺序问题通常不大只要保证公共chunk在业务chunk之前加载即可。如果你用传统script标签同步加载注意common和vendor要放在业务chunk前面否则运行时会报出“某某模块不存在”的错误。4.4 开发环境下的entry注意事项devServer与devtool开发环境下很多人会为entry额外添加热更新入口。最典型的例子是配合webpack-dev-server的hot模式你可能会看到这种配置module.exports { entry: { app: [ webpack/hot/dev-server.js, ./src/index.js, ], }, devServer: { hot: true, }, };数组入口在这里就派上了用场把热更新的client脚本和业务入口绑定在一起构成开发专用的bundle。但实际上webpack-dev-server的热更新并不依赖你手动添加这个脚本通常内置的HMR插件会自动注入。如果你在配置里手动添加反而可能造成重复注入。更需要注意的是devtool与entry的关系开发时配置devtool: eval-cheap-module-source-mapwebpack会对每个模块生成大量source map信息这些信息会被存进memory不会污染真实的entry产物。但如果你用entry设置的数组里包含了webpack-dev-server/client可能会让热更新的初始化时序产生微妙变化。我的经验是开发环境保持entry干净把环境差异交给webpack-merge和配置文件拆分处理而不是在entry里塞各种client脚本。另外开发环境可能希望devServer打开时自动指向一个特定页面路径。这可以通过devServer.openPage、或historyApiFallback配合单页面路由来实现它不直接属于entry的范畴但需要注意的是如果你是多页面应用historyApiFallback默认会把所有未知路径都rewrite到首页导致刷新about.html时被错误地代理到home页面。这时你需要像这样配置devServer: { historyApiFallback: { rewrites: [ { from: /^\/about/, to: /about.html }, { from: /^\/home/, to: /home.html }, ], }, }多页面开发环境中直接用/home.html这种真实HTML路径访问即可让devServer直接服务静态文件避免rewrite带来的混乱。5. 常见踩坑实录与排查手册5.1 数组入口“号称多入口但只产出一个bundle”的真相我在不少项目里看到过这样的配置entry: [./src/pageA.js, ./src/pageB.js],开发者以为这样就能生成两个bundle、两个页面。结果构建完成后dist目录里只有一个main.js打开页面A和B时加载的都是同一个文件。原因前面已经说过了数组入口本质上是单一入口的“多文件拼接”所有入口文件都会被合并进同一个chunk。webpack不会因为数组里有多个文件就认为它是多入口。如果你要的是两个独立页面必须用对象形式entry: { pageA: ./src/pageA.js, pageB: ./src/pageB.js, },这个坑很隐蔽尤其在只跑一次构建、不做产物检查时问题几乎不会暴露。等到真正上线部署发现页面B加载了页面A的逻辑才会追悔莫及。5.2 entry路径大小写与扩展名省略的坑不同操作系统对路径的大小写敏感度不同。在macOS/Linux上./src/Index.js和./src/index.js指向的是两个完全不同的文件在Windows上文件系统默认不区分大小写Index.js也能解析到index.js。于是经常出现这样的场景开发机器是Windows构建正常部署到Linux CI机器上报Module not found: Error: Cant resolve ./src/index.js。扩展名省略也有风险。webpack默认的resolve.extensions包含.js、.json等所以你写./src/index也能解析到index.js。但如果你在某个文件里把import ./utils写成小写而源文件名是Utils.js在大小写敏感的系统上就会失败。entry作为依赖图的根如果路径错了整个构建直接挂掉报错信息往往是一个冷冰冰的Cant resolve。排查方法很简单用path.resolve拼接绝对路径并且严格保持文件名字符一致。5.3 入口文件使用动态require导致打包“假成功”有时候你会想偷懒在entry文件里这么写const page process.env.PAGE; require(./pages/${page});这种动态requirewebpack在解析依赖时由于传入的是一个表达式无法静态分析出确切的模块路径于是会以./pages/为前缀做一个context module打包时会把这个目录下的所有可能文件都作为依赖包含进来。结果就是你本来只想打包一个页面却把整个pages目录下的所有页面全部打进了bundle构建还显示“成功”。这会让entry对应的bundle体积无故暴涨同时运行时的模块选择也完全错误。如果你确实需要动态选择模块建议把这个逻辑移到构建配置的function入口里而不是写在业务代码里。在function入口中读取环境变量确定返回哪个具体的入口文件路径让webpack解析到一个明确的静态路径。如果把动态逻辑留在业务代码中需要使用import()配合变量但也要尽量使用能推断路径的方式比如const pages { home: ./home/index, about: ./about/index, }; import(./pages/${pages[page]});这种写法能帮助webpack定位到确切的模块生成独立的异步chunk而不是一锅端。5.4 多入口时公共模块重复打包与hash不稳定多入口项目最常见的两个问题公共模块没有被抽出来每个bundle体积都很大或者抽出来了但入口bundle的hash依然频繁变动导致缓存失效。前者很好排查打开构建产物对比各entry文件里是否都有一段相同的代码比如React的运行时。如果size差异很大大概率是splitChunks配置没生效。检查一下optimization.splitChunks中是否设置了正确的cacheGroups以及minChunks和minSize是否合理。有时候不是没生效而是公共模块被引用次数只有1没达到minChunks: 2的阈值。这时可考虑把公共库单独用dependOn声明或者直接把minChunks改成1并加上name强制把指定模块抽出去。后者hash不稳定的原因很可能是runtime没有抽成独立chunk。入口bundle内部引用了其他chunk的id映射关系一旦异步chunk或split chunk的内容变化入口文件的hash就会变。解决方案就是前面提过的runtimeChunk: single把运行时独立出来。还有一种情况是output.chunkIds和moduleIds默认使用deterministic算法但如果你在某些loader或配置中引入了随机生成id的插件也会影响hash稳定性这种比较少见但加密混淆类插件要特别注意。5.5 实战排查使用stats分析entry相关chunk当你不知道entry配置到底产生了哪些chunk时不要猜要看构建统计信息。运行webpack构建时增加参数npx webpack --json stats.json然后打开生成的stats.json查找entrypoints字段entrypoints: { home: { name: home, chunks: [home, vendors, common], assets: [ { name: home.a1b2c3d4.js }, { name: vendors.e5f6a7b8.js } ] } }这个结构能直观地看到每个入口最终关联了哪些chunk、哪些assets。如果发现home这个入口的chunks列表中包含了预料之外的chunk名比如误被抽到了另一个页面的专属chunk那就要检查splitChunks的cacheGroups规则是不是太宽泛了。另一个好用的工具是webpack-bundle-analyzer它会以图形方式展示每个chunk里到底包含哪些模块。用这个工具可以快速发现某个entry对应的bundle里混入了不该有的模块比如把另一个页面的路由代码解析了进来。通常这时就是设置了过宽的test正则或者动态require的context module把所有文件卷了进来。6. 经验补给站entry配置的几个进阶技巧6.1 用函数入口实现按环境/动态目录切换前面提过函数入口的写法这里再给一个结合环境变量与多页面的完整示例module.exports (env, argv) { const target env.target || web; // 假设有环境参数 if (target web) { return { entry: { app: ./src/web/index.js, }, // 其他web相关配置 }; } if (target node) { return { entry: ./src/server/index.js, target: node, output: { filename: server.js, libraryTarget: commonjs2, }, }; } throw new Error(Unknown target); };这种方式特别适合需要一套webpack配置同时构建web端和node端的项目。函数入口可以读argv.mode、env参数按需返回不同entry。它比“在业务代码里判断环境”更纯粹因为业务代码依旧保持单一构建逻辑才做分支。6.2 entry与output.filename的命名联动output.filename里的[name]对应entry对象的key。如果你希望不同entry的bundle能区分目录可以使用output.filename里的函数形式或结合entry的命名output: { filename: (pathData) { const name pathData.chunk.name; if (name.startsWith(admin/)) { return admin/[name].[contenthash:8].js; } return [name].[contenthash:8].js; }, }但要让[name]包含admin/entry的key需要写成admin/index: ./src/admin/index.js。这种带斜杠的entry key在webpack中是被允许的但注意后续使用HtmlWebpackPlugin的chunks: [admin/index]时也要保持一致否则匹配不上。更规范的做法是保持entry key简洁在output.filename中通过[name]拼接然后用output.chunkLoadingGlobal、output.publicPath等控制路径。命名联动不是必须的技巧但一旦项目变大合理的命名结构能省下不少后续定位的时间。6.3 微前端/模块联邦下的entry设计思路现在很多团队在探讨微前端webpack 5的ModuleFederationPlugin提供了另一种思路不通过iframe或script标签拼业务而是在构建层把模块共享。在这种架构下entry的角色变得非常微妙。以某个主应用为例它的entry可能仍然是一个普通的SPA入口const ModuleFederationPlugin require(webpack).container.ModuleFederationPlugin; module.exports { entry: ./src/main.js, plugins: [ new ModuleFederationPlugin({ name: mainApp, remotes: { app2: app2http://localhost:3002/remoteEntry.js, }, shared: [react, react-dom], }), ], };这里的entry只是主应用自身的引导入口但ModuleFederationPlugin会额外生成一个remoteEntry.js它是一个运行时入口独立于主entry。这个remoteEntry被其他子应用远程加载以获取主应用共享的模块。也就是说在现代前端架构里“入口”已经不再局限于业务入口还包含了远程模块暴露的入口。设计时要清晰区分主entry负责应用引导remoteEntry负责跨应用模块共享。它们各自的chunk拆分策略也不同主entry可以splitChunksremoteEntry通常要保持精简避免把所有共享代码都塞进remoteEntry否则子应用加载成本会飙升。6.4 一些小众但好用的entry相关选项dependOn、library等除了常规写法entry的完整描述对象还可以携带一些额外选项。在webpack 5中单个entry可以是对象module.exports { entry: { index: { import: ./src/index.js, dependOn: shared, }, shared: ./src/shared.js, }, };dependOn前面说过用来声明入口之间的依赖让webpack知道index的运行需要shared先执行。这在需要把基础库单独抽到一个bundle并提前加载时非常有用。另一个选项是library虽然通常配置在output上但也可以基于entry级联使用。在构建类库时你可能需要多个UMD入口每个入口对应一个不同的组件库。这时entry的值可以是module.exports { entry: { my-lib: { import: ./src/index.js, library: { name: MyLib, type: umd, }, }, }, };不过大部分情况下把library放在output层级更规范因为一组入口通常共享同一种输出格式。还有entry的runtime选项它允许你为一个入口指定名字该名字表示对应的runtime chunk名称。结合函数形式的runtimeChunk使用可以精细控制每个入口的runtime归属。这种用法非常小众通常只有构建大型微前端架构时才需要动它。最后再分享一点我的个人经验entry这个配置项说难确实不难但说简单也真不简单。我见过太多项目一开始为了省事用字符串单入口业务膨胀后靠动态import硬撑最后主bundle还是太大又回过头折腾splitChunks和异步加载也见过多入口项目为了图快手动维护一份长长的一两百行的entry对象每加一个页面都要改配置肉眼排查错误十分痛苦。如果你问我有什么核心建议我会说三条第一单页优先用对象入口哪怕只有一个key也好过字符串因为后面扩展时不用改结构第二多入口务必让entry生成自动化用目录扫描代替手动维护第三多入口项目一定配splitChunks和runtimeChunk否则缓存优化无从谈起。entry不是一个写完就不动的配置它会随着项目架构一起演进。把它理解透你的webpack才算是真正入了门。

webpack入口配置全解析：从单页到多页的构建演进路径

相关推荐

合同、报告、资料统一加抬头图，用这个 Word 批处理功能一次设置全搞定

AI辅助学术写作的合规路径：从选题到答辩的工作流

从零手搓PPT自动化工具：用Python和python-pptx实现批量生成演示文稿

更多资讯

Ingress Nginx 高性能调优：从内核参数到 10 万 QPS 的完整实践

dart_scope鸿蒙适配实战：作用域驱动Flutter依赖生命周期治理

扩散语言模型技术全解析：并行生成、可控性与工程实践

YOLO11双模态改进源码解析：红外与RGB特征融合的目标检测实践

Ray 分布式对象溢出调优：应对千万级长上下文的跨存储治理

基于Python的网络小说分析系统：爬虫、文本挖掘与可视化实战

今日更新

智能硬件视频会议集成：从芯片选型到场景落地的全栈实践

FFmpeg音视频处理与5路RTMP推流实战：从原理到118克盒子部署

RK3528+1GB内存如何变身直播节点？硬编解码与六协议实战复盘

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？