“他在乎的是诸如用户输入事件需要 debounce 这类在做一个 search input 时的应该默认就加上的基本操作”---这算鸡毛优化，属于交互规范了。 我觉得大部分项目不需要刻意优化，能做到适老、无障碍、合理降级已经非常不错了。 没有严重的内存泄漏、卡顿、崩溃已经达标。当然包的体积能小点最好了。

那个词叫 [问到] ，我一眼看成性道...

面试官都是带着答案来问问题的，我之前也是。刚好能说到答案，面试官就会认为你会，很满意，和自己观点相同。 你说到一个面试官没接触过的，即使是对的，面试官自己都不懂，就不满意。好的面试官还会和你聊一聊，你这时候就要说服面试官，但是效果肯定不如说到预先的答案上好。 面试官水平有高有低，面试面的就是和面试官是否投缘，你会的刚好也是面试官会的，你的观点也刚好是面试官的观点，这样 100%稳了。

搞了一年的运维大部分优化搞的 sql 层面，业务 tob 的。想实战参与下别的手段上点中间件类的奈何没机会。前段基本（老项目）大部分搞点限制条件，渲染批量还是单个，看能缓存不，也有些项目有 bug 的碰到了一个级联多选疯狂请求后台的。

从前端的角度来说一点我自己的理解吧 我几乎每次面试都会被问到这个话题，自己面试别人的时候也很喜欢问 首先从我的经历来看，肯定不是楼上老哥们说的“完全是八股文。面试人喜欢你就会要你， 不会太在意你的回答的。 面试官都是带着答案来问问题的，刚好能说到答案，面试官就会认为你会，很满意，和自己观点相同。” 这个话题一般比较开放，如果面试的是一个比较资深的岗位，期望的答案一般是希望能体现出候选人有渊博完备的知识体系，同时有丰富的实践经验和业务理解 ，最好还能有足够前瞻的技术视野。 比如可以从那个被问烂了的“从输入 url 开始到页面加载完成都发生了什么”聊起，讲一下有哪些流程，每个节点上有哪些优化点，哪些部分分别可以提升加载、渲染、交互的流畅程度，有什么弊端。 再整理一下如何衡量性能，都有哪些指标，监控 & 诊断、数据驱动优化。 业务中遇到了哪些性能问题，如何分析、如何解决，成效如何。 未来展望，比如 HTTP3 、边缘计算，balabala 其实面试中遇到这种题挺好的，完全可以充分体现自己的知识深度广度，更重要的是能耗掉相当多的面试时间。你也不想聊了 20 分钟之后，面试官：我没啥可问的了，我们来一道 3D 接雨水吧？

我之前问类似于这样的问题（往往是配合具体场景），我想要听到候选人谈到的点： 1 、你是怎么发现/识别到性能优化点的？发现问题的方式方法很多，那你怎么识别到是这里需要做性能优化的？ 2 、识别到性能优化点后，你是怎么思考解决的？你做过哪些思考和尝试，怎么体现出深度？ 3 、升华一下，你怎么能避免以后不出现类似的性能问题？你能提炼/总结/沉淀出什么经验