现在在华为实习，但是方向和学校的不一致，也不太感兴趣

面到心态炸裂，不知道是不是我真的太菜了1 科研经历 这么多开发实习，在实验室干了啥？算法指标提高了多少？2 项目追问，项目里Redis存放什么?falcon是什么？总数据量？数据量不大，为什么用redis？3 定时任务quartz部署几台机器？如果只部署了一台机器宕机了怎么办？4 如果quartz部署了多台机器，怎么保证不重复调用？怎么保证调用按序进行？5 实习追问，sofaboot增强了springboot什么功能？sofaboot作用是什么？底层了解吗？6 sofaboot底层报错了怎么解决？7 sofaboot的traceid底层是怎么透传的？8 代码遇到过什么异常，不能说业务逻辑导致的，说出异常名称 报错是什么？9 报错日志在哪里配置的？去哪里看日志？10 代码发布的流程是什么？灰度 预发 生产怎么做的？11 写线程池 写五个线程往一个集合里面塞1000个元素，且线程安全，api和函数都需要正确 线程怎么销毁 写在哪里 写出来12 一个服务部署多个环境上，怎么让不同环境读取不同配置文件？怎么配置的？13 怎么将bean添加属性？答加注解 追问什么注解？

面试全是一轮游，学历普通，但实习经历丰富。能进面试已经很意外，毕竟听说这种学历很难过简历筛选。复盘后发现，挂掉是有原因的：简历没深挖，面试准备不足，对岗位业务不熟悉，紧张时回答不够全面。心理上也不够自信，总是患得患失。最近的收获是，要做一个内心辽阔的人，保持身心健康，等待机会的到来。

#你都收到了哪些公司的感谢信？# 搞不懂好未来到底招不招人，还是为了宣传公司。暑期某聘看，一样岗位十几位招聘官，有hr，还有其他岗位的。发信息根本不回应。现在秋招投递 一样问题。。

        第三期来了，惯例感谢牛u们的点赞收藏和花花~        话不多说直接开始。1.（百度一面）什么时候会用到预检请求        可能有些小伙伴还没了解过这个概念，那就整体介绍一下预检请求，看完就明白了。        首先说下啥时候会用到预检请求：在CORS解决跨域的这套机制内会用到。        在 CORS 机制中，客户端将请求分为了两种：简单请求和非简单请求（分类见图1）；当请求为非简单请求时，就会触发浏览器发送预检请求，这是浏览器的行为。            预检请求会向服务器确认跨域是否允许，服务返回的响应头里有对应字段Access-Control-Allow-Origin来给浏览器判断：如果允许，浏览器紧接着发送实际请求；不允许，报错并禁止客户端脚本读取响应相关的任何东西。        所以，比如一个 POST 请求并且请求头添加了Content-Type: application/json ，浏览器判定为非简单请求，自己先发一个 OPTIONS 请求给服务器获取做跨域判定，获取响应后浏览器发现可以跨域，接着就发送真实的 POST。        接下来的问题是：为什么预检请求选择了 OPTIONS 呢？        来看预检请求的流程，如果是一个跨域请求，浏览器会自动给该请求带上 Origin 头部，标明当前请求的来源域；服务器判断这个请求是否允许跨域，就会在返回时，选择是否带上 Access-Control-Allow-Origin 头部，最后，浏览器判断 Access-Control-Allow-Origin 就知道，后续请求是否发送。        这个流程中，对预检请求方法的要求：        ① 不需要带请求体，服务器判断的依据在 Request header 中；        ② 服务器返回不需要响应体，浏览器判断的依据在 Response header 中；        ③ 请求不会去修改服务器资源（幂等），要是一个安全的请求；        ④ 浏览器默认不会缓存，需要每次发送跨域验证；        再看看 OPTIONS 的定义（图2），会有一种量身定做的感觉。        下一个问题：为啥要先去发个请求判断能不能跨域，这样不是比较麻烦吗？        我认为这个做法的优点有两个：        ① 如果类似浏览器这种，包含 CORS 机制的客户端发送的请求，每次都要经过一个复杂逻辑才能知道自己是否跨域，服务器的压力和用户体验是不理想的，那么预检请求就孕育而生：发送实际请求前，先发送预检请求询问服务器是否允许跨域，不允许就不发送实际请求，服务器只需要对预检请求进行跨域处理；        ② 发送预检请求是一种保护机制，保护资源不被未授权的请求修改。和授权服务很像，预检请求通过了，浏览器后续对同一服务的请求，不需要做跨域询问，服务端不想支持跨域访问，啥也不用做。2.（阿里国际一面）react组件的INP比较长，如何优化        问到我这个问题的时候是没听说过这个概念的。INP（Interaction to Next Paint）是一个网站性能度量指标，用于衡量用户界面的响应性，即用户进行点按、点击或键盘交互后，到屏幕上绘制下一帧的时间。        我认为这个指标的优化其实不太涉及到组件。        先来看看一次交互是怎么组成的，一次交互可分为 3 个阶段（图3）：        ① 输入延时（Input Delay）= 交互事件回调开始运行时 - 用户发起与页面的交互时，FID 度量的就是这段时间。        ② 事件处理（Processing Time）= 事件回调运行完成时 - 事件回调运行开始时        ③ 渲染延时（Presentation Delay）= 浏览器显示包含交互的可视结果的下一帧渲染时 - 事件回调运行完成时        所以这三个阶段的总和就是总的交互延时，优化的时候应该尽可能的减少这三部分的耗时。三点的话分别有几个思路：首先对于输入延时，对于交互过程中执行时间过长的会阻塞主线程的任务应该尽可能减少，或者放到别的线程；其次是事件处理，也是一样的要让主线程上的事件处理尽可能快，同时可以对不同类型的输入建立优先级，进行分类；最后对于渲染耗时：减小dom大小，比如虚拟列表之类。除此之外我当时想到了不要让dom的层级或组件嵌套太深，缩短数据传输的链路，链路越长耗时肯定也越长。        上面的内容详细来自于这篇帖子，有兴趣的牛u自行查阅哈：******************************************3.（阿里国际一面）一个秒杀按钮用防抖还是节流        看到按钮可别想当然就说防抖啊，应该想一下这个场景需要什么。        从功能的角度来说，用户肯定希望在事件到的那一刻尽可能快的点击抢购东西。如果是防抖，那么按一次重新计时一次，用户点了几下发现还不如不点，肯定不是我们希望的。所以用节流，在第一次点击后就触发，直到一段时间后才能再次触发。4.（快手三面）react的useEffect叫副作用函数，“副作用”是什么意思？        首先回想一下什么叫做纯函数：给一个 function 相同的参数，永远会返回相同的值。这个概念在react中可以类比成，给一个组件相同的props，渲染出来的视图是一样的。那么副作用就是指一个 function 做了和本身运算返回值无关的事，比如：修改了全局变量、修改了传入的参数、甚至是 console.log()。在 React 中，副作用指的是与组件渲染结果无关的任何操作，例如：        ① 发送网络请求        ② 修改 DOM 元素        ③ 访问本地存储        ④ 订阅或取消订阅事件        ⑤ 改变组件状态外的变量等        这些操作会影响组件的行为和状态，但是并不会直接影响渲染结果。想一下useEffect一般会做些什么是不是就很明了了（如发送网络请求或订阅事件，以及在组件卸载时清除这些操作）。        下一期准备挑蔚来和美团的几个问题，大型连续剧不要错过，欢迎来个关注~        这些问题自己确实也没实操过，大部分是我自己个人结合知识点消化理解的东西，有问题评论区可以批评指正。        再次欢迎大家点赞收藏送花！#我的求职思考##软件开发2024笔面经##前端##百度##阿里国际##快手#