前端：说说工作中解决过的印象比较深刻的问题

本文以本人有限的经历提供一些思路，实际真的有解决过比较棘手的问题的同学就没什么看的必要了。

我认为这个问题主要考察的一方面是求职者解决问题的能力，另一方面是求职者的总结复盘能力，有时还考察求职者是否对技术有关注和接触。这类主观题我觉得可以针对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等等。

从技术方面，可以准备微前端，SSR、webassembly等相关知识。

线上问题定位

对于前端来说有个很头疼的问题，就是线上问题，不想后端一样可以有线上日志，前端问题出现在客户端时我们不知道发生了什么，用户操作了什么，就算可以联系到用户，有时他们也不一定记得自己做了什么，而往往很多时候知道原因就很容易解决问题了，难的就是不知道导致问题的原因。

这个问题我大概是五六年前的时候第一次碰见，很紧急的一个线上支付问题，前端反反复复盲改，一直没改好了，后来加了错误捕获，再通过调用接口获取到错误信息，才知道原因是什么；后来换了工作在新公司中接触到埋点，才开始了解到这一块的东西，不过当时公司的埋点主要用于用户行为分析，在用户进行一些交互操作，比如点击、进入页面、登录时，将用户行为数据上报给埋点平台，数据分析的同学会利用这些数据进行统计，可以给运营同学做一些运营策略的参考，给产品经理规划需求时做参考。

再后来在工作中又接触到监控平台sentry，使用它将应用中捕获到的错误上报给平台，在sentry平台可以看到哪些错误是比较频发的，还可以直观的看到在抛出错误时上报的相关数据，比如操作系统、用户标识、ip、错误信息等等，还可以看到问题是在哪些时间段频发，从而可以确认新发的包是否解决了之前的问题；当然还有很多功能我用的不怎么多还不知道。

如果有同学想把这个问题作为备选，可以提前了解前端的埋点和监控平台。

其实我觉得埋点的核心一个是前期将需要的数据通过接口上报，不管是用户行为数据还是错误信息数据；另一个是后期解决后确认是否该问题不会出现或者被控制在一定范围内。

手动打包问题

我最早待过的一家公司是开发自己手动打包，然后将包发给运维部署，这很容易出错，众所周知，我们通常是拉分支做需求的，如果在做新需求时要切换到旧分支，流程繁琐，很容易误操作，存在安全隐患，也影响新需求的开发效率和进度，后来我们运维就自己搞了一套自动化构建的东西，当时我也没有接触。

后来换了一家公司，接触到jenkins，才开始对自动化构建有一些了解。

如果岗位的JD有这方面的偏好，就可以从自动化构建、CICD方面做一些准备。

工作效率问题

一个是上述的手动打包问题可以说，还可以发挥的地方有，如果项目代码过多，影响构建效率，当我们的代码还在测试阶段时，有时候改bug可能要频繁构建，如果构建慢就很影响测试进度，甚至有时构建慢影响到紧急bug的修复上线，此时可以针对构建工具比如webpack做一些相关配置，相应的就是要对webpack的相关配置提前有所了解。

也可以说说单测，前提是去了解下常用的单元测试工具。

还可以从代码规范着手，讲讲eslint、husky等，提高团队的协作效率；做学习工作方面的分享，提升技术的同时防止一些问题的重复发生；提取公用代码，减少重复劳动。等等。