Skip to content

面试经验分享-真题-答案

记录

总结一下聊的问题:

  1. vue 路由的有哪几种模式,优缺点
  2. vue 虚拟 DOM,优缺点
  3. cookie localStorage sessionStorage 跨域
  4. 上家、过往公司离职原因
  5. 是否用过 uniapp
  6. 介绍公司项目,有没有做过移动端
  7. 期望薪资多少
  8. 多久可以到岗

反问技术:

  1. 技术团队(所用技术)

了解技术栈是否和自己匹配,团队规模人员配置情况

  1. 对候选人的期望,想要找一个什么样的人

看看自己是否符合公司要求

Vue 路由问题

vue 路由都有几种模式

Vue 路由有三种模式,分别是:

  • hash 模式:在 URL 中使用 # 符号作为路由地址的前缀。在这种模式下,当 URL 发生改变时,页面不会重新加载,而是将 # 后面的部分作为参数,通过监听浏览器的 hashchange 事件来更新页面内容。这种模式不需要服务端支持。

  • history 模式:在 URL 中不使用 # 符号,而是使用普通的 URL 地址。在这种模式下,当 URL 发生改变时,Vue Router 会尝试通过浏览器的 history.pushState 和 history.replaceState 方法修改浏览器的历史记录,从而在不刷新页面的情况下更新页面内容。需要注意的是,使用 history 模式需要服务器配置支持类似的请求路径,并返回相应的页面。

  • abstract 模式:不依赖浏览器的 URL,而是通过程序控制路由跳转。在这种模式下,可以将路由映射到任意的数据源,比如本地存储、内存数据、服务器接口等。这种模式通常用于服务器渲染、单元测试等场景。

可以通过在 Vue Router 的配置中设置 mode 属性来切换路由模式。默认情况下,Vue Router 使用 hash 模式。

Vue 路由有三种模式的区别

Vue 路由提供了三种模式:hash 模式、history 模式和 abstract 模式。它们的区别如下:

  • hash 模式

    在 URL 中使用 # 符号作为路由地址的前缀,例如:http://localhost:8080/#/home。当 URL 发生变化时,页面不会重新加载,而是通过监听浏览器的 hashchange 事件来更新页面内容。这种模式不需要服务端支持,可以轻松实现前端路由。在 hash 模式下,如果出现了 404 错误,会默认显示路由器中的路由。

  • history 模式

    在 URL 中不使用 # 符号,而是使用普通的 URL 地址。在这种模式下,当 URL 发生改变时,页面不会重新加载,而是使用 HTML5 History API(pushState 和 replaceState 方法)在不刷新页面的情况下更新页面内容。这种模式需要服务端支持,因为在 history 模式下,浏览器发送的是真正的 HTTP 请求,服务器需要配置支持类似的请求路径,并返回相应的页面。如果服务器没有配置对应的路由规则,则会返回 404 错误。为了解决这个问题,可以使用 vue-router 提供的 history 模式的 Fallback 机制来处理路由的 404 错误。

  • abstract 模式

    不依赖浏览器的 URL,而是通过程序控制路由跳转。可以将路由映射到任意的数据源,比如本地存储、内存数据、服务器接口等。这种模式通常用于服务器渲染、单元测试等场景。

在选择路由模式时,需要根据项目的实际情况来选择。如果项目需要兼容较老的浏览器,或者后端不支持 URL 重写,可以选择使用 hash 模式;如果需要更加优秀的用户体验,可以使用 history 模式;如果需要在一些特殊场景下使用路由,可以选择使用 abstract 模式。

hash 模式和 history 模式的优缺点

hash 模式和 history 模式都有各自的优缺点。

  1. hash 模式

优点:

  • 兼容性好,支持在所有现代浏览器和较老的浏览器上使用。
  • 不需要服务端支持,可以轻松实现前端路由。
  • URL 中的 hash 值可以用于保存页面状态,便于页面的前进、后退和分享等操作。

缺点:

  • URL 中带有 # 符号,不美观。
  • 对于搜索引擎来说,URL 中的 # 后面的内容不被当作是 URL 的一部分,搜索引擎无法获取到其中的内容,对于 SEO 不友好。
  • 如果出现 404 错误,默认情况下会显示路由器中的路由。
  1. history 模式

优点:

  • URL 更加美观,不带有 # 符号。
  • 对于搜索引擎来说,URL 中的内容完全被认为是 URL 的一部分,有利于 SEO。
  • 可以通过服务器端配置实现前端路由,便于在服务端处理路由相关的逻辑。

缺点:

  • 兼容性差,不支持在较老的浏览器上使用,需要使用 polyfill 进行兼容。
  • 需要服务器端支持 URL 重写,否则会出现 404 错误。
  • URL 中不带有 # 符号,如果在页面刷新时,浏览器向服务器发送请求,可能会导致 404 错误。

需要根据项目的实际情况来选择使用哪种路由模式。如果项目需要兼容较老的浏览器,或者后端不支持 URL 重写,可以选择使用 hash 模式;如果需要更加优秀的用户体验,可以使用 history 模式。


abstract 模式 优缺点

abstract 模式是 Vue Router 提供的一种不依赖浏览器 URL 的路由模式,可以将路由映射到任意的数据源,比如本地存储、内存数据、服务器接口等。abstract 模式的优缺点如下:

优点:

  • 不依赖浏览器 URL,可以在不同的数据源之间自由切换,灵活性高。
  • 不需要服务端支持,可以轻松实现前端路由。
  • 可以通过程序控制路由跳转,可以自定义路由的行为,比如跳转前进行数据加载等操作。

缺点:

  • 不支持浏览器的前进和后退操作,需要自行实现历史记录和状态管理的逻辑。
  • 对于搜索引擎来说,无法获取到 URL 中的内容,对于 SEO 不友好。
  • 如果使用内存数据存储路由,当页面刷新时,路由信息会丢失。

需要根据项目的实际情况来选择使用哪种路由模式。abstract 模式通常用于服务器渲染、单元测试等场景。在这些场景下,不需要浏览器 URL 和前进后退功能,而是需要灵活控制路由的跳转行为。

三种路由模式的原理,详细一点

Vue Router 支持三种路由模式:hash 模式、history 模式和 abstract 模式。它们的原理如下:

1. hash 模式

hash 模式是 Vue Router 默认的路由模式,通过 URL 中的 # 符号来模拟一个完整的 URL,实际上 URL 中的 # 符号后面的内容被称为 hash(或哈希)值,用于指示浏览器在当前页面中的不同部分之间切换。例如,URL http://example.com/#/home 中的 /home 部分就是 hash 值,表示要访问的页面是 home。

hash 模式的原理是,在页面加载时,Vue Router 会监听浏览器的 hashchange 事件,当 URL 中的 hash 值发生改变时,Vue Router 会解析新的 hash 值,并根据配置的路由规则来匹配对应的组件,最终将渲染结果显示在页面中。因为 hash 值的改变不会导致页面的重新加载,所以使用 hash 模式可以实现单页应用(SPA)的效果。

2. history 模式

history 模式通过修改 URL 中的路径来实现路由,例如 http://example.com/home,其中 /home 部分表示要访问的页面是 home。在使用 history 模式时,需要注意的是,服务器需要进行相应的配置,将所有的路径都指向同一个 HTML 文件,以避免在用户直接访问路径时出现 404 错误。

history 模式的原理是,在页面加载时,Vue Router 会监听浏览器的 popstate 事件,当 URL 中的路径发生改变时,Vue Router 会解析新的路径,并根据配置的路由规则来匹配对应的组件,最终将渲染结果显示在页面中。因为 history 模式需要服务器的支持,所以它更适合用于传统的多页应用。

3. abstract 模式

abstract 模式是一种不依赖浏览器 URL 的路由模式,可以将路由映射到任意的数据源,比如本地存储、内存数据、服务器接口等。在使用 abstract 模式时,需要自行实现路由信息的管理和状态的保存,包括前进和后退、路由跳转、路由钩子等功能。

abstract 模式的原理是,在页面加载时,Vue Router 会通过程序调用来加载路由信息,然后根据路由信息来匹配对应的路由组件,最终将渲染结果显示在页面中。因为 abstract 模式不依赖于浏览器 URL,所以它更适合用于服务器渲染、单元测试等场景。

跨域问题

wenku.badiu.com``tieba.baidu.com 他们之间是否可以直接获取 localStorage、sessionStorage 里面的数据

localStorage 和 sessionStorage 存储的数据都是基于同源策略的,也就是说,只有在同一个源(protocol + hostname + port)下的页面之间才可以共享 localStorage 和 sessionStorage 中的数据,不同源的页面是不能直接访问另一个源的 localStorage 和 sessionStorage 中的数据的,即使是百度的不同子域名下的页面也是不能直接访问的。

在你提到的这两个网站中,wenku.baidu.com 和 tieba.baidu.com 是不同的子域名,它们的源是不同的,因此它们之间不能直接获取 localStorage 和 sessionStorage 中的数据。如果需要让它们之间共享数据,可以使用跨文档消息或者后端接口的方式。

你提到了“可以使用跨文档消息或者后端接口的方式” 可以详细展开讲讲“跨文档消息” 怎么做吗

你提到了“可以使用跨文档消息或者后端接口的方式” 可以详细展开讲讲“跨文档消息” 怎么做吗

当需要在不同源的页面之间进行数据传递时,可以使用跨文档消息(Cross-document messaging),它是一种基于 postMessage API 实现的跨源通信技术,可以让不同源的页面之间进行安全的通信。

跨文档消息的基本原理是,通过 window.postMessage 方法向目标窗口发送消息,然后在目标窗口中监听 message 事件接收消息,从而实现不同窗口之间的通信。下面是一个基本的跨文档消息示例:

在父窗口中:

javascript
// 获取目标窗口的引用
var iframe = document.getElementById('target-iframe').contentWindow;

// 发送消息给目标窗口
iframe.postMessage('Hello, target window!', 'https://target.com');

在子窗口中:

javascript
// 监听message事件
window.addEventListener('message', function (event) {
  // 判断消息来源是否为指定的源
  if (event.origin === 'https://source.com') {
    // 接收并处理消息
    console.log('Received message:', event.data);
  }
});

上面的代码中,父窗口中的 iframe 元素代表了目标窗口,通过 contentWindow 属性获取到目标窗口的引用,然后调用 postMessage 方法向目标窗口发送消息。在目标窗口中,通过 addEventListener 方法监听 message 事件,并在事件处理函数中接收并处理消息。

需要注意的是,在实际应用中,需要对目标窗口的源进行验证,确保消息的来源是可信的,以防止恶意攻击。

不是 iframe 可以吗,如何在两个浏览器页签之间发送和接收数据

是的,不仅可以在 iframe 之间使用跨文档消息进行通信,也可以在两个浏览器页签之间使用跨文档消息进行通信。

跨文档消息的基本原理是通过 window.postMessage 方法向目标窗口发送消息,然后在目标窗口中监听 message 事件接收消息。不同浏览器页签之间的通信过程与在同一窗口的不同 iframe 之间通信的过程类似,不过需要在消息发送时指定目标窗口的 url 地址。

下面是一个在两个浏览器页签之间发送和接收消息的示例:

在发送消息的页面中:

javascript
// 获取目标窗口的引用
var targetWindow = window.open('https://example.com', 'targetWindow');

// 发送消息给目标窗口
targetWindow.postMessage('Hello, target window!', 'https://example.com');

在接收消息的页面中:

javascript
// 监听message事件
window.addEventListener('message', function (event) {
  // 判断消息来源是否为指定的源
  if (event.origin === 'https://source.com') {
    // 接收并处理消息
    console.log('Received message:', event.data);
  }
});

在发送消息的页面中,使用 window.open 方法打开一个新窗口,然后调用 postMessage 方法向该窗口发送消息。在接收消息的页面中,使用 addEventListener 方法监听 message 事件,并在事件处理函数中接收并处理消息。需要注意的是,在实际应用中,需要对目标窗口的源进行验证,确保消息的来源是可信的,以防止恶意攻击。

webku.baidu.com/index.html``webku.baidu.com/user.html user.html 是否可以获取 index.html 存储的 localStorage 里面的数据

如果 webku.baidu.com/index.html 和 webku.baidu.com/user.html 是同源页面,即它们的协议、主机名和端口号都相同,那么 user.html 页面是可以访问 index.html 存储在 localStorage 中的数据的。

在同源页面中,不同页面之间可以共享 localStorage 和 sessionStorage 存储的数据。当然,如果 localStorage 中存储的数据是经过加密处理的,那么即使在同源页面中也不能轻易地访问和解密这些数据。

需要注意的是,如果 webku.baidu.com/index.html 和 webku.baidu.com/user.html 不是同源页面,那么由于浏览器的同源策略限制,user.html 将无法访问 index.html 存储在 localStorage 中的数据。在这种情况下,可以使用跨文档消息或者后端接口的方式进行数据传递。