这篇分享的起因是昨天在V站刷到一篇帖子，如何用 3–5 个高效问题快速识别 Golang 开发者的技术素养？ 里面提到了我对于八股文面试题的看法。

都要出来面试了，但八股文都不愿意花点时间背，态度很明显就是有问题的，被刷掉也很正常。

从前我也是很讨厌面试时遇到各种八股文面试题，会觉得很无聊和无趣。因为是纯靠背的东西，面试考这些就很蠢。
但是慢慢接触了更多开发者之后，甚至自己面试别人多了之后，就会发现这些看起来很呆板的八股文面试题，其实起到了好几种作用，比如说：

• 筛选不做任何面试准备的面试者；
• 给初级开发在前期建立知识库。

最近没有什么面试经历，上一次面试已经是将近一年前了，所以没办法有效回忆到当时面试的状况。好在近期肉大(@meathill)有在做一个模拟面试的选题，就可以另辟蹊径写一篇旁观其他人面试的文章。

奥利奥同学 是一位能力非常强的前端开发者。最开始了解到他是他在群里分享了自己使用 ThreeJS 开发的一个可交互3D汽车展厅项目 的开发经历，非常吸引眼球并且完成了配套的讲解教程，可以说是非常用心和细致的一个开发者了。

所以这一次我们就来旁观他的一次模拟面试，🏃‍🏃‍🏃‍

面试的时候也算是进场会遇到的一个题目了，结论就是 可以也不可以，看原始数据是什么结构的，也看你如何是操作的。

如果说数组元素是基本类型的，比如说是数字类型、字符串、布尔类型的，那么不管是用 .map() 还是 .forEach() 都是无法修改原数组的。
如果说是集合类型的，比如说数组、对象，那么直接操作内部的元素或者属性都是会修改原数组的。

重排会导致重绘，重绘不会导致重排 。

中文环境下面的 重排 会有另外一种称呼方式叫做 回流。以前一直不理解为什么重排叫回流（直译的 reflow），导致我在记忆的过程中我总是会把他们混在一起，分不清回流是重排还是重绘。

他们对应的含义我倒是分的还是比较清楚的。简单来说就是，牵扯页面布局的页面更新是重排，重绘就只是一些不影响布局的样式更新……

也算是经典面试题的一部分了，对于父子间的通讯很多时候的使用我都是限于 props/$emit 来处理，或者 Vuex/EventBus 这种方式，很少会用到 Provide/Inject 来处理。其实这是一个很实用的跨级组件间通讯的方式。

这对选项需要一起使用，以允许一个祖先组件向其所有子孙后代注入一个依赖，不论组件层次有多深，并在其上下游关系成立的时间里始终生效。

看文档中关于这对API的解释就可以看到，向其所有后代 注入一个依赖，所以在跨级组件间通讯，或者 单父多子组件间通讯就会很方便了。

简单的使用可以查看官方文档中的示例，我就不举例了，因为使用起来真的很简单。

最直白的（但是错误的）可以理解为 props 的强化版本，暴露一个可以无视子组件的嵌套层级属性来进行注入。

一个不幸的消息，最近我厂因为资金的问题凉凉了，所以我得开始重新找工作了，最近应该会分享一些和面试题有关并且我觉得有意思的内容，
😁 正巧今天面试的时候被问到的一个面试题我觉得就挺有意思的题目：

你如何判断一个变量是数组？

因为得知公司要解散的消息后比较仓促，也就没有好好刷面试题直接就出去面了（无缝衔接实属渣男了），所以被问道这还算是比较经典面试题的时候，下意识就回答了使用 typeof 来判断，但是想起来不对啊，数组他是对象类型嘛！

😱 卧槽，踩坑里了。

就马上补充了一句：“emmmm….好像用 typeof 不行，数组返回的是 Object ，应该可以通过原型链上的 constructor 来判断….噢，通过 instanceof 也可以！”

不出意料因为踩坑了，紧接着面试官就追问了一句 “还有其它的方式吗？”
考虑了5秒左右答 “没有了，暂时想不起来更多的方式。”，面试官回：“还有一种 isArray 可以判断”

以前一直没有考虑过这种问题，去判断一个对象是否为数组的场景。所以我觉得就还蛮有意思的，所以回来之后想看看还有哪几种方式可以判断是否为数组。