前端面试高频考点整理
前端面试高频考点整理
一进面试间，很多人习惯先在心里默念“我能行”，但真正坐在屏幕前，才发现“行”和“写出来”之间，隔着一道叫“细节”的坎。前端这行看着门槛低，实际上水很深：你会写页面，不代表你能把页面写得稳、写得快、写得容易维护。面试更像是一次“拆机检查”，面试官不只想看你造过什么，更想看你懂不懂为什么这么造、还能不能造得更好。我见过不少候选人，项目写得挺漂亮，可一被问到“页面为什么卡”“接口怎么防重复”“样式怎么不打架”，就开始顾左右而言他。今天不聊空泛的理论，只把那些反复被问、反复被考、反复让候选人栽跟头的高频考点，一个个拎出来掰开揉碎讲。
有一次面试，候选人挺自信，简历上写着“主导大型单页应用重构”。我让他从登录页开始写，他一边敲代码一边说：“这页很简单，校验一下，调个接口，跳转。”结果我让他把“手机号输错时的交互”现场加上，他写了段判断，长度不对、格式不对、正则不对，混在一起，硬是把一个函数堆到四五十行。我问他：“如果明天产品说要加‘是否海外号码’的逻辑，你打算怎么加？”他愣了一下，说“再写个if”。那一刻我就知道，这一关要挂。真正稳定的前端，不是写得“快”的那一瞬间，而是改得起、拆得开、接得住变化的那一套习惯。
别让页面“假流畅”骗了眼睛
性能优化几乎是必考题，但很多人一上来就背“打包要压缩、图片要懒加载、CDN要加速”。这些没错，但不够落地。你有没有见过这样的场景：页面一打开，白屏两秒，然后突然“唰”一下出来，用户还没来得及看清在哪，手指已经下意识往上划了。这种“假流畅”，其实是骨架屏和首屏资源的配合出了问题。我在一次面试里让人分析一个加载很慢的运营页，他张口就说是“图片太大”。我顺手把Network面板打开，让他看真正耗时的请求，结果发现是主包里塞了一个没做拆分的富文本解析库，首屏还没渲染，解析已经跑了三秒。
真正的性能优化，是从“用户第一眼能看到什么”倒推的。比如首屏只保留核心骨架，非关键脚本往后挪，字体加载策略能不能先fallback，关键接口能不能和静态资源并行。更隐蔽的问题是运行时卡顿：列表滚动到一半掉帧，很多人第一反应是“硬件不行”，其实八成是滚动事件没做防抖、渲染层反复重排。我在项目里吃过亏，一个看起来简单的“吸顶导航”，因为频繁读offsetTop，导致低端机上直接掉到十几帧。后来改成ResizeObserver+节流，才稳下来。面试时如果能把这些“坑”当成案例讲出来，比单纯复述优化清单更有说服力。
状态和副作用，是最容易被轻敌的战场
我见过太多把“状态管理”当成背名词的面试：Redux、Vuex、MobX、Zustand、Jotai，一个个列得整整齐齐，真到写代码，却把状态散落在组件内部、props深处、甚至setTimeout的闭包里。有次面试，我让候选人实现一个“购物车数量同步”的小功能：商品页加减，购物车浮层要实时变，刷新后还得记住。他写了一套事件总线，结果一刷新，数据全丢。我问他为什么不存持久化，他反问：“这不就是localStorage吗？”我继续问：“如果用户开了两个标签页，你怎么做同步？”他卡住了。
前端的状态不只是“放在哪”，更重要的是“边界在哪、变更是否可预测”。副作用更是重灾区：定时器忘了清、监听器重复绑、请求回来组件已卸载。我在项目里见过一个典型的崩溃：页面跳转时，有个未完成的请求回来，调了setState，直接白屏。修复加了三行判断，却暴露了设计上的侥幸。面试时如果能聊出“我会把副作用收敛到统一入口，用取消令牌控制生命周期，状态变更走不可变+最小化扩散”，哪怕代码写得没那么炫，也容易拿高分。
样式不是“写出来就行”，而是“协作出来的”
CSS在面试里常被当成配角，可一旦出问题，就是“全线崩盘”。我参与过一次代码评审，一个按钮在A页面正常，在B页面变大，点击热区偏移。追查下来，是全局样式被局部权重覆盖，加上媒体查询断点不一致，最后用!important硬解。样式冲突、命名漂移、主题切换卡顿，这些都不是“多写几行”能解决的。有次面试，我让候选人现场把一组卡片从“左右布局”改成“上下堆叠”，同时保持间距一致。他上来就写媒体查询，我问他如果换成暗黑模式或者字体放大一倍，间距会不会乱，他说“再调”。
真正经得起折腾的样式系统，是有约束的。命名空间、原子化或组件化选择、设计Token落到变量、关键状态用数据驱动而不是写死class，这些习惯让样式从“个人表达”变成“团队资产”。更值得聊的是可访问性：焦点是否可见、语义是否正确、对比度是否达标。一次我把一个“好看但键盘进不去”的页面退回重做，产品经理一开始不理解，直到我让他蒙住眼睛操作一次，他才明白样式不只是视觉问题。
工程和交付，决定你能走多远
前端不只是写页面，更是写交付流程。我见过简历里写着“参与CI/CD建设”的候选人，连分支策略都说不清楚。工程能力的核心，是“让正确的事更容易发生”。比如代码提交能不能自动跑单测、lint、构建，错误能不能提前暴露，而不是上线后报警。有一次紧急发布，因为没做依赖锁，导致某台机器构建产物不一致，整整半小时的故障，回滚后才发现是package-lock没提交。
工程化还体现在“可维护”上：文档是否可查、接口契约是否稳定、降级方案有没有兜底。我在团队推行过“变更影响清单”，每次上线前对照：路由、权限、缓存、埋点、样式域，五个维度过一遍，看似繁琐，实则省下无数半夜救火。面试时如果能聊出“我会把构建按需拆分、按路由拆分，把公共依赖外置，把运行时错误集中捕获并上报”，哪怕只是思路，也比“我会Webpack”要扎实得多。
前端面试，说到底不是考谁会的框架多，而是考谁能把复杂问题拆清楚、把不确定的事稳住、把协作成本降下来。考点会变，场景会变，但那些反复出现的问题——怎么让用户不卡、怎么让状态不乱、怎么让样式不打架、怎么让交付不翻车——永远值得被认真对待。把这些细节当成日常习惯，而不是临时抱佛脚的“面试题”，你会发现，机会不再是被“面”出来的，而是被“做”出来的。