普通的八股文一大把，我这边只总结我遇到的真实问题。后续有我觉得需要提出来的问题都会放进来更新！

1. 使用 v-html 指令时，有一些需要注意的地方：

潜在的安全风险： 使用 v-html 可能会导致跨站脚本攻击（XSS），因为它会将字符串解析为 HTML。因此，务必确保你信任的内容才能被渲染，或者对内容进行严格的过滤和转义，以防止恶意脚本注入。

性能问题： 使用 v-html 会绕过 Vue 的虚拟 DOM，直接操作真实 DOM。这可能会影响性能，因为 Vue 无法优化这部分代码。只有当你确实需要动态插入 HTML 时才使用 v-html，避免滥用。

不会响应式更新： 与使用模板语法插值不同，使用 v-html 插入的 HTML 不会响应式更新。这意味着如果数据发生变化，v-html 渲染的内容不会自动更新。如果需要内容响应式更新，应该考虑使用模板语法和计算属性等方法。

内容来源可靠性： 当你使用 v-html 渲染动态内容时，一定要确保内容来源可靠。不要直接渲染来自用户输入或外部来源的 HTML 内容，这可能会导致安全漏洞。

总之，使用 v-html 时需要谨慎对待，确保只有信任的内容才能被渲染，并且避免对用户输入或外部来源的内容进行直接渲染。

2. 计算属性（Computed Properties）和过滤器（Filters）的区别

计算属性（Computed Properties）和过滤器（Filters）在 Vue.js 中都是用来处理数据的工具，但它们的用途和实现方式有所不同。

计算属性 (Computed Properties)：
计算属性是基于依赖进行缓存的。
当某个依赖值发生变化时，计算属性会重新计算，但只有在依赖值变化时才会触发计算，否则会使用之前缓存的值。
适合用于对数据进行复杂的计算或者处理，比如对多个数据进行求和、筛选、排序等操作。
计算属性通常定义在 Vue 组件的 computed 选项中。

过滤器 (Filters)：
过滤器用于在模板中对数据进行处理和格式化，但它们不会改变数据本身。
每次重新渲染时，过滤器都会被调用，所以它们不能缓存结果，会导致性能开销较大。
适合用于对单个数据进行简单的格式化、转换或者显示处理，比如格式化日期、字符串截取等。
过滤器通过在插值表达式或 v-bind 指令中使用 | 符号来调用，比如 {{ message | capitalize }}。
过滤器本质上是一个函数，在 Vue 组件中通过 filters 选项进行定义。

总的来说，计算属性适用于对数据进行复杂计算并且需要缓存结果的场景，而过滤器适用于对数据进行简单格式化或者显示处理的场景。

3. nextTick

当你在 Vue 中更新数据时，Vue 并不会立即更新 DOM。相反，它会将 DOM 更新放入队列中，并在合适的时机执行这些更新。而 nextTick 就是用来在 DOM 更新完成后执行回调函数的方法。

通俗来说，就好比你在做一项任务时，你不会立刻去做，而是把它放在待办事项清单里。而 nextTick 就像是一个等待任务完成的标志，告诉你“等一下，任务完成了，你可以继续做下一步了”。

在 Vue 内部，nextTick 会将传入的回调函数放入一个队列中，然后在 DOM 更新完成后执行这个队列里的所有回调函数。这样做的好处是可以确保你在回调函数中访问到更新后的 DOM，而不会出现不一致的情况。

4. 宏任务和微任务
通俗易懂版
想象你是一个忙碌的餐厅服务员，你有两种类型的任务要处理：宏任务和微任务。

宏任务就像是大型任务，比如接受新订单、清理餐桌、或者洗碗。这些任务可能需要一段时间才能完成，因此你会将它们放在一个任务清单上，逐个完成。完成一个宏任务后，你才会考虑处理下一个宏任务。

而微任务就像是小型任务，比如给桌上的客人倒水、询问是否需要续点菜等。这些任务相对来说比较快，而且通常会在处理完一个宏任务后立即执行。微任务的优先级比较高，因为它们可以迅速响应。

在 JavaScript 中，宏任务就是像 setTimeout、setInterval、I/O 操作等异步任务，而微任务则是像 Promise、MutationObserver、process.nextTick 等产生的任务。当主线程执行完当前的任务时，会先处理微任务队列中的任务，然后再处理宏任务队列中的任务，这样可以确保微任务中的操作能够及时更新状态，从而避免出现不一致的情况。

5.节流和防抖
正常的版本听的太多了，我简单的解释一下
节流 = 技能cd，cd结束才可以继续使用。
防抖 = 回城，打断就需要重新回城。

6.当你从列表中的某一项进入详情页后，再返回列表页时，有几种方法可以实现定位到之前浏览的位置：

使用路由参数或状态管理器：
在进入详情页时，记录当前的滚动位置或者题目的索引，可以使用路由参数或者状态管理器（如 Vuex）来保存这个信息。
当你返回列表页时，再根据保存的位置信息，滚动到对应的位置或者高亮显示之前浏览的题目。

利用浏览器的历史记录：
当你点击进入详情页时，可以使用浏览器的 History API 将当前的滚动位置或者题目的索引添加到浏览器的历史记录中。
当你返回列表页时，通过浏览器的历史记录获取之前记录的位置信息，再进行相应的滚动或者高亮显示。

通过路由参数直接传递信息：
在进入详情页时，将当前的滚动位置或者题目的索引通过路由参数直接传递给列表页。
当你返回列表页时，从路由参数中获取之前传递的位置信息，再进行相应的滚动或者高亮显示。

利用浏览器的存储机制：
当你进入详情页时，将当前的滚动位置或者题目的索引存储到浏览器的本地存储（localStorage 或者 sessionStorage）中。
当你返回列表页时，从本地存储中获取之前保存的位置信息，再进行相应的滚动或者高亮显示。
这些方法都可以实现在返回列表页时定位到之前浏览的位置，具体选择哪种方法可以根据你的需求和项目情况来决定。

7. A、B、C端
很多人不太理解 面试中这个专业术语，放到这里科普一下。

在软件开发中，通常使用"A端"、"B端"和"C端"来描述不同的用户角色或者客户端类型。这些术语的含义如下：

A端：
在企业服务或者平台型产品中，通常指的是"供应商"、“服务提供商"或者"内容提供商"等，他们是产品或服务的提供者。
在某些情况下，A端也可以指代"管理员"或者"后台管理人员”，他们负责管理和维护产品或服务。

B端：
通常指的是"商业"、"企业"或者"业务"端，即企业级客户或者商业用户。
B端产品或服务通常针对企业、组织或者商家，提供解决方案、工具或者服务，以满足其特定的业务需求。

C端：
通常指的是"消费者"端，即普通用户或者个人用户。
C端产品或服务通常是面向大众，满足个人日常生活、娱乐、社交等需求。

总的来说，A端、B端和C端用于描述产品或服务的受众群体，分别对应于提供方、企业客户方和普通消费者方

8.http状态码

1xx（信息响应）：
100 Continue：收到请求，客户端应该继续发送请求的其余部分。
101 Switching Protocols：服务器正在切换协议，客户端需要切换到新协议继续通信。

2xx（成功）：
200 OK：请求成功，服务器正常处理并返回所请求的内容。
201 Created：请求已经成功，并且服务器创建了新资源。
204 No Content：请求成功，但是服务器没有返回任何内容。

3xx（重定向）：
301 Moved Permanently：请求的资源已经永久移到新的URL。
302 Found：请求的资源临时移到了新的URL。
304 Not Modified：客户端的缓存资源是最新的，可以直接使用缓存。

4xx（客户端错误）：
400 Bad Request：服务器无法理解客户端的请求，请求语法有误。
403 Forbidden：服务器拒绝了客户端的请求访问资源的权限。
404 Not Found：请求的资源在服务器上不存在。

5xx（服务器错误）：
500 Internal Server Error：服务器在处理请求时发生了意外错误。
503 Service Unavailable：服务器暂时无法处理请求，通常是因为服务器过载或正在进行维护。

9.在选择页面开发技术时，需要考虑到项目的需求、规模、团队技术栈和预算等因素。针对只有1-3个页面的官网类型项目，以下是对Vue、原生（纯HTML、CSS、JavaScript）和服务器渲染（SSR）的适用情况以及成本的简要分析

Vue：
适用于需要交互性强、功能丰富、复杂度较高的页面。
Vue提供了组件化开发的优势，可以更好地管理和组织页面结构。
如果项目未来有扩展需求，Vue可以更方便地进行功能拓展和维护。

就像你在装修房子时选择了一个现代化的装修风格，用了各种新颖的设计和家具。Vue就像是一套先进的装修工具，能够帮助你快速、方便地打造出功能丰富、交互性强的网站。虽然可能有些复杂，但是效果非常好

原生：
适用于简单、静态的页面，且页面内容和功能不需要复杂交互。
原生开发成本低，无需引入额外的框架和工具，适用于小规模项目或者对性能要求较高的项目。

就像你在装修房子时选择了最基本的装修风格，只用了最基础的材料和简单的设计。原生开发就像是用最简单的工具和材料，来构建出简单、朴素的网站。虽然不够华丽，但是简单易懂，适合小规模的项目。

服务器渲染（SSR）：
适用于需要SEO友好、首屏渲染速度快、页面加载性能优秀的项目。
SSR可以在服务器端生成完整的HTML页面，有利于搜索引擎抓取和排名，提升页面的曝光度和访问量。
但是SSR的复杂性相对较高，需要考虑到服务器端渲染的环境和配置，同时可能需要对现有项目进行改造。

就像你在装修房子时选择了一种特殊的装修方式，让房子看起来更加大气、高档。SSR就像是在服务器端提前把网站装修好，然后一次性地呈现给用户。虽然需要更多的准备工作，但是能够让网站更快地加载，更容易被搜索引擎收录。

综上所述，对于只有1-3个页面的官网类型项目，如果需求简单且对性能要求不高，原生开发可能是更轻量级、更直接的选择。如果页面需求较复杂、交互性强，且未来可能有扩展需求，Vue提供了更好的开发体验和组件化管理。而如果项目需要SEO优化和性能优化，SSR可能是更好的选择，尤其是对于需要长期维护和更新的官网项目。

当考虑页面开发技术时，开发成本是一个非常重要的因素。

Vue：
开发成本：中等
Vue提供了丰富的文档、社区支持和开发工具，使得开发人员能够快速上手并高效地开发项目。
使用Vue的成本相对较低，尤其是对于有一定前端开发经验的开发人员来说，学习曲线较为平缓。

原生：
开发成本：低
原生开发不需要引入额外的框架或库，只需使用HTML、CSS和JavaScript即可完成页面开发。
原生开发成本低廉，无需学习额外的技术栈，适合于小团队或者对开发成本有限制的项目。

服务器渲染（SSR）：
开发成本：高
SSR需要考虑到服务器端渲染的环境和配置，以及前后端数据交互等方面的复杂性。
实现SSR可能需要对现有项目进行改造，并且需要了解Node.js等服务器端开发技术，因此开发成本相对较高。

10.vue 在实现登录页面 跳转对应多个入口时 不同源 无法使用cookie的情况下 如何实现

在不同源的情况下，由于浏览器的同源策略限制，无法直接使用Cookie进行跨域通信。在这种情况下，可以考虑以下几种解决思路：

Token-Based认证：
在用户登录成功后，服务器返回一个带有权限信息的Token给客户端。
客户端将Token保存在本地（比如LocalStorage或者SessionStorage）。
在每次需要访问受保护资源时，将Token添加到请求的头部中，发送给服务器进行认证。

这个方案就像是你去商场购物，每次付款时不需要出示身份证，而是用一张特殊的购物卡（Token）来代替。商场只要看到这张卡就知道你是合法顾客，可以放心地给你服务。

单点登录（Single Sign-On, SSO）：
使用SSO解决方案，例如OAuth2.0、OpenID Connect等。
用户在登录成功后，由认证服务器颁发一个令牌（Token），然后可以使用该令牌在不同的应用之间进行认证和授权。

这个方案就像是你在很多不同的网站上都用同一个账号和密码登录，而不需要每个网站都注册新账号。一旦你登录了一个网站，其他网站就能够识别你，让你免去重复登录的麻烦。

代理服务器：
在不同源之间建立一个代理服务器，前端向代理服务器发送请求，代理服务器在后端与不同的源进行通信，然后将结果返回给前端。
前端与代理服务器之间可以通过一些自定义的HTTP头信息进行身份验证，而代理服务器则可以使用合适的方式与其他源进行通信，比如传统的Cookie认证。

这个方案就像是你请了一个中间人代表你去买东西。你告诉中间人你想买什么，中间人帮你去不同的商店购买，然后把东西送回给你。这样你就不需要直接和商店打交道，解决了跨域访问的问题。

跨域资源共享（Cross-Origin Resource Sharing, CORS）：
如果有控制不同源的服务器，可以在服务器端配置CORS，允许特定的源访问资源。
这样客户端发送请求时，浏览器会自动添加一些额外的头信息，服务器会根据这些头信息进行跨域访问控制。

这个方案就像是你在朋友家做客，朋友允许你自由地使用家里的厨房和设备。朋友把家里的厨房开放给你，你可以自由地使用资源，而不需要担心权限问题。

JSONP：
如果是对外提供API的场景，可以考虑使用JSONP来实现跨域请求。
JSONP利用

这个方案就像是你想知道别人的家里有没有某件东西，于是你写了一封信（JSONP请求），给别人的家里（不同域的网站）寄过去。别人收到信后，在回信中带上了你想知道的信息，然后寄给你。虽然不能直接进入别人家里，但是通过这种方式你还是能够获取到信息。

具体选择跨域解决方案确实取决于多种因素。让我们更深入地探讨一下：

项目需求：
如果项目对安全性要求较高，可能需要选择更为安全的跨域解决方案，如Token-Based认证或SSO。
如果项目只是需要简单的跨域访问，可以考虑使用CORS或代理服务器等方案。
技术栈：
如果团队对于某些跨域解决方案有更多的熟悉度和经验，可能会更倾向于选择该方案。
比如，如果团队已经熟悉了OAuth2.0或者OpenID Connect等SSO解决方案，可能会更倾向于使用这些方案来实现跨域登录。
安全考虑：
跨域解决方案需要考虑到安全性，尤其是在跨域通信中涉及到用户身份认证和授权信息时。
需要确保所选方案能够保护用户数据的安全，防止恶意攻击和信息泄露。
可扩展性和维护成本：
需要考虑所选方案的可扩展性和维护成本。
一些方案可能在项目初期实现起来较为简单，但是随着项目的增长和演化，可能会带来更高的维护成本。
因此，需要评估所选方案在长期发展中的可维护性和可扩展性。
总之，跨域解决方案的选择需要综合考虑项目需求、团队技术栈、安全考虑以及可维护性等多个因素，找到最适合当前项目情况的解决方案。

再来几个简单的题，工作久了确实细节忘得比较多
1 多维数组如何拍扁
2 空数组和数组相加