前端项目中遇到的最大问题是什么，该如何回答

Posted 2023-04-11 M-Codes

1 业务简单

由于之前的业务呢，相对来说比较常规，没有遇到太大的困难呢。但是比较期待在今后的工作中遇到一些难题，因为这样才能使我成长

2 业务复杂

不能说的特别简单
uni-app刚出来的时候，官方文档和软件bug很多，没有相关文档告知bug如何解决，

小程序，微信端嵌入html网页跳转链接URL参数丢失问题。解决方法：对URL进行encodeURIComponent()处理。

请求服务：资源加载无效资源
上传视频资源，后台转码，有时候转码成功，有时候转码失败，
各种转码失败，后台转码脚本异步，导致转码成功，而视频为空。

小程序：
问题：图片验证码问题。
描述：图片验证码登录，后端判断验证不成功。
很多开发这都是用小程序的授权登录，而我这项目中需要用账号密码登录，同时使用图片验证码去校验，后端是php返回的图片流，直接插入到wxml中的image.src里面直接显示，图片能清楚显示，无怎么提交后端都返回验证码错误，狗血的是我用postman测试一直能成功登录，放到小程序怎么样都不行。
和后端交流问题，他就截图postman，表示后台系统程序没有问题，直接把锅丢给前端。
小程序端，请求正常，请求数据格式正常，验证码输入正确，后台能返回校验情况，我也真找不到问题。我这边只好测试请求数据的格式，json，form什么的格式都测试了一遍，都不行。图片放到最大，确保验证输入一定正确，无奈，页面上的操作无法解决请求的问题。
再和后端沟通，后端确实有点不耐烦，我叫他返回base64图片试试看，他却说postman请求成功，还用PC端后台登录也是这样用都可以，就不给我返回base64了。
我只好自己瞎搞一下了，拿着请求格式，图片验证码不能成功的问题，去百度，谷歌，360，知乎，博客，前端的群，一起开发的朋友同事，问了一边，翻了一遍，然而都没有对应的问题解决情况，又回头看了小程序请求文档，最终懂没有在这个方向解决这个问题。
为了不影响开发进度，这些纠结解决不了的问题也只好放在一边了。
利用晚上，周末的时间再去找问题解决方法。
解决问题要点：转换问题的思路，了解实现的根本原理。
PC端提交验证图片验证码无误，这个验证码的校验过程是怎么样的？作为前端，很多人都用图片验证码，但估计都不知道这个直接插入html中的验证码，到底是怎么样跟后台校验的。原来这个验证码获取的时候，浏览器会主动保持[‘Set-Cookie’]里面的值PHPSESSID，这个值就是后端加密的图片验证码数字的字符串，在cookie本地，然后提交数据验证的时候后端再取cookie的PHPSESSID解密，校验提交的验证码。是这样的流程。然后上小程序论坛，发现小程序根本不会主动储存[‘Set-Cookie’]，所以后端一直都应该拿不到PHPSESSID，然后的校验肯定是不能成功的。
然后我要手动存储[‘Set-Cookie’]，url就是图片路径，我前端怎么能手动存储[‘Set-Cookie’]？下载图片，去请求中的取header[‘Set-Cookie’]，然后保存起来，提交登录验证把保存的header带上，然后验证成功，问题解决了。
花了好几天的时间
总结：
1.错误思路，方向错误，怎么改都是错。
2.后端不配合，postman请求成功，就不帮忙调试问题了，帮忙调试一下，就知道没有PHPSESSID,那就可以直接知道问题的根处，解决问题的时间可以缩短90%；
3.转换思路，了解原理，配合调试。
4.一般情况，叫后端都可以打印日志看看就好，像我这样搞，都是逼的。

---

拓展

实话实说，都是常规开发，项目还在初级阶段，暂时还没遇到难点

一开始也不太会回答，但是后来想了一下面试官的意图，之后就直接说学校项目其实深度和难度上都不大，但是在碰到某个知识点的时候，我有深入去了解它的源码（原理），巴拉巴拉。

项目经理
可能是项目经理也可能是技术总监，但关注的都是你的学习能力，及项目把控能力，不会像一面那样问些细碎的知识点

最近项目中遇到什么问题，及解决方案？
面试前自己一定要准备一波，不然面试的时候自己大脑中会一片空白。如果觉得自己解决的问题都没什么技术含量，那可以说项目中其他同事解决的问题，或者是自己在网上看到的问题。但前提是自己一定要搞明白，以后自己遇到了也能解决。

最近有学习什么新技术？
此题主要是想考查你平时爱不爱学习，对新技术有没有一定的敏感度。不用你有多深的领悟了解即可，但千万不能说没有。如果真的没有，就自己了解一下

平时自己逛什么社区？
主要是想了解你平时都是通过哪些途径学习，哪些娱乐社区就别说了，说一些前端方面的社区，像掘金等

你对加班怎么看？
说自己真实看法就好了，如果你说自己绝对不能加班，那就是你自己不想要这个offer

你还有什么想要了解的吗？
别问工资、五险一金啥的，这是项目经理不是hr,问一些技术团队方面的问题，这对于你以后的工作很重要

框架方面
只是部分的问题，希望大家能由点及面好好准备自己框架方面的知识。我建议大家准备一门框架就可以了，大体都相同，精通一门就好了。别vue、react 都是半桶水，还是要深入的了解。

单页面应用和多页面应用的优缺点？

• 单页应用
  优点：页面切换快
  因为页面每次切换跳转时，并不需要做html文件的请求，这样就减少了http发送

  缺点：首屏时间慢，SEO差
  因为首屏时需要请求html，同时还要发送js请求，两次请求回来了，首屏才会展示出来。相对于多页应用，首屏时间慢。
  SEO效果差，因为搜索引擎只认识html里的内容，不认识js的内容，而单页应用的内容都是靠js渲染生成出来的，搜索引擎不识别这部分内容

• 多页应用
  优点：首屏时间快
  因为当我们访问页面的时候，服务器返回一个html，页面就会展示出来，这个过程只经历了一个HTTP请求，所以页面展示的速度非常快。
  搜索引擎优化效果好
  搜索引擎在做网页排名的时候，要根据网页内容才能给网页权重，来进行网页的排名。搜索引擎是可以识别html内容的，而我们每个页面所有的内容都放在Html中，所以这种多页应用，seo排名效果好。

  缺点：页面切换慢
  因为每次跳转都需要发出一个http请求，如果网络比较慢，在页面之间来回跳转时，就会发现明显的卡顿。
  衍生如何解决单页及多页面各自优点的问题

服务端渲染

说一下vue对应的生命周期？
activated和deactivated

vue懒加载
3种方式：vue异步组件、es6提案的import()、webpack的require.ensure()

说一下自己对vdom的了解？
关于这个问题，大家看下我这篇文章，前端学习，五分钟带你看懂Virtual DOM及diff算法在vue中的应用，回答个80分是没有问题的

mvvm的双向绑定原理？
理解即可，不用死记硬背
mvvm 双向绑定，采用数据劫持结合发布者-订阅者模式的方式，通过Object.defineProperty()来劫持各个属性的 setter、getter，在数据变动时发布消息给订阅者，触发相应的监听回调。
为什么要监听getter呢？因为没有getter的属性，说明页面中没有用到，就没有必要监听其setter

几个要点：

1、实现一个数据监听器 Observer，能够对数据对象的所有属性进行监听，如有变动可拿到最新值并通知订阅者

2、实现一个指令解析器 Compile，对每个元素节点的指令进行扫描和解析，根据指令模板替换数据，以及绑定相应的更新函数

3、实现一个 Watcher，作为连接 Observer 和 Compile 的桥梁，能够订阅并收到每个属性变动的通知，执行指令绑定的相应回调函数，从而更新视图

实现简单的双向绑定,大家可以阅读下这篇文章，这应该是最详细的响应式系统讲解了，有时间还是建议能自己敲一遍

vue-router的路由模式?
hash、history
路由原理的深度剖析，大家有时间可以阅读下这篇文章，深度剖析：前端路由原理

说一下redux?

理解即可，不用死记硬背。面试时详细的说一下自己的使用流程，至于细节方面，面试官还会深度的拷问
redux 是一个应用数据流框架，主要是解决了组件间状态共享的问题，主要包括三个核心方法，action，store，reducer

关于 Store：

整个应用只有一个唯一的 Store
Store 对应的状态树（State），由调用一个 reducer 函数（root reducer）生成
状态树上的每个字段都可以进一步由不同的 reducer 函数生成
Store 包含了几个方法比如 dispatch, getState 来处理数据流
Store 的状态树只能由 dispatch(action) 来触发更改
Redux 的数据流：

action 是一个包含 type, payload 的对象
reducer 函数通过 store.dispatch(action) 触发
reducer 函数接受 (state, action) 两个参数，返回一个新的 state
reducer 函数判断 action.type 然后处理对应的 action.payload 数据来更新状态树
所以对于整个应用来说，一个 Store 就对应一个 UI 快照，服务器端渲染就简化成了在服务器端初始化 Store，将 Store 传入应用的根组件，针对根组件调用 renderToString 就将整个应用输出成包含了初始化数据的 HTML。

说几个自己常用的vuex的api?

store.registerModule(‘c’,) //注册一个模块

store.unregisterModule(‘c’) //解绑一个模块

store.subscribe() //订阅，每次mutations被调用，这个api都会被调用

store.subscribeAction() //监听actions

store.watch() //每次state改变之后都会调用

谈谈vue和react？

这题没有对错，说出自己的见解就行，但不能空有见解，还要有理论进行支撑

两者的本质区别
vue - 本质是 MVVM 框架，由 MVC 发展而来
React - 本质是前端组件化框架，由后端组件化发展而来
vue - 使用模板（最初由 angular 提出）
React - 使用 JSX（jsx不是react独有的，已经成了一种标准）
React 本身就是组件化，没有组件化就不是 React
vue 也支持组件化，不过是在 MVVM 上的扩展
两者共同点
都支持组件化
都是数据驱动视图
自己的一些看法 ​
模板语法上，我更加倾向于 JSX，因为它更接近js 语法（列如vue的循环用的是新指令v-for,而react用的是js中的map()函数）
模板分离上，我更加倾向于 vue（数据和视图分离的更彻底）
组件化上，我更加倾向于 React ，做的彻底
国内使用，首推 vue 。文档更易读、易学、社区够大 。 如果团队水平较高，推荐使用 React 。组件化和 JSX 大型项目用react，小型项目用Vue
数据结构和算法

至于数据结构和算法方面各个公司考查的方式完全不同，之前有给大家写过一篇好书推荐的文章，里面有一本数据结构和算法的书真的不错，有时间可以买来看看。如果时间不允许，大家只要认真准备这几点就好了
快速排序、选择排序、希尔排序、冒泡排序、波兰式和逆波兰式

hr
大部同学都不太重视hr的面试，虽然说只要技术官和项目经理过了，一般offer就到手了，但hr是有一票否决权的，大家还是要稍微准备下，死在这就太冤了。。。

为什么想要换工作？
换工作无非于那三个原因，钱给的不够、在公司处的不开心、在公司没有上升空间。只要大家的原因积极正向一点别说公司的坏话就好了，其它自由发挥。记住千万别说公司坏话，即使前公司很操蛋

对薪水自己有怎样的期待？
自己给出一范围，别把话说太死，不同公司可以上下调整的
对未来有一个怎样的规划？

别说的太空，主要从两个方面出发，一个实近期规划，还有一个是长远规划

你还有什么想要了解的吗？
现在可以了解自己的工资、待遇、公司环境等，这里就别端着了，有什么想了解的尽管问

最近读到张爱玲的一句话：中年以后的男人，时常会觉得的孤独，因为他一睁开眼，周围都是要依靠他的人，却没有他可以依靠的人。

漫漫前端技术路，其中冷暖只有自己知道。。。我不喜欢面试，也不喜欢被人挑选的感觉。但只有自己时刻准备、一直学习着，才会拥有选择的权利。

与君共勉

2017你该选择什么前端框架？

框架选型 

前面的话

　　有一个流传较广的笑话，一个人在stackoverflow中提了一个问题，如何使用javascript实现一个数字与另外一个数字相加。最高票回答是你应该使用jQuery插件，jQuery插件可以做任何事情。 历史总是在重演，以前是jQuery，现在可能是react或vue。不同的框架有不同的应用场景，杀鸡不要用牛刀。本文将详细介绍框架选型

 

框架与库

　　库(lib)具有以下三个特点：

　　1、是针对特定问题的解答，具有专业性；

　　2、不控制应用的流程

　　3、被动的被调用

　　框架(frameword)具有以下三个特点：

　　1、具有控制反转(inverse of control)的功能

　　2、决定应用程序的生命周期

　　3、一般来说，集成了大量的库

　　由下图所示，框架会在特定的时间要求程序执行某段代码。框架决定了什么时候调用库，决定了什么时候要求代码去执行特定功能

　　而实际上，一个库有时也可以称之为框架，而库里面集成的方法称之为库

　　框架和库的区别不由实际大小决定，而由思考角度来决定。框架和库实际上可以统称为解决方案

 

解决方案

　　前端开发中的解决方案主要用于解决以下7个方面的问题：

　　1、DOM

　　2、Communication(通信)

　　3、Utililty(工具库)

　　4、Templating(模板集成)

　　5、Component(组件)

　　6、Routing(路由)

　　7、Architecture(架构)

【why】

　　为什么要使用外部的解决方案呢？

　　1、提高开发效率

　　2、可靠性高（浏览器兼容，测试覆盖）

　　3、配备优良的配套，如文档、DEMO及工具等

　　4、代码设计的更合理、更优雅

　　5、专业性高

　　如果问题过于简单，或者备选框架的质量和可靠性无法保证，再或者无法满足业务需求，则不应该选择外部的框架。如果团队中已经有相关的积累，就更不需要使用了

【how】

　　一般地，解决方案要实际开发中有以下3种使用方式：

　　1、开放式：基于外部模块系统，并自由组合

　　2、半开放式：基于一个定制的模块系统，内部外部解决方案共存

　　3、封闭式：深度定制的模块系统，很少需要引入外部模块

 

DOM

　　接下来，将针对解决方案中提到的7个问题进行分别介绍，首先是DOM

　　关于DOM，主要包括Selector(选择器)、Manipulation(DOM操作)、Event(事件)、Animation(动画)这四个部分

　　DOM相关的解决方案主要用于提供以下操作　

　　1、提供便利的 DOM 查询、操作、移动等操作

　　2、提供事件绑定及事件代理支持

　　3、提供浏览器特性检测及 UserAgent 侦测

　　4、提供节点属性、样式、类名的操作

　　5、保证目标平台的跨浏览器支持

【常用方案】

　　常用的DOM解决方案有 jQuery、zepto.JS、MOOTOO.JS等

　　jQuery是曾经风靡一时的最流行的前端解决方案，jQuery特有的链式调用的方式简化了javascript的复杂操作，而且使人们不再需要关心兼容性，并提供了大量的实用方法

　　zepto是jQuery的精简版，针对移动端去除了大量jQuery的兼容代码，提供了简单的手势，部分API的实现方式不同

　　mootools源码清晰易懂，严格遵循Command-Query(命令-查询)的接口规范，没有诸如jQuery的两义性接口。还有一个不得不提的特点是，使用选择器获取的是DOM原生对象，而不是被包装过的对象。而它支持的诸多方法则是通过直接扩展DOM原生对象实现的，这也是它的争议所在

　　相比较而言，最稳妥的DOM解决方案是jQuery

【专业领域】

　　上面的解决方案用于解决DOM一般的通用问题。随着技术的发展，DOM的专业领域出现一些小而精致的解决方案

　　1、手势

　　Hammer.JS包括了常见手势封装（Tab、Hold、Transform、Swifp）并支持自定义扩展

　　2、局部滚动

　　iscroll.JS是移动端position:fix + overflow:scroll的救星

　　3、高级动画

　　Velocity.JS可以复杂动画序列实现，不仅局限于 DOM

　　4、视频播放

　　Video.JS类似原生 video 标签的使用方式，对低级浏览器使用 flash 播放器

通信

　　关于通信，主要包括XMLHttpRequest、Form、JSONP、Socket等 

　　通信相关的解决方案主要用于提供以下操作

　　1、处理与服务器的请求与相应

　　2、预处理请求数据与响应数据 Error/Success 的判断封装

　　3、多类型请求，统一接口（XMLHttpRequest1/2、JSONP、iFrame）

　　4、处理浏览器兼容性

【常用方案】

　　除了jQuery等，其他常用的通信解决方案有Reqwest、qwest等

　　Reqwest支持JSONP，稳定性高，IE6+支持，CORS 跨域，Promise/A 支持

　　qwest代码少、支持XMLHttpRequest2、CORS 跨域、支持高级数据类型（ArrayBuffer、Blob、FormData）

【专业领域】

　　对于实时性要求较高的需求可以使用socket.io，它实时性高，支持二进制数据流，智能自动回退支持，且支持多种后端语言

 

工具包

　　工具包(Utililty)的主要职责包括以下：

　　1、提供 JavaScript 原生不提供的功能

　　2、包装原生方法，使其便于使用

　　3、异步队列及流程控制

【常用方案】

　　常用的工具包解决方案有es5-shim、es6-shim、underscore、Lodash等　　

　　上面提到的shim，也是经常听到的一个词，翻译过来是垫片的意思。对于es5、es6等标准包括的一些新方法，由于浏览器兼容性不高，所以无法直接使用它们。这时，就需要在保证实现与规范一致的基础上，来扩展原型方法，这种做法就叫做shim。好处在于，实际上就是在使用javascript的语法，但不用去考虑低版本浏览器的兼容性问题

　　es5-shim 提供 ES3 环境下的 ES5 支持

　　es6-shim 提供 ES5 环境下的 ES6支持

　　underscore 提供兼容 IE6+ 的扩展功能函数

　　Lodash是underscore 的高性能版本，方法多为 runtime 编译出来的

 

模板

　　模板主要包括三类：基于字符串的模板(String-based)、基于DOM的模板(DOM-based)、活动模板(Living Template)

　　1、基于字符串的模板(String-based)，解决方案包括(dustjs、hogan.js、dot.js)

　　原理如下：输入一段模板字符串，通过编译之后 ，生成一段Function，通过Function的render或类render函数渲染输入的数据data，输出模板字符串，字符串通过innerHTML或类似的方式渲染成最后的DOM结构。这类模板的问题在于通过字符串生成DOM之后就不再变化，如果在改变输入的数据data，需要重新render，重新生成一个全新的DOM结构，性能较差。但该模板可以在服务器端运行

　　2、基于DOM的模板(DOM-based)，解决方案包括(angularjs、vuejs、knockout)

　　原理如下：将输入的字符串模板通过innerHTML转换为一个无状态DOM树，然后遍历该节点树，去抓取关键属性或语句，来进行相关的绑定，进而变成了有状态的DOM树，最终导致DOM树会与数据模型model进行绑定。这类模板的特点是修改数据时，会使有状态的DOM树实时更新，运行时性能更好，也会保留 DOM 中的已有事件

　　3、活动模板(Living Template)，解决方案包括(RegularJS、RactiveJS、htmlbar)

　　原理如下：活动模板融合了字符串模板和DOM模板的技术，模板字符串string通过自定义的解析器DSL-based Parse解析成AST(抽象语法树)，通过遍历AST，使用createElement()、setAttribute()等原生DOM方法，生成DOM树，最终导致DOM树会与数据模型model进行绑定。由于其内部完全不使用innerHTML，所以安全性较高

 

组件

　　组件(Component)的主要职责包括以下：

　　1、提供基础的 CSS 支持

　　2、提供常见的组件，如slider、Modal等

　　3、提供声明式的调用方式（类似 Bootstrap）

【常用方案】

　　常用的组件解决方案有Bootstrap、Foundation等，两者具有移动端first的流式栅格系统，由sass组织，可定制UI

　　Bootstrap封装了常用的组件，是目前最火的组件解决方案

　　Foundation在国内知名度不高

 

路由

　　路由在单页系统中非常重要，主要职责如下

　　1、监听 URL 变化，并通知注册的模块

　　2、通过 JavaScript 进行主动跳转

　　3、历史管理

　　4、对目标浏览器的兼容性支持

　　无论什么框架，在完成配置之后，内部都有如下图所示的类似的路由表。

【常用方案】

　　常用的路由解决方案有page.JS、Director.JS、Stateman、crossroad.JS等

　　page.JS类似 Express.Router 的路由规则的前端路由库

　　Director.JS可以前后端使用同一套规则定义路由

　　Stateman处理深层复杂路由的独立路优库

　　crossroad.JS老牌路由库，API 功能较为繁琐

 

架构

　　所有的架构(architecture)都是一个目的，就是解耦。解耦有很多方式，可以通过事件、分层等

　　市面上，有很多架构模式，包括MVC、MVVM、MV*等

　　架构的职责主要包括以下：

　　1、提供一种范式帮助（强制）开发者进行模块解耦

　　2、视图与模型分离

　　3、容易进行单元测试

　　4、容易实现应用扩展

　　以MVVM为例，如下图所示。它包括Model(数据层或模型层)、View(视图层)、ViewModel(控制层)

　　Model(数据层或模型层)表示数据实体，它们用于记录应用程序的数据

　　View(视图层)用于展示界面，界面是数据定制的反映，它包含样式结构定义以及VM享有的声明式数据以及数据绑定

　　ViewModel(控制层)是View与Model的粘合，它通过绑定事件与View交互并可以调用Service处理数据持久化，也可以通过数据绑定将Model的变动反映到View中

　　它们的关系是：各部分之间的通信，都是双向的；View 与 Model 不发生联系，都通过 ViewModel 传递；View 非常薄，不部署任何业务逻辑，称为"被动视图"（Passive View），即没有任何主动性，而ViewModel非常厚，所有逻辑都部署在那里

【SPA】

　　要特点注意的是，MV* !== SPA(单页系统)

　　SPA应用程序的逻辑比较复杂，需要一种模式来进行解耦，但并不一定是MV*模式

 

最后

　　最后推荐一个框架选型网站https://www.javascripting.com，该网站根据不同的需求的选择，给出当下流行的框架选型