接了个老项目要把一套两年没动的Vue2管理后台升级到Vue3 Vite。我原本以为最费时间的是组合式API重写和响应式改造结果真正卡了我两天的居然是路径配置这种基础问题。vue.config.js里的publicPath在Vite里变成了basepublic目录里的favicon和PDF照常被复制到dist部署到子路径后却集体404。这篇文章就把我从Vue2迁移到Vue3过程中关于Vite和Webpack路径配置差异、public目录使用的那一整套经验整理出来尤其是那些文档里不会明说、但实际一定会踩的坑。1. 先分清两件事publicPath 和 base谁才是Vite里的根路径1.1 Webpack体系里的根路径藏在publicPath里在Vue CLI底层是Webpack的项目里跟你路径最相关的配置就是publicPath在Vue CLI 3.3之前它叫baseUrl很多人从老项目拷配置时还会看到这个旧名字。这个值的作用是给构建产物中所有资源加上一个公共前缀默认是/。比如默认配置下构建出来的dist/index.html长这样script src/js/chunk-vendors.abc123.js/script link href/css/app.def456.css relstylesheet /这种写法只适合把站点部署在域名根路径。一旦你把dist丢到https://example.com/admin/下面浏览器请求的/js/chunk-vendors.js就会落到https://example.com/js/...直接404。所以多数Vue2项目的vue.config.js里都会有这么一段module.exports { publicPath: process.env.NODE_ENV production ? /admin/ : / }含义是开发时资源路径保持根路径方便dev server直接访问生产构建时才把/admin/前缀拼上去让资源和部署位置匹配。Webpack的publicPath还有一个特点它属于运行时配置。打包完成后你依然可以在代码里通过__webpack_public_path__动态修改比如做灰度发布、动态切换CDN域名时非常有用。这一点Vite没有直接等价物迁移时如果依赖这个能力需要另想办法。1.2 Vite的base除了改路径还改了开发服务器访问方式Vite对应的配置项叫base。先说怎么配// vite.config.js export default defineConfig({ base: /admin/ })看起来和publicPath差不多但有几个明显区别需要提前适应。第一base在开发和生产阶段是同一个值。你设置base: /admin/后跑npm run dev时访问地址会变成http://localhost:5173/admin/而不是之前的http://localhost:5173/。Webpack环境下的publicPath在开发时通常保持/生产时才通过环境变量改成子目录前缀两者使用习惯不一样。第二base影响的范围包括index.html中构建产物入口的引用、CSS里的url()、动态import的chunk路径以及import.meta.env.BASE_URL这个内置变量的值。也就是说你拿到import.meta.env.BASE_URL时拿到的就是base的值。第三base可以填几种不同形态的值这对迁移很关键。base取值含义典型场景/根路径默认值部署在域名根目录/admin/绝对子路径部署在https://example.com/admin/https://cdn.xxx.com/完整URL静态资源单独走CDN./相对路径部署位置不固定但会带来连锁问题空字符串类似./嵌入场景我见过许多人从Vue2迁移过来第一反应就是publicPath: ./换成base: ./因为Vue CLI时代用相对路径部署很省心。但Vite里的./埋了很多坑尤其是和public目录配合的时候接下来这两个章节就专门讲这个。2. public目录的迁移盲区同名目录三处行为不同2.1 先回顾Vue CLI时代public目录是怎么用的Vue CLI项目里public目录位于项目根目录和src平级。构建时目录里的所有文件会被原样复制到dist根目录不经过Webpack的打包管线所以不会生成hash文件名也不会被压缩优化。路径引用在模板和代码里一般是靠BASE_URL变量拼接的!-- public/index.html 模板 -- link relicon href% BASE_URL %favicon.ico /// 业务代码里访问public下的静态文件 const pdfUrl process.env.BASE_URL download/help.pdfprocess.env.BASE_URL是Vue CLI在构建时注入的特殊环境变量值来自publicPath。只要publicPath配置正确这种拼接方式就能保证资源路径和部署位置一致。这也是Vue CLI项目里public资源不容易出现子目录404的原因——很少有人在模板里写死绝对路径。那什么文件适合放public我自己的判断标准是三条不需要被引用进JS/CSS构建图的文件名不需要加hash的体积大、没必要走构建管线的。比如favicon.ico、robots.txt、manifest.json、第三方独立SDK的js文件、预先下载好的大PDF等。2.2 Vite里public目录的三处规则变化Vite同样使用项目根目录下的public文件夹构建时也原样复制到dist根目录。但要记住三处和Webpack明显不同的规则。第一引用public资源只能用根绝对路径比如/favicon.ico、/images/logo.png不能写相对路径。开发时会由dev server直接返回public目录下的文件构建后这个路径也不会被处理原样保留在代码里。有人习惯写./favicon.ico这在开发模式下容易受当前路由影响在Vite里属于错误姿势。第二public目录里的文件不能通过import从JS里引入。import /help.pdf这种写法不会走构建管线它只是给运行时留下一个字面量路径如果你试图import favicon from /favicon.ico然后期待它返回处理后URL那会得到和直接写/favicon.ico一样的结果最多算是把路径变成了变量并没有任何hash、压缩、校验发生。需要被import的资源应该放到src/assets下。第三public目录的根目录和base是两套逻辑。public目录里的文件在构建后始终复制到dist的根目录而不是dist/你的base子目录。假设base是/admin/你的favicon.ico最终在dist/favicon.ico可index.html里如果写了link relicon href/favicon.ico浏览器会请求https://example.com/favicon.ico。如果你的网站只部署了/admin/这一个应用这个请求可能走向另一个应用也可能直接404。public资源路径必须手动配合base使用这恰恰是迁移时最容易忽略的。2.3 process.env.BASE_URL改成import.meta.env.BASE_URLVite把Webpack时代的process.env.BASE_URL换成了import.meta.env.BASE_URL使用位置也从Node环境变量变成了ESM模块元信息。虽然名字相似但类型和替换时机不同// Vue2 Webpack const helpUrl process.env.BASE_URL download/help.pdf // Vue3 Vite const helpUrl import.meta.env.BASE_URL download/help.pdf当base为/或/admin/时这个替换基本无感。但如果base设成./import.meta.env.BASE_URL的值就是字符串./。这时候你在某个深路由页面里拼出./download/help.pdf浏览器会基于当前页面路径去解析结果很可能跑到/admin/users/download/help.pdf这种错误位置。另外在TypeScript项目里直接使用import.meta.env.BASE_URL可能会报类型错误。需要在src/vite-env.d.ts里加上/// reference typesvite/client /这一步补上后import.meta.env下的内置字段以及你的VITE自定义变量才会有类型提示。3. 部署子目录后favicon集体404一次典型排错的全过程3.1 现象本地正常一上测试环境就抓瞎这里分享一个我迁移时实际遇到的案例。项目从Vue2 Vue CLI迁到Vue3 Vite为了保持原来的部署习惯我在vite.config.js里写了base: ./。构建很顺利dist目录也出来了部署到nginx的/portal/子路径下。结果页面打开后JS能跑、CSS也正常但浏览器标签页的favicon一直不显示。打开Network面板一看favicon.ico请求的地址是https://example.com/favicon.ico状态404。public目录下另一个静态PDF文件也有同样问题业务代码里用import.meta.env.BASE_URL download/help.pdf拼出来的路径请求后同样是404。3.2 看构建产物找出路径没有生效的根源先看dist目录结构favicon.ico确实在dist根目录复制逻辑没问题。再打开dist/index.html会发现一个非常典型的组合script typemodule crossorigin src./assets/index-2f3a1c.js/script link relicon href/favicon.ico /同样配置了相对base但script标签被加上了./前缀而link relicon里的/favicon.ico纹丝不动。原因在于Vite对构建产物资源的重写只会作用于经过构建入口进入的资源public目录里的文件是原样复制的html里写死的绝对路径自然也不会被改写成相对路径。Webpack时代为什么没遇到这个问题因为Vue CLI的index.html模板里用的是% BASE_URL %favicon.icoBASE_URL在渲染模板时被替换成publicPath的值。你配置publicPath为./模板里出来的就是./favicon.ico天然相对。Vite的官方模板则直接给/favicon.ico很多人在迁移时保留了这种写法再配合base: ./就把这个坑踩实了。3.3 三种修复方案按复杂程度排个序方案一改index.html用Vite的HTML环境变量替换语法%BASE_URL%link relicon href%BASE_URL%favicon.ico /构建后这个位置会被替换成对应base的值。如果base是/portal/产物里是/portal/favicon.ico如果base是./产物里是./favicon.ico。方案二不在index.html里硬编码favicon改到main.js里动态创建const favicon document.createElement(link) favicon.rel icon favicon.href ${import.meta.env.BASE_URL}favicon.ico document.head.appendChild(favicon)这是一招兜底方案不管HTML环境变量替换在哪个版本上表现如何动态拼接一定生效而且还能根据环境或域名动态切换不同favicon。方案三彻底放弃相对base改用绝对路径base让所有路径引用逻辑统一。这个方案是我现在最推荐的原因下面会展开。3.4 为什么我最终不推荐base: ./base: ./在Vue CLI时代算是一个通用解但在Vite里有三个连锁问题。第一是public目录资源路径需要像上面那样逐处处理稍一漏掉就404。第二是import.meta.env.BASE_URL会变成./在history路由下拼接资源路径很容易拼错。第三是动态import的chunk加载在某些页面URL下也会受相对路径解析影响特别是用户刷新一个深层次路由页面时浏览器拿当前URL去解析相对chunk路径很容易请求到不存在的地址。所以我现在的观点很明确如果部署子路径是确定的就老老实实用/portal/这种绝对路径base如果部署位置真的完全不可控宁可让后端在nginx做一层简单的前缀映射也不要在前端工程里强行用相对路径打天下。4. 组件里那些资源引用require、别名、动态路径逐个改4.1 require没有了import顶上Vue2项目里最常见的动态资源写法是require(/assets/logo.png)这在Vite里不存在。Vite基于ESM推荐直接用静态importimport logo from /assets/logo.png如果文件小于assetsInlineLimit默认是4KBVite会把文件直接内联成base64字符串减少一次请求超过阈值则生成带hash的文件并在引用处生成对应URL。这个行为你不需要特殊配置但要知道它存在以免排查问题时误判。如果确实需要运行时动态拼路径比如根据用户选择显示某个图标别用字符串拼接/assets/ name .png这在Vite里不会被解析。官方推荐的是new URL方式const iconUrl new URL(../assets/icons/${name}.svg, import.meta.url).href原理是import.meta.url指向当前模块文件的完整URL用它作为基准new URL()可以解析出相对路径对应的最终地址Vite在构建时扫描到这种写法会把../assets/icons/目录下的所有文件都当作潜在资源打进产物里。所以这种写法里的name变量最好控制在有限集合内别把整个文件系统路径都塞进去。4.2 别名的配置别被__dirname坑了Vue CLI默认支持指向src目录Vite里需要手动配// vite.config.ts import path from path export default defineConfig({ resolve: { alias: { : path.resolve(__dirname, src) } } })但现在的Vite项目通常都是ESM模式如果package.json里设置了type: modulevite.config.ts里直接用__dirname会直接报错因为ESM里没有这个变量。官方推荐的写法是这样import { fileURLToPath, URL } from node:url export default defineConfig({ resolve: { alias: { : fileURLToPath(new URL(./src, import.meta.url)) } } })这段代码在Vue官方创建Vite项目的模板里就能看到直接用就行。配置好之后模板和JS里的/assets/xxx.png都能正常解析。不过我建议CSS里的url路径尽量少依赖别名有些样式处理链路对alias的支持不如JS稳定相对路径加上src/assets的合理目录层级反而是最省心的。4.3 public和src/assets的分工迁移时列一张判断清单很多Vue2项目当初为了省事把所有图片、PDF、字体都丢进public导致迁移时一改路径就乱。这里给出我自己的判断清单照着做不容易错。文件特征推荐位置原因favicon.ico、robots.txt、manifest.json、第三方SDKpublic必须原样输出、不带hash大体积且少变化的PDF/ZIPpublic避免构建时被尝试解析会被import进JS的图片/字体src/assets获得hash指纹和CDN友好路径小于4KB的小图标src/assets自动内联为base64减少请求需要经构建处理压缩、雪碧图的资源src/assets走完整构建管线运行时用户上传的动态文件服务器存储public不适合承载动态内容一句话概括public适合不需要被构建、也不想被构建的原始文件assets适合你希望构建帮你管理版本和优化的资源。两者混着放也不是不行但要先想清楚每个文件的定位。4.4 TS类型、CSS里的小坑从Vue2迁到Vue3 Vite TS时资源导入会碰见TS报错比如Cannot find module ./logo.png。这是因为TS默认不认识图片模块。Vite提供了现成的类型声明在src/vite-env.d.ts里引入/// reference typesvite/client /这样.png、.svg、.css等模块导入都会有类型。CSS里引用public资源也有个容易忽略的差异public资源在CSS里同样要用绝对路径引用但如果你设置了base为./CSS文件本身经过构建后路径被改写的逻辑和HTML里完全不同最容易出现样式里的背景图找不到。所以我自己的经验是CSS背景图这类资源不要放public直接放在src/assets里用相对路径或import方式处理让Vite统一改写反而省心。5. 部署形态决定base取值路由、环境变量和nginx一次配齐5.1 三种部署形态下base怎么选部署在域名根目录base: /是默认值什么都不用改。部署在固定子路径比如https://example.com/portal/推荐base: /portal/。如果静态资源要全部走CDN可以写成base: https://cdn.example.com/这种情况下HTML里引用的都是CDN完整地址public资源的引用也要手动带上CDN域名前缀。相对路径./只适合一种场景打包后的dist文件会被复制到多个不同的子路径而且无法预知具体位置。这种场景在纯静态内嵌、离线包分发里偶尔会遇到。使用相对路径时一定要记得把index.html里的public资源全部改成%BASE_URL%业务代码里所有public资源都用import.meta.env.BASE_URL拼接并且路由不能使用history模式否则一刷新就出问题。5.2 路由base和Vite base要联动Vue Router 4创建history模式路由时第二个参数是路由的base路径import { createRouter, createWebHistory } from vue-router const router createRouter({ history: createWebHistory(import.meta.env.BASE_URL), routes })这一步在Vue CLI时代就是标配Vite迁移时把process.env.BASE_URL换成import.meta.env.BASE_URL即可。需要注意的是createWebHistory接收的base要求能表达一个真实路径前缀./这种相对值虽然在开发时可能不报错但在线上history模式下非常不可靠再次印证了绝对base的必要性。配套的nginx配置里如果部署在/portal/location要保证未匹配到的前端路由都能回到index.htmllocation /portal/ { alias /srv/www/myapp/; try_files $uri $uri/ /portal/index.html; }注意 alias 和 try_files 的配合。如果只有根路径一个应用用root加try_files也可以。关键是前后端资源请求路径能对上不要出现页面能打开、刷新就404这种经典问题。5.3 环境变量从VUE_APP_换成VITE_Vue CLI的环境变量默认前缀是VUE_APP_Vite换成了VITE_。比如原来在.env.production里写VUE_APP_API_BASE_URLhttps://api.example.com迁移后要改成VITE_API_BASE_URLhttps://api.example.com。代码里的读取方式也从process.env.VUE_APP_API_BASE_URL改成import.meta.env.VITE_API_BASE_URL。一个很多人会混淆的点import.meta.env.BASE_URL是Vite内置的和你自己定义的VITE_*变量是两回事前者由base配置自动推导后者来自.env文件。开发接口联调时如果前后端分离Vite里的代理配置和Vue CLI差异不大// vite.config.js server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }这个配置只是把开发时的接口请求转发到后端和生产部署的nginx代理是两条独立链路别把两者混为一谈。5.4 上线前花五分钟检查这几项写到这里分享一个我固定保留的上线前检查步骤。构建完成后先不要急着上传服务器用npx vite preview在本地起一个预览服务打开Network面板逐项检查页面主资源请求路径是否带上了正确的base前缀favicon、public下文件是否请求到了预期地址动态import的chunk在刷新深层路由后能不能正常加载CSS里的背景图有没有404。这四个检查点全部通过再扔到nginx上基本不会出现路径相关的幺蛾子。我个人在实际操作中还有一个习惯在vite.config.js里加一行打印把base值和import.meta.env.BASE_URL的最终形态输出到日志里多环境构建时能一眼看出这次构建用的什么路径策略。这个办法成本极低排查效率提升却不小遇到测试环境正常预发布又挂了这类问题基本能省掉一半时间。迁移这件事路径看似小问题但一旦被404缠上折磨人程度一点不比业务逻辑重写低。希望这篇基于Vite和Webpack迁移实战的路径配置总结能帮你少踩几个我已经替大家踩过的坑。