前端工程化（三）：打包器如何从入口生成构建产物

从入口文件开始建立依赖图

假设入口是 main.js，它静态引入 a.js，而 a.js 又引入 b.js。打包器通常从 main.js 开始读取模块，解析导入路径，定位 a.js 和 b.js，递归分析它们继续引用的依赖，最终形成一张模块依赖图。

这个过程不只是“找文件”。源码还可能需要经过 TypeScript、JSX、CSS 等转换，之后打包器才会继续分析转换后的模块。完成依赖分析后，打包器根据入口、动态 import() 边界和构建配置生成一个或多个 chunk，并输出 JavaScript、CSS、source map 等产物。

可以把链路概括为：

入口
-> 模块解析
-> 资源转换
-> 递归建立依赖图
-> 生成 chunk
-> 输出构建产物

loader 和 plugin 解决的问题不同

loader 通常针对具体资源或模块进行读取和转换。例如 CSS loader 处理 CSS，TypeScript 相关转换处理 TypeScript 源码。loader 的关注点是“这个资源如何变成打包器可以继续处理的模块”。

plugin 的范围更大。它通过打包器提供的生命周期钩子介入构建过程，可以参与模块解析、依赖分析、chunk 生成、资源输出等阶段。loader 是资源级转换，plugin 是构建流程级扩展，这是面试中需要明确说出的边界。

resolve.extensionAlias 是模块解析配置

在 my-world/next.config.ts 中，webpack 配置了扩展名映射：

webpack: (webpackConfig) => {
  webpackConfig.resolve.extensionAlias = {
    ".cjs": [".cts", ".cjs"],
    ".js": [".ts", ".tsx", ".js", ".jsx"],
    ".mjs": [".mts", ".mjs"],
  };

  return webpackConfig;
}

这段配置解决的是模块定位问题：当代码引用某种扩展名时，webpack 按声明顺序尝试匹配真实文件。它不是 loader，因为没有转换资源内容；也不是 plugin，因为没有通过生命周期钩子扩展整个构建流程。

chunk 和内容 hash 如何影响性能

生产构建把代码拆成多个 chunk，可以让页面首屏只加载当前需要的资源，其他功能在真正使用时再加载。合理的代码分割还可以让不同页面之间复用公共 chunk，减少重复下载。

文件名加入内容 hash 后，文件内容变化时 hash 通常也会变化，浏览器可以安全地对旧文件使用长期缓存；只有内容变化的文件需要重新下载。这样既支持缓存复用，也避免了发布新版本后浏览器继续使用旧代码。

但 chunk 不是越多越好。如果动态模块内部继续层层动态导入，就可能形成请求瀑布：前一个资源请求完成后才触发下一个请求，串行等待叠加后，代码分割的收益可能被网络开销抵消。治理方式包括控制拆包粒度、避免不必要的动态依赖链、预加载即将使用的 chunk，以及并行加载互不依赖的模块。

source map 让构建产物可以追溯到源码

生产代码通常经过转换、压缩和合并，浏览器直接看到的文件不容易对应到原始 TypeScript、JSX 或 CSS。source map 保存了构建代码位置与原始源码位置之间的映射，可以帮助开发者调试和定位错误堆栈。

生产环境是否直接公开 source map 需要权衡。公开它能提高排错效率，但也可能暴露源码结构、路径和实现细节。一种常见做法是将 source map 上传到错误监控平台，让内部工具能够还原堆栈，但不直接把映射文件暴露给所有访问者。

开发态和生产态的目标不同

开发环境优先反馈速度：启动要快，热更新要快，错误要容易定位。因此开发构建通常减少压缩和复杂优化，并保留更强的 source map。

生产环境优先最终用户体验和线上稳定性：需要关注产物体积、加载和执行性能、缓存复用、代码分割以及稳定的错误定位。压缩、Tree Shaking、内容 hash 和生产 source map 策略都服务于这些目标。

Webpack 和 Vite 的开发方式不同

Webpack 的开发服务器通常先组织模块并生成 bundle，再通过增量编译和 HMR 更新。Vite 的开发环境更多利用浏览器原生 ESM，按请求提供源码模块，并对第三方依赖做预构建，因此冷启动通常更快。

这不意味着 Vite 的生产环境完全不打包。生产构建仍然需要进行打包、代码分割、压缩和产物优化。开发态和生产态的工作方式不同，是因为它们优先解决的问题不同。

用真实 .next 产物定位体积问题

本次对 my-world 已有生产构建进行了只读观察。.next/static/chunks 中有 81 个 JavaScript chunk 和 8 个 CSS chunk。按文件大小排序后，最大的 JavaScript chunk 是 146ww84hlwbm6.js，约 3.85 MB。

继续在 .next/diagnostics/route-bundle-stats.json 中追踪这个文件，发现它出现在 /admin/[[...segments]] 的首屏 chunk 列表中；普通首页 / 的首屏列表不包含它。首页首屏未压缩 JavaScript 约 726 KB，管理后台首屏未压缩 JavaScript 约 6.44 MB。

这个结果不能简单解读成“项目首页有 3.85 MB 的性能问题”。首先，大 chunk 主要属于 Payload 管理后台，而不是普通前台首页；其次，firstLoadUncompressedJsBytes 是未压缩 JavaScript 体积，不是所有资源总大小，也不能直接等同于真实加载时间。是否值得优化，还要结合管理员访问频率、压缩后传输体积、真实加载和交互数据、维护成本以及后台未来增长判断。