因为项目复杂度提高，前端工程化已成为一种必然。

模块化

痛点：代码量激增、单文件难以维护、全局变量冲突、命名污染频发。

因为 JS 的发展很快。项目的代码量也逐渐提高，单纯将所有代码写在一个文件里已经难以维护。没有模块化，所有的 JS 变量都挂在 window 中。命名冲突、全局变量污染等问题接踵而至。有了模块化，可以按照功能将 JS 代码拆成一个个独立的模块，一个文件就是一个模块，模块之间可以引入、使用。在提高代码独立性、复用性的也让模块之间的依赖关系变得更加明晰。

早期的模块化是通过立即执行函数来实现的。通过创建一个新的作用域，避免了命名冲突、全局变量污染等问题，但是它仍然无法解决模块之间的依赖问题。真正的模块化顺势出现，包括 AMD、CMD、CJS、ESM 等。现在以 CJS、ESM 为主。其实，其中 CJS 主要用于 Node 环境，ESM 则是 ECMAScript 官方发布的模块化标准。早期主要用于浏览器环境，现在 Node 也支持 ESM 模块化。

CJS 与 ESM 的区别

痛点：CJS 与 ESM 混用导致建立报错、调试困难；怎么说呢，不同加载时机引起性能波动。

语法层面

• CJS 导入：const a = require;其实，
• CJS 导出：module.exports = { name: 'cjs'。age: 30 }，
• ESM 导入：import { add } from './math';
• ESM 导出：export default { add,name };

注意 ESM 只能有一个默认导出，而 CJS 的 module.exports 是一个对象。

模块加载方式和时机

• CJS 同步加载 / 动态加载 require 本质上是函数，仅在代码执行到该行时才读取对应模块。同步加载会阻塞后续代码，按理说，动态加载可放在条件判断中，根据业务场景按需加载。
• ESM 编译时静态分析 编译阶段扫描所有 import/export，生成依赖图。其实，import 为异步且静态。只能写在顶层，会被提高到模块顶部执行。其实，

Caching不同

• CJS 缓存的是 module.exports 对象的值拷贝。即使内部修改导出的值，通过 require{​}获取到的仍是最初缓存结果。
• ESM 缓存的是值的引用。导出的变量会与原模块保持动态关联，同步更新。

This 指向不同

• CJS 中：This === module.exports // true
• ESM 默认使用严格模式。全局 This 为 undefined.

//__dirname// 和 //__filename//

• CJS 可直接使用这两个参数，因为包装函数会传递它们。话说回来，
• E​SM 中不存在需要通过 import.meta.url 获取当前模块 URL。再自行解析目录方法，

建立打包

为什么需要打包？

Trouble: 浏览器只认识原生 HTML/CSS/JavaScript。却要使用 SCSS/Less/TailWindCSS、JSX/Vue SFC、新语法及 CJS 模块，这些“高级语言”如果不会直接报错。

• Sass/Less/TailWindCSS 等预处理器

B​undle 工具把这些高级特性翻译成浏览器能识别的代码，同时区分开发环境和生产环境需求：

开发环境	生产环境
- 不压缩代码 - 开启 SourceMap - 热更新快	- 极致压缩 - 摇树调整 - 去除调试信息

打包工具干了什么？

Pain point: 手动管理依赖、手动拼接文件导致错误频出且效率低下。

• .Entry——从哪开始干活？

  entry: './src/main.js'

  Webpack 会从入口文件开始递归解析所有 并把相关资源拉进来打包。
• .Output——打包完放哪？叫啥名，

  output: {
  path这方面，path.resolve。filename: 'bundle.js'
  }

• .Loader ——遇到什么文件，怎么处理 Webpack 原生只认识 JavaScript 与 JSON。Loader 是"翻译官 + 加工厂"。按理说，示例这方面，

  module: {
  至于rules。// 从右到左执行
  }
  ]
  }

• .Plugin——流水线上的“提高” 凡是 Loader 做不了的任务，都交给 Plugin。例如自动生成 HTML 并注入资源：

  plugins: 

• .Mode——切换 “开发 / 生产” 环境

  mode: 'development' // 或 'production'

• .Bundle——得到最终可部署文件

Webpack 与 Vite 的区别

Pain point: Webpack 冷启动慢、热更新卡顿；Vite 启动快但对第三方库有预建立要求。

• 全部预编译 + 打包 → 再开启服务器
  • 递归解析所有 import/require → 建立完整依赖图
  • 通过 Loader 转译所有文件
  • 合并为 bundle.js 放入内存
  • 启动本地服务器供浏览器访问
• 按需即时编译 + 原生 ESM 加载
  • 不预解析业务代码。仅启动轻量 HTTP Server
  • 浏览器使用原生 type="module" 请求所需模块
  • Vite 拦截请求 → 用 esbuild 实时转译 → 返回给浏览器
  • 第三方依赖一次预建立 成 ESM 并缓存，以解决 CJS 在浏览 器中的兼容性问题

资源缓存策略

Pain point: 浏览器每次请求都走网络导致页面首屏渲染慢；缓存失效又导致使用者看到旧内容。

再看强缓存，首次请求后直接本地保存资源及其有效期；后续请求若未过期，则 **不向服务器发送任何请求**。适用于**不经常变动且带哈希** 的静态资源。

从协商缓存来看，首次请求后保存资源并记录标识；后续请求会携带标识向服务器询问是否有更新；若返回 304，则继续使用本地缓存，否则下载新资源。适用于**偶尔变动、不带哈希** 的文件。

<\/table>

策略	响应头示例
不使用缓存	Cache-Control: no-store
强缓存	Cache-Control:max-age=31536000 Expires: Mon。01 Jan 2030 00:00:00 GMT
协商缓存	ETag:"686897696a7c876b7e" Last-Modified: Wed,21 Oct 2020 07:28:00 GMT

• 带哈希且不经常改动 → 强缓存 + 长 max‑age
• 无哈希或偶尔改动 → 协商缓存 + 合理 max‑age
• 入口文件等经常改动 → 不缓存或 very short max‑age <\/ul>

  推荐配合 CDN，将资源就近分发至使用者所在地区，实现“最近距离取货”。<\/p>

  打包体积调整

---