17370845950

浏览器原生ESM仅支持语法加载，不支持路径解析、包名解析等工程化能力；Webpack构建时打包，Vite开发时按需编译，核心差异在于打包时机与模块处理方式。

JavaScript 原生不支持 import 从本地文件系统加载模块（比如 import { foo } from './utils.js'），浏览器只认 HTTP URL，且不处理路径解析、依赖图、代码分割等逻辑——模块打包器就是为填补这个 gap 而生的。

为什么浏览器直接运行 import 会报错？

即使你写了 type="module" 的 ，浏览器仍要求：

• import 路径必须是完整 URL 或以 /、./、../ 开头的相对路径
• 不能省略后缀（import './utils.js' ✅，import './utils' ❌）
• 不支持 Node.js 风格的包名解析（import 'lodash' 直接失败）
• 没有 node_modules 查找机制，也没有 package.json#exports 解析

也就是说，原生 ESM 只解决“语法加载”，不解决“工程化加载”。Webpack 和 Vite 都在这一层之上补全了路径重写、依赖遍历、模块标准化等能力。

webpack 和 vite 的核心差异在哪？

关键不在“能不能打包”，而在于“什么时候打包”和“怎么处理模块”：

• webpack 是构建时（build-time）打包：启动 webpack serve 也会先分析整个依赖图、转译、合并、生成 chunk，再起 dev server —— 启动慢、热更新（HMR）需 patch 模块图
• vite 是开发时（dev-time）按需编译：用原生 ESM + import 请求拦截，在浏览器请求 /src/main.js 时，vite 动态将 import './utils.ts' 改写成 import '/@fs/.../utils.ts' 并实时转译（TS/Babel）、返回 JS，不预打包
• vite 生产构建默认仍用 esbuild + rollup 打包（可选关闭），但开发阶段零打包；webpack 无论开发还是生产都走同一套打包流水线

这导致：

npm create vite@latest my-app -- --template react
# 生成的 vite.config.js 不需要配置入口、output、resolve.alias 等 —— 它默认就懂 tsx/jsx/resolve/alias

而同等功能的 webpack.config.js 通常要手动配 resolve.extensions、resolve.alias、rules 处理 ts/jsx/css，否则连 import React from 'react' 都会失败。

哪些场景会让 vite 行为和你预期不符？

vite 的“快”有前提，几个常见翻车点：

• 动态 import() 路径含变量时（import(`./pages/${page}.tsx`)），vite 默认无法静态分析，需显式加 import.meta.glob
• 使用非标准导出（如 export = xxx 的 CommonJS 模块），vite 的 ES 模块模拟可能失败，需配 optimizeDeps.include
• vite 的 HMR 对 CSS-in-JS（如 styled-components）或自定义 hook 更新支持弱于 webpack + react-refresh，有时需强制刷新
• 某些 Webpack 插件生态（如 html-webpack-plugin 的模板注入、copy-webpack-plugin）在 vite 中需改用 vite-plugin-html 或 vite-plugin-static-copy，API 不兼容

例如，想让 vite 预构建 lodash-es 并正确处理命名导出：

export default defineConfig({
  optimizeDeps: {
    include: ['lodash-es']
  }
})

模块打包器不是“越新越好”，而是看它是否匹配你的工程约束：团队熟悉度、插件生态需求、是否重度依赖 Webpack 特有 API（如 __webpack_require__.e）、CI 构建环境对 esbuild 二进制的支持程度——这些细节比“快不快”更容易决定落地成败。