hash和history模式

hash模式

Hash 模式是一种在 URL 中使用哈希（#）来管理路由的前端路由模式。例如：http://localhost:9028/#/enter-park

当使用 Hash 模式时，URL 中的哈希部分（#）后面的内容被称为哈希值。哈希值的变化不会触发浏览器向服务器发送请求，因此路由的切换是在前端完成的，不会引起页面的刷新。

为什么说hash值的变化不会触发浏览器向服务器发送请求？

hash值的变化仅仅是前端路由的变化，并不是页面的请求。当你在前端发起异步请求与后端进行数据交互时，这些请求是通过其他方式（例如 AJAX、Fetch 或 WebSocket）手动发起的，而不是由浏览器根据 URL 变化自动发起的。

总之，hash模式的优势就是避免了全局页面的刷新请求，做到局部手动刷新。弊端见下方chatgpt的回答

history模式

History模式使用浏览器的History API来管理路由状态。它的URL地址不存在（#），使用的是真实的地址。

history模式的工作原理：

1、当用户访问应用程序时，浏览器发送 HTTP 请求到服务器，服务器返回应用程序的主页

2、用户在应用程序内跳转路由，使用History API里面的 pushState 和 replaceState 方法更新路由的URL，但是不会发送HTTP请求。（这里要清楚的是，浏览器不会发送HTTP请求，我们在路由页面的时候是通过手动进行触发的HTTP请求）。

常见的问题之history模式下会出现404报错：

如果服务器没有正确配置的话，访问某个地址或路由就会报错404，这是因为在history模式下，URL的路径会直接映射到服务器的上的文件路径，服务器需要去解析这个路径并返回对应页面的内容。

解决：

为了解决这个问题需要在服务器上进行正确的配置，确保所有路径都返回应用程序的主页（通常是 index.html），然后由前端的 Router 接管路由的解析和渲染。

Nginx下的配置：

location / { try_files $uri $uri/ /index.html; }

为什么hash模式下不会发生404的错误呢？

URL 中的哈希部分（#后面的内容）不会被发送到服务器端，而是完全由前端进行处理。这是因为在 hash 模式下，URL 中的哈希部分被视为客户端的内部状态，用于前端路由的实现，而不是真正的服务器路由。

当使用hash模式的时候，所有的路由请求不会向服务器获取资源，所以也不会发生404的错误。当切换路由时，只是通过监听浏览器的 hashchange 事件来更新页面的视图组件，而不会触发对服务器的请求。但是他里面的静态资源还是会向服务器发送资源请求，获取静态资源，与当前路由的哈希部分无关。

优点：
Hash模式的缺点就是history模式的优点。