2024年畅销书《深入浅出Vue(1)，2024年最新Web前端面试及答案

本文链接：https://blog.csdn.net/2401_84434331/article/details/138915407

专业技能

一般来说，面试官会根据你的简历内容去提问，但是技术基础还有需要自己去准备分类，形成自己的知识体系的。简单列一下我自己遇到的一些题

HTML+CSS
JavaScript
前端框架
前端性能优化
前端监控
模块化+项目构建
代码管理
信息安全
网络协议
浏览器
算法与数据结构
团队管理
开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

最近得空把之前遇到的面试题做了一个整理，包括我本人自己去面试遇到的，还有其他人员去面试遇到的，还有网上刷到的，我都统一的整理了一下，希望对大家有用。

其中包含HTML、CSS、JavaScript、服务端与网络、Vue、浏览器等等

由于文章篇幅有限，仅展示部分内容

感谢主管的培养和信任，给了我很多试错空间，入职到现在这半年时间从第一次当PM到现在，犯了很多错误，在一次次犯错后也学习到了很多当Project Manager的知识，本小节将这些成长总结起来分享给大家。

▐ 解决合作阻碍

在推进项目时，有时会遇到一些阻碍，例如：不配合，难合作，主动性差等问题。绝大部分能来到阿里工作的同学不会是“能力”或“态度”问题，所以大部分阻碍可以归结于：

信息不一致
目标不一致
优先级不一致

解决障碍，就是在解决以上这三点**，信息不一致可以靠“沟通”和“换位思考”解决，而“目标不一致”和“优先级不一致”可以靠“上升”解决，**只要事情足够重要，给出几种解决方案，上升到某个级别问题一定会被按照最合理的方案解决。

▐ 建立自己的权威

入职大概三个月左右的时候，我发现PD（产品经理，在阿里巴巴我们称为 Product Design，即：“产品设计”）在与我合作的过程中对我是有点不信任的，例如：相同的答案PD会相信我师兄和主管、我给了方案后PD会再去找我主管询问是否有更好的方案等。这也让我有了很多成长，当时我还特地去向二级主管请教一些方法。

拉人佐证自己的判断

案例一：在没有建立起自己的权威前，很多时候PD并不相信我给出的方案。那么这种情况解决方案是：假设有3种方案，将各自的利弊信息同步给PD后，如果都不满意，可以拉其他人，例如拉自己的主管进来，佐证自己的判断。（但前提是自己要做好功课，先和主管沟通好达成一致，再将信息同步给PD）。

案例二：假设现有两种方案各有利弊，完美的方案需要团队A配合，那么可以拉着自己的PD去和团队A的PD谈（前提是要先和自己的PD达成一致，并且以自己为主导拉PD只是来佐证自己的判断），一方面向团队A的PD佐证自己提的需求是重要的，另一方面也可以向自己的PD佐证这个需求确实没那么简单。如果事情推进遇到阻塞，回到“解决合作阻碍”小节，最终问题一定会被解决。

拉主管进来是为了佐证自己的判断，而不是和PD一起把复杂问题抛出去。

拉主管佐证要先沟通好达成一致，不是突然把主管拉进来佐证自己，避免主管的判断和自己不一致当场被打脸

资源不足而PD说我都要怎么办？

先和主管达成一致，客观评估需求是否真的重要到需要拉其他同学来帮忙开发，在一个更宏观的角度评估哪个需求优先级更高，然后再给PD同步结论，如果不接受拉主管进来还是相同的结论，再不接受再拉主管的主管也是相同的结论。权威就是在日常这样一点点建立起来的。

与PD合作的艺术

回到最初的问题，PD为什么要找我主管寻求帮助？

她想把事情更好地推进下去
她觉得找主管会有更令她满意的方案

本质上是我还没有建立起自己的权威，另外PD是信息弱势方，所以如果我给出的方案她不满意时，她会去找她更信任的人寻求帮助看是否有更好的方案，那么如果这时真得到了一个更满意的方案，那么她会觉得这招管用下回还会再去，这时候我的权威就会崩塌。

解决方案是：提前做功课给到PD的信息永远是权威的判断，在不信任自己时拉人佐证自己的判断是对的，或者和PD一起去找其他人继续推进&解决问题，逐渐让PD意识到即便是找了其他更信任的人也会得到相同的结论，我的结论就是正确且权威的。

积累自己的信用

作为新同学，可能会发现同一件事，同一个解法，PD经常会不信任新同学。

这里日常工作本质上是累积信用和消费信用的过程，解决方案是：在日常工作中一点点累积自己的信用，当机会来临要勇于消费信用去推动事情，这也是体现“此时此刻，非我莫属”的阿里巴巴价值观。

当然，打了败仗，信用也会消耗，经常打败仗即便不是新同学也很难让人信任，所以还是要靠自己的本事来积累信用并建立权威。

▐ 项目风险同步

这半年时间，关于风险同步我犯过两次错误，这两次错误也分别让我学到了两种关于项目风险的经验。

风险同步：Case 1

事情发生在今年的88大促，当时我为会场底层渲染架构全新升级了一版，在一个极短的时间用新开发的2.0追上了正在运行的1.0的大部分功能，然后在88大促切换到2.0，可以类比在天上给飞机换引擎。切换2.0后如预料中的一样，出了一些小问题。

问题在于，给飞机换引擎这个动作和行为，我没有通知给业务方，导致出了问题的时候，业务方很惊讶，为什么之前一直好好的这次突然出了这么多问题？业务方对这个事没有任何预期。

在这件事上，我学到的是：**在做一件事时，要通知到所有可能会因为这件事而受到影响的人，把自己的计划，方案，风险等信息完全同步给可能会受到影响的人，**好处是：

人多力量大，如果方案确实不成熟，有漏洞大家可以一起完善提高稳定性
大家都知道这件事，而且计划、方案、风险、预案都得到了大家的认可，即使真的出问题也不会给大家“惊喜”

风险同步：Case 2

事情的背景是，有一次我负责一件事，这件事在过程中我发现进度有延迟的风险，但当时我选择了自己抗下来，加加班，赶赶进度。后面我低估了这件事的严重性，导致最后实在扛不住了才暴露风险，紧急加人解决了这件事，虽然这件事没引起问题，但是这个最后临门一脚才暴露风险这个行为是不对的。

通过这件事，我也学会了如何做事是对的（感谢主管孜孜不倦的教导），**暴露风险不是懦弱和能力不行的体现，暴露风险是一个PM的专业素质，**不要自己硬扛风险和压力，过程中有风险需要帮助应及时提，避免到最后扛不住才将风险暴露出来。

▐ 误区：不敢上升和暴露风险

新人入职都会进入一个误区：

为什么我负责的项目，大家都在争论不休，是不是我能力不行？
为什么我负责的项目，好多事我都解决不了需要靠更高级别的同学来拍板，是不是我能力不行？
为什么我负责的项目，又又又又有风险了，是不是我能力不行？

现在我可以很明确的告诉大家，不是，完全不是！

推进项目受阻有很多原因，绝大部分都不是自己这个位置能解决的，上升是非常高效的解决方案。

项目遇到风险也是同样的道理，除了确实是自己能力导致的风险以外，绝大部分风险都是客观存在的事实，和自己能力没关系，即时且充分暴露风险寻求资源解决风险才是王道，这反而是一名专业的PM应该具备的基本素质。

PM的职业素养

PM的目标只有一个：“确保项目按时保质上线”，但过程也同样重要，阿里巴巴有句土话我很喜欢：没有过程的结果是“垃圾”，没有结果的过程是“放屁”。

在推进项目的过程中，一名合格的PM需要具备的基本素养是：

拥有Owner的心态
做关键技术决策
充分暴露风险
调动能调动的一切力量

内心时刻铭记一句团队内广为流传的名言：所有关于事的困难可以靠坚持解决，所有关于人的困难可以靠换位思考解决。

▐ 关于情绪控制

项目复杂且生产关系也复杂的时候，会遇到各种困难和阻塞。沟通工作时很容易情绪失控，但身为一名合格的PM，任何时候，不应该被情绪控制自己的判断。

任何时候，都应该基于客观事实理性分析问题，不应该带有主观的执念。

这也是未来我要加强训练的一点，过去这半年，我经常情绪失控，未来我会克服这一点，做一名专业的Project Manager。

▐ 关于方案评估

评估某个方案是否可行，不应该只是评估技术上是否可行，还要考虑按照这个方案推进后，会带来怎样的影响。

关于这点我曾犯过一次错，在技术方案的评审上，我只判断了技术的可行性就同意了某个方案，但是我没有考虑按照这个解决方案推进后会带来很大的其他影响。后面我师兄及时制止了这件事的发生，但是已经答应了PD按照某个方案推进结果又反悔，对于我这种新人甚至是我们团队在PD心中，都是非常消耗信用的一件事**，“积累信用可能需要好久，但消耗信用，仅仅只是一次无意间的失误”，**要珍惜自己的信用，“信用”，才是PM推进事情时的通行证。

▐ 避免无意中踢皮球的情况

客户（运营、产品、其他人）有疑问来向自己咨询的时候，即便不是自己负责的域，也不要直接和客户说你去找谁谁谁。正确的做法是先把问题揽下来，然后团队内部找对应的同学拉个群解决。

我就曾遇到过这种被踢皮球的情况，我有疑问找了A，A说让我找B，B让我找C，C说他不负责这事，然后我直接找了他们共同的主管，问题解决。