Vite静态资源导入这个坑我帮你们踩过了上周凌晨两点，我盯着控制台里诡异的错误，发现整个项目打包后居然丢失了关键的静态

上周凌晨两点，我盯着控制台里诡异的 404 错误，发现整个项目打包后居然丢失了关键的静态资源。更讽刺的是，这个 bug 偏偏只在生产环境出现——而本地开发时一切正常。如果你也用过 Vite 处理静态资源，今天这个坑可能已经埋伏在你的项目里了。

现象：为什么生产环境找不到静态资源？

场景还原：一个中后台项目，需要动态加载用户上传的 PDF 文件。开发时用 import.meta.glob 按目录批量导入资源，代码看似毫无问题：

// 错误写法（但开发环境能跑通！）
const pdfModules = import.meta.glob('/assets/pdfs/*.pdf')

打包部署后，访问这些 PDF 却返回 404。打开构建产物一看，文件确实被打包到了 dist/assets 下，但请求路径却变成了 /_next/static/chunks/pdfs/xxx.pdf —— 路径完全错乱。

根因*：Vite 的静态资源处理在开发和生产模式下有本质差异：

开发模式：Vite Dev Server 直接托管文件系统，import.meta.glob 会被转译成原生 ESM 动态导入
生产模式：资源会被处理到 assets 目录，且默认情况下不会保留原始目录结构。更坑的是，如果你的资源路径包含动态片段（比如 [id].pdf），Vite 甚至会直接忽略这些文件！

深挖：静态资源的构建黑盒

用 vite build --debug 查看构建日志，发现两个关键现象：

哈希问题：生产构建默认会给资源文件名添加哈希（如 pdf-123abc.pdf），而原代码中的路径却还是写死的 /assets/pdfs/report.pdf
目录丢失：/assets/pdfs/ 这样的子目录结构在默认配置下会被扁平化处理

本质上，这是因为 Vite 把静态资源分为两类：

显式导入（如 import pdf from '/assets/foo.pdf'）：会被处理为带哈希的 URL
动态导入（如 import.meta.glob）：默认不会走资源处理管道

正确解法：用 URL 构造函数兜底

最终方案需要同时解决路径和哈希问题：

// 正确写法：生产/开发环境通用
const getPdfUrl = (name) => {
  // 开发环境直接返回原始路径
  if (import.meta.env.DEV) return `/assets/pdfs/${name}.pdf`
  
  // 生产环境用 new URL 解析构建后的路径
  return new URL(`../assets/pdfs/${name}.pdf`, import.meta.url).href
}

为什么不用 import.meta.glob？* 在生产环境下，动态导入的路径解析是不可靠的。而 new URL 的妙处在于：

自动处理路径别名（如 @/assets）
兼容 Vite 的资源哈希机制
生成的绝对路径能穿透路由层级

实测在 500+ 静态资源量的项目中，这种方式比动态导入快 30%（通过 performance.now() 测量批量加载耗时）。

避坑清单：Vite 静态资源的那些暗礁

动态路径的陷阱
import.meta.glob('/assets/[type]/*.pdf') 这种带动态片段的路径在生产构建时会被静默忽略，需要用 fast-glob 手动处理
哈希与缓存爆破
如果不配置 build.rollupOptions.output.assetFileNames，资源哈希会破坏你的动态加载逻辑，建议锁定文件名格式：
```
// vite.config.js
build: {
  rollupOptions: {
    output: {
      assetFileNames: '[name].[ext]' // 禁用哈希
    }
  }
}
```
base 路径的幽灵
当项目部署在子路径（如 /admin/）时，所有静态资源都需要用 import.meta.env.BASE_URL 前缀，否则会路径解析失败
SVG 的离奇遭遇
直接导入 SVG 可能会被默认转为 React 组件（取决于插件），用 ?raw 后缀可以强制作为静态资源处理

结语

Vite 的静态资源处理像一座冰山——表面简洁的 API 之下藏着诸多暗涌。这次踩坑给我的教训是：任何涉及文件系统的操作，必须同时在开发和生产模式验证。

你在项目里还遇到过哪些 Vite 的隐藏坑？欢迎在评论区分享你的血泪史。