项目中的路径问题1. 相对路径与绝对路径详解 2. publicPath的配置详解 3. base的配置详解 4. hi

一、前置知识

相对路径：从当前文件所在目录开始
绝对路径：从根域名或完整URL开始

//假设当前文件路径为 `https://example.com/blog/post.html`

<!-- 不加斜杠的路径 （相对路径） --> <img src="images/logo.png"> 
//实际解析为：https://example.com/blog/images/logo.png 
<!-- 加斜杠的路径(绝对路径) --> <img src="/images/logo.png"> 
//实际解析为：https://example.com/images/logo.png

<img src="/assets/images/logo.png"> <!-- 无论当前页面在哪个子目录，均指向根目录下的assets文件夹 -->

<!-- 假设当前文件路径为 /blog/post.html --> 
<img src="logo.png"> <!-- 等价于 ./logo.png --> 
<!-- 显式声明当前目录 --> 
<img src="images/logo.png"><!-- 等价于 ./images/logo.png -->

二、vue项目中的配置

publicPath:为打包后资源的路径配置
base: 为router中的路径配置

publicPath结合场景解析：

比如vue项目打包完之后，会交给运维部署，因为是单页面，运维会将所有的路径访问指向打包后的html页面

//问题一：

www.ddd.com/   
www.ddd.com/a/b/c
// 即，正确配置下，以上两个都会访问到同一html页面

//当比如，部署上线后，访问首页可以正常访问，当访问其他路径，页面是404，就可能是因为没有做页面映射。

2.打包的资源路径：当能访问到页面后，浏览器会解析，解析过程中会遇到很多外部资源，资源加载的路径就与publicPath有关了：

//vue.config.js
//publicPath配置为''的情况：

module.exports={
    devServer:{},
    publicPath:'', //打包后，资源的前缀。如果没有前缀，则资源中的路径将没有“/”，即相对路径。
}

//场景举例：
页面的路径的路径有很多，虽然之前有说，都会定向到统一的路径，但对于资源的路径是唯一的。
场景问题：
- 此时有一个css资源路径： www.sss.com/css/kk.uuu.css  【只有通过这个路径才能访问到css】
- 但是，目前打包路径配置为publicPath:''，即html资源中的路径为 css/kk.uuu.css
- 若访问路径为：www.sss.com/ , 那么该资源可以正常加载，路径就是www.sss.com/css/kk.uuu.css
- 但是，若访问路径为：www.sss.com/a/b/c , 那么就访问不到该资源了，www.sss.com/a/b/c/css/kk.uuu.css
解决方法：
- 设置publicPath:'/' ， 这样html中的资源就变成了绝对路径 /css/kk.uuu.css
- 不管访问哪个资源，都拼接的是根目录。
- 即publicPath影响的是打包后的资源路径

base结合场景解析：

// base: router中的路径配置 
const router = new VueRouter({
    routes, // 路由配置规则，访问的路径，根据路由规则进行匹配
    mode：'history'
    base:''
})

场景案例：比如，运维部署上去后，是在一个子目录下。

- 当访问www.sss.com/admin/about时，是不能匹配到路由规则中的/about的，需要改为：/admin/about
- 配置base:'admin' ， 就是在配置路由的前缀

注： publicPath与base最好配合环境变量使用。

三、顺带提一下history与hash的区别：

Hash模式：

原理：

URL 结构：http://example.com/#/path（以 # 分隔路由）
实现机制：
- 通过 window.location.hash 获取和修改 URL 的 hash 部分。
- 监听浏览器的 hashchange 事件，当 hash 变化时触发路由更新。
- 无需服务器配合：所有路由逻辑由前端控制，服务器只需返回同一个 HTML 文件。

特点：

优点：
- 兼容性极强：支持所有浏览器和旧版本。
- 无需服务器配置：适合静态文件服务器或简单托管环境。
缺点：
- URL 不美观：包含 # 符号，可能被误认为“页面内锚点”。
- SEO 不友好：搜索引擎默认忽略 # 后的内容。
- 路由功能受限：无法直接使用 window.location.pathname 等标准 API。

History模式：

原理：

URL 结构：http://example.com/path（与普通 URL 无异）
实现机制：
- 使用 HTML5 的 History API（pushState, replaceState, popstate 事件）。
- 通过修改浏览器的历史记录栈来模拟页面跳转。
- 需要服务器配合：所有非静态资源请求必须返回 index.html，否则会出现 404 错误。

特点：

优点：
- URL 干净：无 # 符号，符合传统 URL 规范。
- SEO 友好：搜索引擎可正常抓取路由内容。
- 功能完整：支持完整的路由 API 和浏览器历史操作。
缺点：
- 服务器配置复杂：需额外设置（如 Nginx/Apache 的 try_files 或 Fallback 规则）。
- 兼容性略差：依赖 HTML5 History API，不支持 IE9 及以下浏览器。