前端：说说工作中解决的印象比较深刻的问题。我觉得这道题一方面主要考查求职者解决问题的能力，另一方面考查求职者总结和复习的能力。有时也考察求职者是否对技术有关注和接触。这种主观题我觉得按照京东的要求可以贴近招聘需求。平时忙于业务开发的同学，有时容易忽略一些问题，或者有时急于完成需求和修复bug，解决问题后未能及时记录。本文作为介绍，列举了一些比较普遍的问题。重复点击按钮的问题其实还是挺容易遇到的，所以我觉得比较适合前端时间不是太长的同学，比如一两年，作为备选。有时由于网络问题、手机性能问题，或者一些不明原因，导致用户点击按钮操作得不到及时响应，用户下意识地频繁、反复点击。如果按钮的点击回调是调用接口，假设用户点击频繁，必然会对服务器造成压力。最简单的解决办法就是设置按钮在用户点击后不可点击，等到界面返回后再改变按钮状态。重置;如果界面没有正常返回，为了防止因为网络等原因无响应，也可以在前端设置一个定时器，控制用户以一定的频率进行操作，比如发送验证码。如果按钮的点击回调是弹窗的话，那么频繁点击的后果可能就是连续弹窗。当然你也可以为按钮设置状态标志字段或者时序。这时候可以结合节流和防抖来回答，正好面试的时候也容易遇到节流和防抖的问题。化被动为主动，更好把握面试节奏。当然，前提是要做好这方面的准备。如果按钮与原件交互，例如我遇到过调用原件打开新的webview或其他应用程序。如果原来由于某些系统原因没有及时打开，节流和防抖也做了，但是如果长时间延迟响应，用户可能正在页面上做其他操作。这时候如果之前打开一个新的webview或者其他app有响应，可能会有同时多个操作的交互反馈，造成混乱。后来的解决方案是标记字段。标记第一次打开webview的操作。如果不重置标记（没有打开新的appview），则不会响应后续页面的其他交互。这在逻辑上可能不太合理，但是打开webview和其他app的操作是无法取消的。当时并没有想到其他更好的方案。轮询接口问题等场景比较常见，适合两三岁或三四岁的学生。有时候我们会遇到一些需求，比如页面需要定时获取最新的数据，比如用户积分，APP内的消息通知，一般简单的处理就是使用接口轮询，定时调用后端接口，如果应用的流量不大，使用的用户也不多，所以这种方式问题不大。但实际上这样做会造成过多的请求，占用服务器资源。出于优化的考虑，可以考虑websocket，可以提前对websocket做一些了解和学习。如果有项目实际开发的经验就更好了。一次加载过多图片的问题这个问题一般出现在移动端，尤其是图片尺寸过大时，可能会影响其他请求的发送。比较常见的是列表。通常这些列表中的数据是由用户在后台上传的。因此，如果用户上传一些高清图片，可能会导致图片尺寸过大。应该进行图片压缩。同时，我们也可以在移动端进行图片制作。懒加载，只渲染进入可见区域的图片，等待图片进入可见区域后再加载；现在移动端的列表一般都会分页，就是常见的上拉加载，不会一次加载太多图片，如果对性能要求比较高的时候也可以加入Lazyloading。如果图片托管在OSS平台，也可以在链接后面加一个处理参数（x-oss-process）来限制返回图片的大小和大小，也是一种方法。移动端适配问题是移动端上的老生常谈了。css中的relativeunit和常见的解法rem可以说配合理解一些webpack插件。您还可以谈论vw、vh、屏幕分辨率和浏览器视口。手机兼容性问题手机的型号很多，尤其是安卓机型，或多或少都会遇到这样的问题，但不能一概而论。如果有的同学已经解决了很多这方面的问题，但是平日没有整理出来，可以提前整理一下，到mdn，caniuse等网站做一些补充和完善，然后就可以用了在面试过程中。应用性能问题如果你在工作开发中没有遇到过什么大问题，你也可以有一个通用的答案，那就是优化应用性能。我想很多JD也希望应聘者有性能优化方面的经验。可以对应。随着需求的迭代，项目代码必然会变多，打包体积变大，用户第一次打开应用会变慢。这个问题可以从很多方面来回答。从交互层面，可以作为骨架屏，让页面在第一次加载的时候不会长时间空白，也可以让用户提前知道页面的分布情况;或者添加一些等待交互。从代码层面，可以将公共代码、公共代码抽取出来做成公共函数，也可以封装成组件、业务组件或基础组件。从构建工具方面，比如webpack，可以提前了解它的一些配置，比如代码压缩、代码拆分、tree-shaking、懒加载等。性能工具方面，比如lighthouse，量化指标，根据提供的建议进行调优，可以提前学习一些代码和性能分析工具。网络请求方面，比如在客户端设置缓存，可以准备强缓存，提前协商缓存储备知识，一方面减少用户请求，另一方面及时更新缓存；使用CDN等。技术方面可以准备微前端等相关知识。在线问题定位有一个很让前端头疼的问题，就是在线问题，不像后端可以有在线日志，当客户端出现前端问题的时候，我们不知道发生了什么，用户做了什么，即使能联系到用户，有时他们不一定记得自己做了什么，很多时候知道原因就很容易解决问题。困难在于他们不知道问题的原因。大约五六年前，我第一次遇到这个问题。这是一个紧急的在线支付问题。前端一味地反复改，一直没修好。后来加了错误捕获，然后调用接口获取。直到看到报错信息才知道原因。后来换了工作，在新公司接触到了埋点，才开始了解这个东西。不过公司的埋点当时主要用于用户行为分析，对用户进行一些交互操作，比如在点击、进入页面、登录时，将用户行为数据上报给埋点平台，数据分析同学会利用这些数据进行统计，可以作为运维同学的参考和产品经理规划时的要求。后来在工作中接触到了监控平台哨兵，用它来将应用中捕捉到的错误报告给平台。在哨兵平台可以看到哪些错误比较频繁，也可以直观的看到什么时候抛出错误上报相关数据，比如操作系统，用户ID，ip，错误信息等，还可以看到什么时候抛出错误问题频繁出现，以便您确认新发布的包是否解决了之前的问题；当然还有很多功能。我不知道我用了多少。如果有同学想做这道题的备选题，可以提前了解一下前端埋点和监控平台。其实我觉得埋点的核心是前期通过接口上报需要的数据，不管是用户行为数据还是错误信息数据；二是确认后期解决后问题是否不会发生或控制在一定范围内。手动打包问题我最早工作的公司之一是开发并手动打包包，然后将包发送到运维部署。这是非常容易出错的。众所周知，我们一般都是拉分支来做需求。如果需要切换到旧的分支，流程繁琐，容易误用，存在安全隐患，也会影响新需求的开发效率和进度。后来我们运维开发了一套自动化构建工具，我当时没接触过。后来换了一家公司，接触到了jenkins，才开始对自动化构建有了一些了解。如果岗位的JD有这方面的偏好，可以从自动化构建和CICD做一些准备。影响工作效率的问题之一就是上面提到的人工打包问题。可以说还有用的地方。如果工程代码过多，会影响施工效率。当我们的代码还处于测试阶段时，有时我们可能需要频繁构建以修复错误。如果构建慢会极大地影响测试进度，有时构建慢还会影响紧急bug的修复。这个时候可以对webpack等构建工具进行一些相关的配置。相应的，你必须提前了解webpack的相关配置。也可以讲讲单元测试，前提是了解常用的单元测试工具。也可以从代码规范入手，讲讲eslint、husky等，提高团队协作效率；组织学习工作分享，提高技术的同时防止一些问题再次发生；提取通用代码，减少重复劳动。ETC。
