综合面试真题

一、实践题 ★★★

★★★ 实践题

经过二个月“测评项目“开发，测试，上线，”测评项目“服务于学校实施的第一站，参与测评学校的学生上午8点集中开测。市场反馈有如下情况：

1）打开网站出现502

2）登录进不去系统

3）提交数据一致反复

4）有时出现白屏现象

对于市场反馈情况谈谈你的认识？

    首先，502错误，意思是worker忙不过来，参与测评学校的学生上午8点集中开测，在短时间内访问人数过多导致积累了大量的请求，后台服务器忙不过来。解决方法贵公司可以看一下PHP到底在忙些啥，如果是 CPU 密集型计算（应该不会），看看CPU和内存满没满，没满就多开一些worker，满了就多加一些机子。我猜测可能是数据库响应缓慢，然后人多了数据库是否能撑住也是一个考虑，多用一些缓存吧。防流量攻击真没啥好办法，找牛逼一些的机房/CDN 吧。

    第二个问题，结合502报错来看，登录不进系统的原因估计也是短时间内访问人数过多导致服务器崩了。

    提交数据一直反复就相对复杂了，可能出现的使用场景也有很多。
    比如说我们在提交表单的时候，有可能是网络延迟或内存不足，导致点击一次提交按钮，页面没有反应，结果强迫症就犯了，就疯狂的点提交恨不得把手机屏幕点烂来。也有可能是有些毛孩子，点完提交按钮立马点击刷新页面，或直接返回上层页面想卡bug，不为别的，哎~就是玩儿。
    对于这种情况，我以前工作的做法就是设置蒙版层，不管你怎么点，只要你点提交，我就给你弹出蒙版层。其实这个问题最根本的原因是程序没有进行重复判断，导致数据库重复写入。前端后端都可以添加一个重复判断逻辑，判断后台数据库中是否已经存在当前提交的数据，避免重复添加。但是这种判断只解决了两次表单依次提交的问题，如果不同用户同时提交表单，数据就不一定会正确了。这种问题就是我们常说的并发问题，并发问题的解决方案也有很多，比如：加锁排队处理等。

    最后提到解决白屏问题，我个人在白屏优化实践上尝试过SSR、预渲染、还有骨架屏等一些方案，每个方案都个有自己的优劣，需要根据实际的业务场景进行取舍。
    SSR服务端渲染，这个方案可以让页面直接在服务端渲染，但是不利于前后端分离，开发的效率也比客户端渲染低，同时也加大了服务器的压力。而且由于地理位置的不同，不同用户看到的页面也是不一样的，也就是所谓的千人千面，这也为缓存造成了一定困难。
    使用预渲染的话，预渲染插件会在编译阶段就将对应的路由编译好插入到app节点，这样就能在js文件解析过程中有内容展示，js解析完成后，项目使用的单页面应用框架会将app节点内的内容替换成它渲染好的内容。但是当真实访问页面的时候，真实数据可能已经和预渲染的数据有了很大的出入，会导致涉及到一些价格、金额、地理位置的地方甚至会导致用户做出一些错误的决定。
    使用骨架屏的话，实现原理和预加载类似，也可以很好的完善预渲染的不足。但是也存在与业务深度耦合，页面复杂度变高的问题。当应对需求变更时，骨架屏结构成本，工具实现成本，配置成本，项目的维护成本，都比较高。

二、项目中的挑战 ★★★

★★★ 项目开发中有遇到什么挑战没？

1.问题描述：1）简单介绍这个项目规模、背景2）什么情况下遇到什么样的问题

2.你处理这个问题的过程及结果：1）遇到问题你如何思考；2）你如何执行的；3）处理结果如何

3.通过处理这个问题，你学到了什么或者说通过这个问题，你看到了你们什么不足，后续动作（采用什么样的方式，在以后的项目中避免再出现这类问题）

1.（使用缓存处理）
    在做Vue开发移动端APP时，有个页面比较常见，左边是对所有菜谱品类的展示，右边是对对应菜谱的展示，一开始在开发的时候没注意，就直接在mounted()前面使用async,里面使用await调了两边接口后，又通过watch监听了品类索引变化，调了一遍接口。后面发现每次切换品类时，页面都有一闪而过的感觉，发现每次都调了一遍接口，这对性能消耗挺大。所以就尝试的走了Vuex做缓存处理。当时解决这个缓存问题用了一些巧妙的方法，首先缓存的数据，采用的是对象形式，不是数组。这样写起来更快，因为用品类的下标直接做缓存数据的key值，非常好写。不过后面又有点坑，就是我监听的是引用数据类型，不管是vue还是react，引用数据类型发生变化时，页面可能不会更新。后面又在mutation中对vuex中的数据更新时，做了一下深复制，就做好了缓存处理。因为我是根据判断这个对象中有没有数据去调接口的，如果存在，就不调接口。现在做了缓存没错，那如果以后后台的数据发生了变化的话，那我这里也不调接口了，后台数据就没有在页面上实现更新，所以在跳出这个页面的时候还要清下缓存。清缓存要在生命周期结束的时候清，如果碰到了动态组件把APP页面下的 Tap 栏包住的时候， Keep-alive。就不能用 destroyed 生命周期清除，要用 deactivated 生命周期去清除。这样才有始有终，完成缓存处理。

2.（解决关键词高亮问题---->原理和字符串敏感词替换一样，但是用在关键词高亮上算是一个技术亮点吧）
    用户配置一堆关键词，在页面上将这些关键词高亮，也许你会觉得这有什么难度？用正则匹配一下出来高亮不就行了吗？但是，一开始，用户的词不多，我确实使用的是遍历，时间复杂度为n2。后来用户会配置100w量级的词，使用遍历就会使页面卡死崩溃。解决的方法就是：优化性能，高亮分三步，生成字典树，遍历页面文字，取出文字进行匹配。使用字典树代替遍历，整个页面100w量级的词绘制可以实现在1秒以内。

3.（封装自定义组件）
    在一个小程序项目需求中，要求页面头部tab栏切换的同时，对应tab栏品类的页面也要展示出来。你可能会觉得这个需求用个taroUI组件库中的tabs标签页组件不就可以完成吗？但是这个需求想满足用户的沉浸式体验，切换页面时需要有独特丝滑的专场特效。所以当时面临的问题就是，使用的UI库的组件默认样式生硬，满足不了需求。我当时是对小程序原生swiper组件进行了二次封装，主要实现了几点自定义需求：头部Tab栏品类样式使用flex动态布局，实现品类数量可变；使用 slot 插槽来动态渲染 Tab区块中的内容，配合原生swiper组件使用定义插槽；小程序原生组件<swiper>是有默认高度的，必须手动设置其高度，这里使用wx.getSystemInfo来动态获取屏幕尺寸。自己封装组件，踩了不少坑，但从中我学习到了：使用小程序的原生组件，并修改其默认的样式；学会使用 slot 插槽，实现组件内容的差异化；学会了使用小程序原生 api 获取手机信息，用 js 改变组件样式等等

4.（遇到了难用的轮子）
    在写XXX小程序项目中需要实现音频播放的功能，官方已经推荐使用新的API了，然而这个小程序官方文档文档写得并不好，很多时候我们会遇到一些需求，或者改变而这些需求文档里又写得非常模糊，这就比较头疼了。小程序官方文档更新十分频繁，坑非常多。所以很多时候，我就要去不断地从文档的字里行间猜测，并结合源码一步一步地去跟踪，去尝试解决这个音频播放问题。但有时候确实超出了我的能力范围，那么我就会把我的问题提炼成一个小demo，到知乎、segmentfault思否去问，或者提问一些同样用这个轮子的作者，最终找到了新API的使用规范。

注意：这个时候你就要说你最擅长的，一定是你最擅长的点，告诉他这个问题怎么解决，一定是你最懂的，而且经得起推敲的解决方案。你要准备的不仅仅是你的项目中有哪些难点，更重要的是和这个难点相关的知识都要准备充分。所以，你的答案并不是这个项目中最难的点，而是一个最能让你回答好整套相关问题的难点。

三、最难得项目 ★★★ (同上)

★★★ 对哪个项目印象比较深刻深刻，遇到最难的项目是啥？

【同上】

1.问题描述：1）简单介绍这个项目规模、背景2）什么情况下遇到什么样的问题

2.你处理这个问题的过程及结果：1）遇到问题你如何思考；2）你如何执行的；3）处理结果如何

3.通过处理这个问题，你学到了什么或者说通过这个问题，你看到了你们什么不足，后续动作（采用什么样的方式，在以后的项目中避免再出现这类问题）

1.（使用缓存处理）
    在做Vue开发移动端APP时，有个页面比较常见，左边是对所有菜谱品类的展示，右边是对对应菜谱的展示，一开始在开发的时候没注意，就直接在mounted()前面使用async,里面使用await调了两边接口后，又通过watch监听了品类索引变化，调了一遍接口。后面发现每次切换品类时，页面都有一闪而过的感觉，发现每次都调了一遍接口，这对性能消耗挺大。所以就尝试的走了Vuex做缓存处理。当时解决这个缓存问题用了一些巧妙的方法，首先缓存的数据，采用的是对象形式，不是数组。这样写起来更快，因为用品类的下标直接做缓存数据的key值，非常好写。不过后面又有点坑，就是我监听的是引用数据类型，不管是vue还是react，引用数据类型发生变化时，页面可能不会更新。后面又在mutation中对vuex中的数据更新时，做了一下深复制，就做好了缓存处理。因为我是根据判断这个对象中有没有数据去调接口的，如果存在，就不调接口。现在做了缓存没错，那如果以后后台的数据发生了变化的话，那我这里也不调接口了，后台数据就没有在页面上实现更新，所以在跳出这个页面的时候还要清下缓存。清缓存要在生命周期结束的时候清，如果碰到了动态组件把APP页面下的 Tap 栏包住的时候， Keep-alive。就不能用 destroyed 生命周期清除，要用 deactivated 生命周期去清除。这样才有始有终，完成缓存处理。

2.（解决关键词高亮问题---->原理和字符串敏感词替换一样，但是用在关键词高亮上算是一个技术亮点吧）
    用户配置一堆关键词，在页面上将这些关键词高亮，也许你会觉得这有什么难度？用正则匹配一下出来高亮不就行了吗？但是，一开始，用户的词不多，我确实使用的是遍历，时间复杂度为n2。后来用户会配置100w量级的词，使用遍历就会使页面卡死崩溃。解决的方法就是：优化性能，高亮分三步，生成字典树，遍历页面文字，取出文字进行匹配。使用字典树代替遍历，整个页面100w量级的词绘制可以实现在1秒以内。

3.（封装自定义组件）
    在一个小程序项目需求中，要求页面头部tab栏切换的同时，对应tab栏品类的页面也要展示出来。你可能会觉得这个需求用个taroUI组件库中的tabs标签页组件不就可以完成吗？但是这个需求想满足用户的沉浸式体验，切换页面时需要有独特丝滑的专场特效。所以当时面临的问题就是，使用的UI库的组件默认样式生硬，满足不了需求。我当时是对小程序原生swiper组件进行了二次封装，主要实现了几点自定义需求：头部Tab栏品类样式使用flex动态布局，实现品类数量可变；使用 slot 插槽来动态渲染 Tab区块中的内容，配合原生swiper组件使用定义插槽；小程序原生组件<swiper>是有默认高度的，必须手动设置其高度，这里使用wx.getSystemInfo来动态获取屏幕尺寸。自己封装组件，踩了不少坑，但从中我学习到了：使用小程序的原生组件，并修改其默认的样式；学会使用 slot 插槽，实现组件内容的差异化；学会了使用小程序原生 api 获取手机信息，用 js 改变组件样式等等

4.（遇到了难用的轮子）
    在写XXX小程序项目中需要实现音频播放的功能，官方已经推荐使用新的API了，然而这个小程序官方文档文档写得并不好，很多时候我们会遇到一些需求，或者改变而这些需求文档里又写得非常模糊，这就比较头疼了。小程序官方文档更新十分频繁，坑非常多。所以很多时候，我就要去不断地从文档的字里行间猜测，并结合源码一步一步地去跟踪，去尝试解决这个音频播放问题。但有时候确实超出了我的能力范围，那么我就会把我的问题提炼成一个小demo，到知乎、segmentfault思否去问，或者提问一些同样用这个轮子的作者，最终找到了新API的使用规范。

四、前端扮演的角色 ★★★

★★★ 项目研发流程中作为前端开发一般扮演的啥角色？

    前端开发一般扮演着一个“团队核心废物”的角色。为什么这么说，首先在项目的研发中，UI小姐姐总感觉前端开发的页面满足不了她们的设计理念，说你没品味；后端小哥哥觉得前端开发就像只会写写样式的js交互工程师，像极了一个破美工的；测试小哥哥拿着测试报告说：这锅谁他娘的来背一下。还记得当年那个请你根据手机壳的颜色，来实现APP启动的颜色的产品经理嘛？这些对前端开发的误会难道不能折射出前端是团队里最应该学会沟通的人嘛？
    界面有问题需要和UI沟通,数据有问题需要和后台沟通,功能有问题需要和产品沟通,测试的时候给你提bug你还需要和测试沟通……毕竟前端是最接近用户的人,用户对一个网站,软件最直观的感受是反映到前端；交互体验更是前端项目的核心点。
    和UI的沟通,在工作中我们不应该是被动的实现UI的设计,而是应该合理化的提出自己的想法,不然日后返工浪费的是双方的时间。比如通用组件的设计，每次页面的提示弹窗设计，再比如你需要做一个图表,用到了echarts,你完全可以让UI基于echarts去设计样式,而不是让她在那里自由发挥，因为你永远不知道设计师的脑子里装了多少创意,这样节省的是两个人的时间,不会出现他做好样式而你实现不了的尴尬。
    和后端联调接口前，先要对业务需求了解透彻，需要哪些数据，有时候明明后台来处理某个事件很简单,后台非要你来做,这就需要我们对一个需求,一个任务的要有清晰认识了,如果对任务含糊不清,自己都没搞明白,你只能受后台摆布了.最后可能也会因为任务没有完成而备受责难了。有理有据,后台开发人员是不会说什么的,否则,后台会很不耐烦的,甚至骂你的可能都有,本身做后台比较难,尤其在查询数据,取数据,封装数据方面都比较难处理。
    面对产品经理的需求，前端应该深刻理解需求，毕竟工作性质影响了一个人的思维逻辑，前端能站在一个产品经理的角度去思考每一个需求，便显得尤其重要。不放过每一个细节也很重要。产品经理在设计一个产品的时候，都是从大方向去想问题的，大方向没有错就行了，细节脱离不了大方向。这是他们想的。但是对于程序来说，却万万不能。因为一个细节的逻辑往往决定了整个大方向。
    举个例子：有一个需求，用户的作品需要提交审核，经过审核才可以让所有人看到。当产品经理交这个需求给你的时候，你能察觉到什么问题了吗？这里面有几个细节：1.用户提交审核后，用户可以不可以再编辑作品；2.作品是否会多次审核；3.需不需要记录审核历史；4.用户作品是否需要有版本的控制，如要产生版本，版本又是如何产生的；5.审核通过后，用户可以不可以再修改作品，若不可以，那么是不是其他人就看不见用户作品等等。
    我认为前端开发是团队里最应该学会沟通的人，一个好的前端开发模式可以推动整个项目的进步的，尽管有时可能会被误解成废物，但是这何尝不是大家公认的核心呢？

五、项目有啥优化 ★★★

★★★ 现在有的项目中觉得哪些项目可以继续优化，为啥没有优化？

    之前用vue做了一个动态官网项目，后期客户要求seo，百度上之前搜索不到官网地址，后来在项目的入口文件index.html页面加上了，固定的meta标签，加上name名为keywords、description的meta标签。以上做了个简单的seo优化，这个项目有几个官网，但是其中只有一个官网要求seo，也就是在百度能够搜索到，当时为了应急，就写死了，但是，其它的网站也就会受到干扰了，也就是对于一个项目对应几个官网，写死的meta标签做seo是不科学的。
    如果这个项目要解决seo优化，可以用服务端渲染（ssr），如果项目刚开始就考虑到seo，采用服务端渲染，那么就用服务端渲染就得了。但是一般来讲，项目做到后期才会考虑到seo的问题，这时再去搞服务端渲染，相当于重头写项目，非常耗费人力物力。
    所以先只考虑在首页加入 meta 标签提供一些元数据，使用简单、具有表意性的 title 以及使用 h5 提供的具有语义化的标签（不要一堆 div），生成对 search engine 友好的 sitemap，使用合理的 html 结构（比如按标题、内容、页脚这样的顺序、或者将重要的内容放在 html 前，其他放在后）

六、总结过项目吗？★★★

★★★ 平时写项目总结么，一般总结哪些东西？

    平时在写项目的时候，会写项目总结，常常会遇到什么技术难点后，先用自己积累的知识点去尝试解决，如果遇到不会的，我就会在网上查看文档，通过翻阅资料解决问题。在解决问题后，一般我会将我认为有坑的地方记录下来。
    比如，最近我做的一个比较有特点的项目，用的是 React + taro + koa框架，完成类似听书小程序。里面有个书城页面，是自己封装了品类筛选的组件。用的是小程序 scroll-view 的原生API，这里面有好多个坑，首先他有一个API，是scrollintoView,这个API的值不能数字开头，但是后端给的数字一般都是id，数字嘛。这只能自己把后端传的数字处理成string类型。最后还有一个样式的坑，你一定要按照官方文档中给的CSS样式来，给scroll-wrap加上white-space：nowrap和宽度百分百，才能实现滚动的效果。
    除了总结遇到的问题，还会总结一下自己负责模块的一些规范，比如打包技术，图片的使用，自己使用了那些UI库的组件实现了什么具体的功能。自己负责的模块中联调了哪些接口。最后总结下大概完成了哪些需求。

七、持续学习么？★★★

★★★ 工作中能够持续学习么？

    工作中当然可以持续学习，我认为每次对自己的总结就是很好学习机会，可以是工作上的总结，生活上的总结，某一件小事的总结都可以学习。
    总结自己掌握的前端知识体系，总结知识体系的过程是一个查缺补漏的过程。遇到没掌握或者了解不深的知识点，务必去了解、搞清楚，否则就不算掌握。还可以，总结自己做过的项目中有哪些难点，或者技术架构。涉及到的所有技术点都可以挖一下，看看有没有某个点是自己描述不清的。
    有空闲时间，会去leetcode社区上找点算法题，可以去bestofjs社区看看社区又出了什么比较前沿的技术，框架 。还可以去Git上看看别人写的代码，或者翻翻Vue，React源码研究研究。

八、学习动力 ★★★

★★★ 学习的动力怎么来的，如何维持？

    我对前端开发学习动力来自对解决问题的成就感，这一个过程，是让人享受的。比如刚步入前端的时候，当我刚学会怎么使用css属性，去给静态页面添加旋转，缩放，背景颜色渐变的时候，那时候满脑子都是花里花哨的效果，在练习的demo中，一些地方本来朴实无华，但我偏偏想用用动画，渐变去玩一玩。后面学到用js操作dom元素，自己玩玩计时器，页面上能玩的更花里胡哨了，就感觉非常舒服。在又学会了jq,ajax配合表单的使用，向后端传递数据时，感觉就非常到位。慢慢就觉得前端开发非常有成就感。现在前端开发，知识体系庞大，各种框架组件，组件写法百花齐放，这难道不是一种让人兴奋的事嘛？我在工作中不但可以做着让人兴奋的事，还可以拿工资，这难道不舒服嘛？

九、未来规划 ★★★★

★★★★ 未来会有什么样的规划？

    我近期的规划首先先把咱们公司的项目做好。另外夯实我自己的技术，多学一些组件、插件，再多学一到两个框架。
    这是我近期的规划，对于中长期的规划。我打算将来我研究研究Vue，react，源码。深入了解一下前端工程化和实践，我会持续关注业界的新话题和新技术，并锻炼一下自己进行项目或者业务的技术选型的能力，尝试制定前端的技术规范，制定文档。前段时间也研究过一下webpack，用webpack自己手动搭建了一个React脚手架，把以前工作写的后台管理系统重新在在自己搭的脚手架中简单的跑了一下。我觉得这让我对前端工程化思想有很大的帮助。所以未来希望自己的技术水平能再上一个台阶，也为了更好的为我们公司服务。

十、你对加班的看法 ★★★★

★★★★ 对于加班你是怎么看的？

    现在每个行业都竞争激烈。企业要想在竞争中占据主动地位，就必须付出更多的努力。比如华为提倡的奋斗者精神。所以我认为正常的加班是可以理解的，如果是工作需要，我会义不容辞的加班。我现在单身，没有任何的家庭负担，可以全身心的投入工作，但是同时，我会提升工作效率，不至于存在加班很严重的情况。如果公司遇到了紧急的任务，我肯定是全力配合公司来完成。

十一、学习前端的历程 ★★★

★★★ 说下你学习前端的历程吧？

【按照个人简历上历程的来回答，不穿帮即可】

十二、前端的未来 ★★★

★★★ 前端未来展望？

    看好，非常看好。很多人以为，前端入门门槛比较低，随便学学HTML,CSS就能只做网页，随便网上看看教程，看几本书就能学会了。这样的话，岂不是随便在家看看，就能入职前端开发工程师了？那当然不是，前端虽然入门容易，但是越往后学的越慢。很多人只是看一点点基础，随便学点东西，只会一点点皮毛就不再深入拓展。那这样的人，市场当然早就饱和了。其实每个行业都是这样，金字塔原理，顶尖的人群可能只占百分之几，而下面的百分之八十，可能都是往这个门里挤的人。这之中，能力强的挤上去了，而能力不足又不努力的，只能被拒之门外。在未来，专业的前端开发工程师才是企业真正争夺的香饽饽。而被淘汰的不是前端开发，而是淘汰技术落后和技术不精的开发者。③关于这个行业的未来刚刚也有提到过，这个行业正处于一个高速发展的阶段，短期内还看不到任何衰退的迹象。随着前端的不断发展，移动端应用、小程序、H5游戏等全新产品的出现，前端开发应用场景不断拓展。走向更专业和工程化的发展。前端还有太多的道路没有探索，没有挖掘，很难判断前端没有现在火的时候行业会怎么样。
    前端工程师面向的范围很广，学习的知识也很广泛。不过，要想成为全栈工程师，还是有很长一段距离的，有很多全新知识需要学习。会不会变成全栈工程师，可能更多跟你自己的想法相关吧。不成为全栈工程师，做专一的前端开发工作，也不是不行。

十三、前端的发展 ★★★ (同上)

★★★ 你看好前端发展吗？

【同上】

    看好，非常看好。很多人以为，前端入门门槛比较低，随便学学HTML,CSS就能只做网页，随便网上看看教程，看几本书就能学会了。这样的话，岂不是随便在家看看，就能入职前端开发工程师了？那当然不是，前端虽然入门容易，但是越往后学的越慢。很多人只是看一点点基础，随便学点东西，只会一点点皮毛就不再深入拓展。那这样的人，市场当然早就饱和了。其实每个行业都是这样，金字塔原理，顶尖的人群可能只占百分之几，而下面的百分之八十，可能都是往这个门里挤的人。这之中，能力强的挤上去了，而能力不足又不努力的，只能被拒之门外。在未来，专业的前端开发工程师才是企业真正争夺的香饽饽。而被淘汰的不是前端开发，而是淘汰技术落后和技术不精的开发者。③关于这个行业的未来刚刚也有提到过，这个行业正处于一个高速发展的阶段，短期内还看不到任何衰退的迹象。随着前端的不断发展，移动端应用、小程序、H5游戏等全新产品的出现，前端开发应用场景不断拓展。走向更专业和工程化的发展。前端还有太多的道路没有探索，没有挖掘，很难判断前端没有现在火的时候行业会怎么样。
    前端工程师面向的范围很广，学习的知识也很广泛。不过，要想成为全栈工程师，还是有很长一段距离的，有很多全新知识需要学习。会不会变成全栈工程师，可能更多跟你自己的想法相关吧。不成为全栈工程师，做专一的前端开发工作，也不是不行。

十四、登录的流程 ★★★

★★★ 请简单绘制登录场景的业务流程图，如不熟悉登录业务，也可以选择自己之前项目的业务简单说明。

React做的后台管理系统的登录。【鉴权，不同角色的权限管理】

十五、项目上线 ★★★

修改配置文件，把默认首页从index.html改成5ox.html就可以了。

十六、项目流程 ★★★

★★★ 项目中由谁定接口，公司文档如何管理，由谁负责上传代码，怎么上传代码的，项目发布都是怎么做的？

    首先，接口文档不应以前端作为主导方提出，而是由服务端进行接口文档的编写工作，在编写完成后，和前端一起协商补充，这样做是最好的。前端只负责数据的展示，所以没必要由前端进行接口定义，因为服务端的逻辑处理如果完全按照前端提出的来，那还咋设计。。最重要的是沟通，并且熟悉业务逻辑。
    公司文档，
    项目上传由运维上传，
    。。。

十七、前端工程师区别 ★★★

★★★ 请你说说高级前端工程师和初级以及中级有什么区别？

    初级前端工程师：能熟练使用HTML、CSS、JS主要工作还是搭建静态页面。一套代码能适配PC+手机端。以外，还需要会使用一些框架之类的东西，像bootstrap、jquery之类的。会ajax了解怎么与后台交互是学习Ajax的关键点。

    中级前端工程师：首先就是前端工程化有一定的了解，框架angular、vue、react 。那它和jquery有着很大区别。vue是数据控制页面渲染及状态，而jquery是DOM节点控制渲染，vue渲染页面更容易更优雅。vue能够把前端项目彻底工程化，有配置文件、可以安装第三方模块、配合webpack打包、可以实现模块化开发..等等，当然简单是它最大的优势。熟练es6 7 语法、vuex、Element_ui （开发pc端框架）、vux（开发手机端框架）、Mint UI（开发手机端框架）、Nodejs（后端语言，js语法）。

    高级前端工程师：要求编写的模块更具有可复用性，不用怎么修改，后续要加新功能时，也不需要改动原有代码，就能让项目逐渐的稳定下来。有卓越的技术方案设计和架构能力了。能从原理层面来解决问题。对前端工程化、数据可视化、Webkit、可视化搭建、跨端、移动端动画等领域极为精通。来自于深耕，基本上有什么问题、需求或者技术评审，叫上他们就行。钻研和解决问题的能力。时刻关注业界新动态，能快速研究一项新技术，了解和思考如何应用以及对已有业务的帮助。如何提升体验以及赋能。遇到问题就解决问题，不抱怨。执行力和沟通能力。跨部门、团队协调合作，做一件事情能有始有终做好并且拿到成绩，拿到之后还可以汇报展示出来。

十八、使用 echars ★★★

★★★ 用过echars与highchars么，你遇到哪些问题及如何解决的

    在用React项目中集成过echars图标表，首先引入之后，用window来访问，如果访问成功，就说明安装成功。指的注意的是echars图表初始化实例其实是dom操作，当用React的hooks写法时，这个初始化实例的操作要放在副作用里，就是用useEffect包起来，不然的话就影响性能。有时候还要注意样式，如果不给，图表就会没有高度，就不会显示出来。一般是从后端动态数据，先做一层处理，在一般是叫 options 生成器，把后端数据处理成 echars 的规范的数据，在引入到视图展示。还有注意调数据是异步的，所以要确保拿到数据后在显示图表。如果做大量图表，我们就需要封装一个个的 option ，不然数据会非常复杂。我们调接口肯定是走状态管理，一般的做法会使用两个useEffect，一个用来初始化，一个用来触发调接口。因为图表的实例化是dom操作，所以我们还有可以用hooks中useRef这个API去优化一下。
    在工作中也是用过Ant-V，不过大都是看着文档来，思路都是一样的，实在有搞不定的问题，只能面向百度编程了。

十九、使用加密 ★★★

★★ 你写过的项目中有没有使用过加密

    没有使用过加密

二十、包管理工具 ★★★

★★★ 项目开发中是用什么工具来管理代码的；说一下你是用过的工具用法（git、svn）

git包管理工具，加入一个项目组，正式开始开发，一般有以下几个步骤：
1、git clone git@gitlab.com ——使用git clone克隆远程项目到本地，克隆到本地后只有一个分支master
2、git checkout -b test ——本地创建一个test分支并为测试环境代码分支并切换至test，这里根据原项目仓库的测试环境代码分支命名，有些使用dev，这里假定原项目测试环境代码分支为test，测试test分支代码跟master分支代码相同
3、git pull origin test ——拉取远程test分支代码并合并到本地test分支，经过本步操作，本地test分支就是测试环境代码了，以后开发分支的代码都要先合并到test分支推到远程测试环境经过测试后才能进行线上部署
4、git checkout master ——再切回master分支
5、git checkout -b develop-branch ——创建开发分支develop-branch并切换至develop-branch分支，这一步就是要进入开发了，一个需求一个开发分支，直到功能开发完毕
6、git add new_file.php ——把开发过程中新建的文件添加进版本管理
7、git commit -m '备注' ——提交所有变更
8、git checkout test ——切换至测试分支
9、git merge develop-branch ——合并新开发的变更到test分支
10、git push origin test ——test推到远程分支，此时测试环境可以拉取test分支代码，然后进行测试
11、git checkout master && git merge develop-branch ——测试通过后，切换到master分支然后合并develop-branch到master分支
12、git push origin master ——master分支推到远程仓库，进行后续的部署上线

二十一、前后端分离 ★★★

★★★ 谈谈对前后端分离的理解。

    在我看来，前后端分离给开发工作带来了很多好处，在以前，没有这个概念的时候，一种经典的设计模式MVC模式。前端开发很不盛行，几乎很多后端程序员就兼顾了前端开发工作，前后端耦合性极强，在jsp时代，前端写好的页面最后要和后端实现交互，需要程序员手动的更改代码，这是很大的一个工作量，这种事情交给前端还是后端？谁都不愿意做吧！
    前后端分离过后，通过预先定义好接口规范，前端后端独立部署独立开发，后端只需要提供接口供调用即可，解耦效果是真的强，这对工作效率的提升是巨大的，对于后期的维护只需要前后端单独完成即可！
    【可引导拓展至对 MVC、MVVM模式的理解】

二十二、路由跳转 ★★★

★★★ 请你说一下我从A页面路由跳到B页面如何让它不记录路由跳转

this.$router.replace： 跳转到指定url路径，但是history栈中不会有记录，点击返回会跳转到上上个页面 (就是直接替换了当前页面)

二十三、为什么辞职 ★★★★

★★★★ 简单的自我介绍为什么辞职？

    在上一家公司，我也想过要早些辞职，但是考虑某个未完成的重要项目、或是继任者短期内还不能胜任角色所以晚了一些。主要离职的原因是在上一家公司待的时间比较长了，公司的各种业务已经非常熟练了，感觉工作成了流水线般的生产工具，技术达到了一定的瓶颈，我觉得我应该跳出舒适圈去接触更多的新技术与新的业务从而扩展自己的技术广度。我觉得贵公司的技术要求与我非常符合，有一些我自己非常熟练或精通的技术，更重要的事有一些我之前只是自己业余时间研究过但一直没有几乎用于实战的技术。我相信贵公司的岗位对我虽然有一定的挑战信但是会给我带来更多的提升机会。同时我上一家公司中用的React加koa框架做的项目也有很多设计上的亮点，我也可以将上一家优秀完整的项目开发流程与管理经验，项目设计思路与贵公司分享。完成互利互惠共同成长。

二十四、项目负责什么 ★★★

★★★ 讲一下最近的这个项目中都负责什么

    1. 这个项目的列表展示与详情页是我负责的。我对于后端传递的数据进行了怎样的处理，在异步请求中选择了一定的异步分割处理数据，拆分一次性阻塞主线程的时间，可以减少用户的等待，页面滚动时选择节流，减少无效的axios请求等等，对自己模块所负责的内容，进行梳理。

    2. 这个项目的登录，注册，模块是我负责的。我对不同角色的鉴权是怎么实现的。。。

    3. 这个项目的表单提交页是我负责的。。。。用了什么UI组件。。。

    【问法同一、二大题类似，展开自己最拿手的回答即可】

二十五、判断成产、打包 ★★★

★★★ 怎么判断是开发环境生产环境

    在node中，我们有一个对象process对象，它里面包括的一些信息，env和它的一些属性，当然NODE_ENV是我们自己加上去的自定义属性，用来区分环境变量，也就是通过这个变量来进行区别是开发环境还是生产环境；但是有个问题，不同电脑上设置的方式是不一样的，所以cross-env就来了，它可以跨平台设置环境和使用环境变量。

npm install cross-env
我们在webpack.base.conf.js文件中修改代码：

const NODE_ENV=process.env.NODE_ENV;
console.log(NODE_ENV);

    然后我们修改package.json文件：
//--config是可以设置我们执行哪个webpack文件，默认是执行webpack.config.js,但是我们现在修改文件名了，所以我们要设置一下
"build": "cross-env NODE_ENV=production webpack --config webpack.config.prod.js",
"dev": "cross-env NODE_ENV=development webpack-dev-server --config webpack.config.dev.js"

    就这样，我们就实现了利用webpack来区分开发环境和生产环境，当我们用npm run dev运行的时候就是开发环境，当我们运行npm run build的时候就是构建生产环境打包；

综合

目录