共计 3174 个字符，预计需要花费 8 分钟才能阅读完成。
本文以自己无限的经验提供一些思路，理论真的有解决过比拟辣手的问题的同学就没什么看的必要了。
我认为这个问题次要考查的一方面是求职者解决问题的能力，另一方面是求职者的总结复盘能力，有时还考查求职者是否对技术有关注和接触。这类主观题我感觉能够针对 JD 的要求去贴近招人需要。
平时忙于业务开发的同学，有时很容易疏忽一些问题，或者有时急着实现需要和修复 bug，解决问题后没及时记录下来，本文就起个抛砖引玉的作用，列举一些比拟通用型的问题。
按钮反复点击的问题
其实这场景应该还蛮容易遇见的，所以我感觉比拟适宜做前端年限不太长比方一两年的同学来作为备选。
有时因为网络问题，或者手机性能问题，或者一些未知起因，导致用户点击按钮的操作没有及时失去响应，用户下意识的就会频繁反复点击。
如果该按钮的点击回调是去调用接口，假如用户频繁点击，不可避免的就会给服务器造成压力，最简略的解决就是在用户点击之后设置按钮为不可点击，等到接口有返回后再将按钮状态重置；如果接口没有适合的返回，为了避免因网络等起因导致的没有响应，也能够前端设置定时，使用户操作控制在肯定的频率，比方发送验证码这种场景。
如果该按钮的点击回调是关上一个弹窗，频繁点击的结果可能就是关上一串的弹窗，当然也能够给按钮设置状态标记字段或者定时，此时就能够联合节流与防抖作答，正好面试中也很容易遇到节流与防抖的问题，化被动为被动更好把握面试节奏，当然前提就是对这方面的内容有所准备。
如果该按钮是与原生有交互，比方自己已经遇到过调用原生关上新的 webview 或者其余 app，如果原生因为某些零碎起因没有及时关上，节流防抖也做了，然而如果响应提早很久，用户可能在页面上做其余操作了，此时如果之前关上新的 webview 或者其余 app 有了响应，就有可能同时呈现多个操作的交互反馈，造成凌乱，起初的解决方案还是做了字段标记，在第一次关上 webview 的操作就作标记，如果此标记没重置（没关上新的 appview），就不响应后续此页面上的其余交互，这在应用逻辑上可能有些不太正当，然而关上 webview 和其余 app 的操作原生无奈勾销，过后还没想到比拟好的其余解决计划。
轮询接口的问题
此类场景也还算常见，适宜两三年、三四年的同学作为备选。
有时咱们会遇到一些需要，比方页面要定时获取最新的数据，如用户积分、app 内音讯告诉，个别简略的解决就是应用接口轮询，定时调用后端接口，如果利用的流量不大、应用的用户不多，这么解决也没什么大问题。
但理论这样做会使申请过多，占用服务器资源，出于优化思考，能够思考 websocket，就能够提前对 websocket 做一些理解学习，如果我的项目理论开发中有应用教训就更好了。
单次加载图片过多的问题
这个问题通常产生在挪动端，尤其图片体积偏大时，可能影响其余申请的发送。
比拟常见的就是列表，往往这些列表的数据是用户在后盾上传的，因而如果用户传一些高清图，就可能导致图片体积过大，图片压缩当要做，同时在挪动端，咱们也能够做图片懒加载，只渲染进入可视区域的图片，期待图片行将进入可视区域时再进行加载；当初挪动端列表个别会做分页，也就是常见的上拉加载，一次不会加载太多图片，如果对性能要求比拟高的时候也能够加上懒加载。
如果图片托管在 OSS 平台，也能够在链接前面追加解决参数（x-oss-process），对返回的图片的大小和尺寸进行限度，也是一种办法。
挪动端适配问题
挪动端陈词滥调的问题了，css 中的绝对单位，罕用计划 rem 能够说，配合理解一些 webpack 插件。
也能够说说 vw、vh，屏幕分辨率，浏览器视口。
挪动端兼容问题
挪动端手机型号多，尤其安卓机型，或多或少会碰到这类问题，但这些问题又不能一概而论。
如果有同学解决过较多这方面的问题，然而素日里没有整顿过，能够提前做一些整顿，去 mdn、caniuse 等网站针对做一些补充欠缺，就能够在面试时施展了。
利用性能问题
如果切实工作开发中没碰到过什么大的问题，还能够有个万能的答复，就是对利用性能进行优化，我看很多 JD 里也会心愿候选人有性能优化方面的教训，正好能够对应上。
随着需要迭代，我的项目代码不可避免会增多，打包体积随之减少，用户首次关上利用也会变慢。这个问题能够从多方面着手去作答。
从交互层面，能够做骨架屏，使得页面首次加载不会长时间白屏，也能让用户事后晓得页面的散布；或者减少一些期待的交互。
从代码层面，能够提取专用代码、通用代码，抽取进去做成专用函数，或者封装成组件，业务组件或者根底组件。
从构建工具方面，比方 webpack，能够提前理解它的一些配置，比方代码压缩、代码拆分、tree-shaking、懒加载。
从性能工具方面，比方 lighthouse，量化指标，依据提供的倡议进行调优，能够提前理解一些代码和性能剖析工具。
从网络申请方面，比方用户端设置缓存，能够提前准备强缓存和协商缓存方面的储备常识，一方面缩小用户申请，一方面及时更新缓存；应用 CDN 等等。
从技术方面，能够筹备微前端等相干常识。
线上问题定位
对于前端来说有个很头疼的问题，就是线上问题，不想后端一样能够有线上日志，前端问题呈现在客户端时咱们不晓得产生了什么，用户操作了什么，就算能够分割到用户，有时他们也不肯定记得本人做了什么，而往往很多时候晓得起因就很容易解决问题了，难的就是不晓得导致问题的起因。
这个问题我大略是五六年前的时候第一次碰见，很紧急的一个线上领取问题，前端反反复复盲改，始终没改好了，起初加了谬误捕捉，再通过调用接口获取到错误信息，才晓得起因是什么；起初换了工作在新公司中接触到埋点，才开始理解到这一块的货色，不过过后公司的埋点次要用于用户行为剖析，在用户进行一些交互操作，比方点击、进入页面、登录时，将用户行为数据上报给埋点平台，数据分析的同学会利用这些数据进行统计，能够给经营同学做一些经营策略的参考，给产品经理布局需要时做参考。
再起初在工作中又接触到监控平台 sentry，应用它将利用中捕捉到的谬误上报给平台，在 sentry 平台能够看到哪些谬误是比拟频发的，还能够直观的看到在抛出谬误时上报的相干数据，比方操作系统、用户标识、ip、错误信息等等，还能够看到问题是在哪些时间段频发，从而能够确认新发的包是否解决了之前的问题；当然还有很多性能我用的不怎么多还不晓得。
如果有同学想把这个问题作为备选，能够提前理解前端的埋点和监控平台。
其实我感觉埋点的外围一个是后期将须要的数据通过接口上报，不论是用户行为数据还是错误信息数据；另一个是前期解决后确认是否该问题不会呈现或者被管制在肯定范畴内。
手动打包问题
我最早待过的一家公司是开发本人手动打包，而后将包发给运维部署，这很容易出错，家喻户晓，咱们通常是拉分支做需要的，如果在做新需要时要切换到旧分支，流程繁琐，很容易误操作，存在安全隐患，也影响新需要的开发效率和进度，起初咱们运维就本人搞了一套自动化构建的货色，过后我也没有接触。
起初换了一家公司，接触到 jenkins，才开始对自动化构建有一些理解。
如果岗位的 JD 有这方面的偏好，就能够从自动化构建、CICD 方面做一些筹备。
工作效率问题
一个是上述的手动打包问题能够说，还能够施展的中央有，如果我的项目代码过多，影响构建效率，当咱们的代码还在测试阶段时，有时候改 bug 可能要频繁构建，如果构建慢就很影响测试进度，甚至有时构建慢影响到紧急 bug 的修复上线，此时能够针对构建工具比方 webpack 做一些相干配置，相应的就是要对 webpack 的相干配置提前有所理解。
也能够说说单测，前提是去理解下罕用的单元测试工具。
还能够从代码标准着手，讲讲 eslint、husky 等，进步团队的合作效率；组织学习工作方面的分享，晋升技术的同时避免一些问题的反复产生；提取专用代码，缩小重复劳动。等等。
