浏览器原生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 的核心差异在哪？
关键不在“能不能打包”，而在于“什么时候打包”和“怎么处理模块”：
立即学习“Java免费学习笔记（深入）”；
-
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 二进制的支持程度——这些细节比“快不快”更容易决定落地成败。
