本系列本章是一系列面试方法论和思路的汇总，立意是以更加真实更加切中面试官考察思路的方式进行面试，同时能够给校招面试者一些快速提升技术能力的思路。 前文：
非典型面经（二）：面试官问的都是我不擅长的问题怎么办？ 前文已经讲过了练手项目的复盘思路和面试中的一些话术，本文以实际演练的角度来实操一下。
项目示例
还是以老生常谈的音乐界面为例，点击访问线上页面：
前文发布后有些同学有私信我希望能按照我的方式来部署自己的练手项目，这里我把项目放出来，仓库地址，顺手做了一个一键部署。
感兴趣的同学也可以基于这个项目去穷尽一下自己的前端知识，按照前两篇文章给出的思路，做一些自己的修改和优化，把它变成自己的项目，对自己的能力也是一种锻炼。
开始面试
Q: 我们面试开始，请先介绍一下你自己。
A: 面试官你好，我叫 xxx，毕业自 xxx，专业 xxx，毕业时间 xxx。
我的项目经历有：仿 QQ 音乐前端项目、B 项目 两个项目。
我在项目中分别扮演了 xxx 角色，在仿 QQ 音乐前端项目中我主导了项目的开发，负责了【技术选型、架构设计、代码开发、工程化建设、性能优化、复杂功能开发】中的一项或者多项。 【针对一项展开陈述】在性能优化这一块，我做了 xxx、xxx、xxx 措施，对性能的提升达到 xx%。
实习经历有c、d，在实习中我做了 xxx 项目，实现了 xxx 功能，【此处展开陈述也可以参考项目陈述】。
很高兴能接到这次面试的机会【巴拉巴拉客套两句自我介绍结束】。
八股文
问八股文的话，回答的时候可以把八股文和项目联系到一起来。
Q：JS 的闭包你了解吗？
A-1：了解的，一个函数和对其周围状态的引用捆绑在一起，这样的组合就是闭包，闭包通常可以用来创建私有变量。 【A-1 这样回答就把话头给回了面试官，面试官要么继续深入问闭包相关的基础知识，要么问别的问题了。】
A-2: 了解的，一个函数和对其周围状态的引用捆绑在一起，这样的组合就是闭包，闭包通常可以用来创建私有变量，用于规避 JS 中存在的变量污染问题。
在仿 QQ 音乐的这个项目里，我有多次应用到闭包这个特性，例如在搜索音乐这个功能里，为了减少接口调用频率，保证搜索结果的正确性，使用了防抖函数，我使用闭包实现了防抖。 【面试官听到 A-2 这样的回答，至少知道你不是背的答案，而是有实际应用而且有一定的理解，但是掌握程度如何还需要挖掘。】
Q：你为什么用闭包来实现防抖，不用可以吗？
A：根据防抖的原理，对一个函数需要持有一个 timeoutID 来做清除，对不同的函数，持有的 timeoutID 需要隔离，不用闭包的话，timeoutID 写在全局变量易出现覆盖而导致污染，而临时变量在代码执行完毕之后就会被回收。
当然，不用闭包的话，使用 Class 属性来持有也是一种方式，但是不太符合使用习惯。 【上面的回答体现了你对闭包的深刻理解，再深入一步，聊一下垃圾回收也是很不错的。】
从上面的回答里还是可以引申出很多其他问题的，比如函数作用域的理解、函数上下文的改变等等，这种能提前复习到就最好，一套回答下来没有十五分钟也有二十分钟了。
框架题
Q：你的项目使用的是 vue 框架，你对 mvvm 是怎么理解的？ 【有些同学面经看的比较多，双向绑定都回答得不错】
A: 背面经...Observer...Compiler...Dep 收集...
Q: 能具体讲讲Model to View 和 View to Model对应到你说这几个角色都执行了什么呢？ 【其实是同一个问题，但是很多背面经的同学遇到这个问题会傻眼，其实结合项目来说就很简单】
A: 以我的音乐项目为例，Model to View 可以理解为音乐进度条随着音乐的播放进行更新，当音乐进度变化的时候更新 data，Observer 监听到了数据的变化……【根据 vue 的原理展开来讲】；View to Model 则可以对应到我拖动进度条，从而更新到数据……【讲 vue 怎么收集依赖等等】
当我察觉到面试者在背面经的时候，我就会把同个问题换个问法来问，这个考察的就是理解而非死记硬背了，答案其实是一样的，就看你会不会活学活用到项目中。
有时候面试者会觉得这个问题我回答过的，为什么又问？对自己技术的不自信往往体现着不熟练，所以只要你觉得答案是对的，充满信心地回答出来就好了。
开放题
Q：你刚提到在这个云音乐的项目里，你做了很多性能优化，还达到了一个很不错的效果，能展开说说你做了哪些性能优化吗？【开放题】
很多同学面对这种问题脑子一空，就天南海北地开始一个一个蹦，这种回答很不好过关，除非真的在某个点做的非常精湛，这里我们还是套上一篇文章中给出的思路。
A: 首先我的这个项目在体验的时候遇到了这个瓶颈，首屏加载很慢【问题是什么】
我希望能够做到首屏秒开【目标是什么】 【接下来详细展开实施的步骤】
我首先尝试用 chrome devtools 进行分析，看能不能找到首屏加载慢的原因。按照页面加载的流程，加载慢的原因可能有：服务器原因、网络原因、资源太大、JS 解析卡住等等。
为了确定是哪个环节出现了慢的问题，我先在 devtool 的 network 面板分析了首屏加载的资源和耗时，确定了xxx 加载慢、不必要的资源加载、xxx 资源过大的问题，并且分别采取 xxx 措施进行了解决。 【实施的困难是什么，我是怎么解决的。解决方法可以不复杂，但是思路一定要完整。】
然后我又在 performance 面板抓取了整个页面的渲染流程，发现 js 的执行也比较耗时，耗时的环节在于某个环节出现了阻塞。社区中常见解决这个问题的方式有：方式 A，方式 B，方式 C。
我对这三种方案进行了综合的比对，从稳定度、后续的维护、解决后的体验、和开发成本上进行了取舍和考量，最终确定了 xxx 方案。 【成果测量】
在完成优化之后，我用 performance 工具进行了测量，在同等情况下， 首屏加载耗时减少了 xx%。【如果进一步增加了质量监控、耗时上报来提现这一数据会更加亮眼。】
作者说
本系列已经进展到第三篇，虽然是从我片面的面试和被面试经验中总结出来的一些小经验，但还是希望能够给读者带来一些新鲜的思路，也希望能够给面试者带来更多的信心，找工作平时的积累和面试突击准备都是非常重要的。
