“前端岗位又双叒叕空出来了。”这是我在季度复盘会上说的第一句话。团队的前端负责人提了离职HR给我推了一沓简历我看了一下午愣是没找到一个能直接上手改样式的人。不是候选人不行是岗位和市面上的人压根对不上。那一刻我脑子里冒出的念头就是标题这句话真的不想再招前端了。这不是气话是前端开发现状逼出来的结论。你打开任何一家招聘平台搜“前端”需求依然一大把你再看看面试现场能聊框架原理的人不少能交付一个不卡顿、不白屏、边界情况处理干净的项目的人却没几个。问题不在某个候选人身上而在整个前端岗位的选拔方式、技术生态和用人思路上。这篇文章我想以一个带过多个前端团队、亲手面试过几百人的技术管理者的身份把这几年在前端招聘、前端开发、前端工程化上踩过的坑和换过的思路一次性讲透。文章不会只是吐槽每一节都会有可落地的解法。适合正在为前端团队发愁的技术负责人也适合焦虑自己“会不会被淘汰”的前端开发还有那些正准备入行的新人——你们需要看清这个岗位的真实水位在哪。1. 先聊聊“不想招”的真正原因岗位供需的结构性错位1.1 简历堆满关键词真正能干活的人却很少我收到的十份前端简历里至少有六份写着“熟练掌握 Vue3 TypeScript Vite”“精通组件化开发”“有微前端实践经验”。结果我一问微前端对方支支吾吾说“看过 qiankun 的文档”。再看项目经历写的是“参与公司后台管理系统开发”再追问“你在里面具体负责什么”“有没有独立设计过组件”“遇到性能问题怎么排查”很多人就接不下去了。这里面有个很扎心的现实前端行业的简历通胀比货币通胀还快。因为前端的入门门槛相对低培训班三个月能批量产出一批“全栈工程师”他们的简历模板几乎一样——Vue/React、小程序、uni-app、组件库、性能优化关键词堆得满满当当。但真正的工程能力比如依赖版本冲突怎么解、打包体积怎么降、内存泄漏怎么定位、跨端适配怎么做这些硬功夫是培训班教不出来的只能靠真实项目喂出来。这不是在否定培训班出来的同学而是想说明一个结构性错配市场需求的是“能解决具体问题的工程师”人才市场上供应的却是“背过题目的关键词玩家”。两边都痛苦招聘方觉得简历筛选像开盲盒求职者觉得面试官总问用不到的东西。1.2 前端工具链的军备竞赛把所有人拖进了内耗前端这个圈子工具链迭代速度快得离谱。我刚入行那会儿一个 jQuery 插件搞定所有交互页面丢到服务器上就能跑。现在呢你打开一个正经前端项目的 package.jsonReact/Vue 全家桶、Vite/webpack、TypeScript、ESLint/Prettier、Tailwind/CSS Modules、状态管理、路由、请求库、组件库……光把这些工具的版本对齐、配置调通就能耗掉一个新人一周的时间。更让人头大的是这些工具很多是重叠的。明明一个 create-react-app 就能初始化项目团队非要自己搞一套脚手架明明 CSS 就能实现布局非要上个 CSS-in-JS 方案。我见过一个老项目为了引入某个新功能硬生生把 webpack 换成了 Vite结果几十个依赖不兼容光修构建就花了三周。你说这三周对业务有任何价值吗没有纯粹是工具链的内耗。这带来的直接后果是面试时“会的东西多”和“能把事情做成”完全变成了两码事。一个候选人可能对 Vite 的插件机制倒背如流但让他排查一个线上样式错乱的问题他可能连浏览器开发者工具里的 Computed 面板都没点开过。工具是手段不是目的但很多人已经搞反了。2. 前端面试的核心矛盾八股文与实战能力的鸿沟2.1 “前端八股文”为什么让招聘越来越难我面试的时候问过自己一个问题那些经典的面试题宏任务和微任务的执行顺序、Vue 的 nextTick 原理、浏览器渲染流程这些知识重要吗重要。但它们能不能预测一个人在实际工作中的表现不能至少不能单独作为评判标准。原因很简单八股文考察的是“记忆的准确度”而前端开发日常工作考察的是“在模糊条件下做决策的能力”。你写一个页面需求是“展示数据支持筛选和排序”但数据量上万条接口返回慢组件还要复用。这时候真正考验你的是是前端做筛选还是后端做列表需不需要虚拟滚动表格列多到横向溢出怎么办这些问题的答案没有标准只有权衡靠背题永远背不出来。更糟糕的是八股文面试正在形成一种逆向淘汰。真正在一线写代码、解决过复杂问题的人往往没有时间刷题他们的知识是“场景触发式”的——遇到问题能想起来平时不会刻意背诵。反倒是那些刚培训出来、每天都在刷面试题的人对八股文对答如流。结果就是你越想通过八股筛出“基础扎实”的人越容易招进一堆“嘴上王者”。2.2 会做事的工程师正被一套过时的筛子滤掉我印象特别深的一个候选人简历写得毫不起眼普通二本毕业在一家小公司做了三年“打杂前端”。面试的时候前半小时聊项目他眼睛是亮的讲他们怎么用 WebSocket 做实时数据推送、怎么在低配安卓机上优化页面性能细节扎实得让人惊讶。结果进入八股环节我问他“事件循环”的执行顺序他卡住了磕磕绊绊说了几句就说不下去。我一度想按流程给他 pass但直觉让我多问了一句“如果让你排查页面卡顿你会怎么入手”他立刻说“先打开 Performance 录一段看是脚本执行时间长还是渲染频繁然后看 Network 里有没有大体积资源阻塞。”那一刻我知道这个人不是基础差他只是不适应这种“把知识从场景里抽离出来”的考试方式。后来我把他招进来了事实证明他确实是团队里最能扛事的人。那个差点被八股筛掉的工程师解决了我们好几个历史遗留的性能问题。这段经历让我彻底反思我到底是在招一个“会背题的人”还是在找“能解决问题的人”答案本来很清楚但一套惯性思维把我们推向了反面。3. 用人策略的三个转向与其再招一个前端不如换个解法3.1 把前端做成“组件工厂”用工程化压缩人力需求先说一个很多人忽略的事实一个成熟的后台管理系统表单、表格、弹窗、筛选器、详情页这几类页面往往占了 80% 以上。如果你的人每天在做这些页面的重复劳动那不是人的问题是工程化缺失的问题。我们团队曾经有 3 个前端维护一个大型后台每个页面都是“复制上一个页面改改”。后来我用一个月时间带着大家做了件“笨事”把项目里出现 3 次以上的 UI 模式全部抽成业务组件。比如“带筛选条件的表格页”我们封装成一个ProTablePage组件传入列配置、筛选表单配置、接口地址页面直接生成。效果立竿见影。原来开发一个新列表页平均要 2 天变成参数配置后半天搞定原来 3 个人忙得团团转后来 1.5 个人就能覆盖日常迭代剩下的人去做真正的创新功能比如数据大屏、数字孪生可视化。这时候你会发现你根本不缺前端你缺的是对重复劳动的洞察力。组件化不是锦上添花是直接把“人力需求”降维了。3.2 让 AI 进开发流2026 年前端团队的新标配这两年“AI 前端 skill”相关的话题热度很高我也从观望者变成了重度使用者。说实话AI 对前端开发的冲击远比想象中来得快。我现在写代码的流程已经变了先让 AI 根据需求生成基础模板我再做 review 和改造重点处理边界条件和交互细节。举几个实际落地的场景。一个是写正则表达式以前写一个“校验手机号座机号分机号”的正则我得翻文档试半天现在直接让 AI 生成我只需要验证边界一个是排查样式问题把布局代码丢给 AI它会指出 flex 布局里常见的min-width缺失导致的换行问题还有一个是生成联调 mock 数据以前写一整套接口 mock 要半天现在描述一下数据结构AI 几秒钟就生成了。这里必须提醒一句AI 生成的代码绝对不能无脑接进项目。我踩过的坑包括 AI 生成的代码没有处理接口异常、没有做防抖节流、请求没有取消机制甚至有一次生成了一个能跑但存在明显 XSS 隐患的富文本渲染组件。AI 是放大器它把你 prompt 里的模糊之处无限放大。所以我的原则是AI 负责提效人负责兜底任何 AI 代码都要走 Code Review。3.3 全栈化转型把“前端”重新定义为“带界面能力的工程师”聊完组件化和 AI还有一个更根本的转向我越来越倾向于把纯前端岗位改成“前端轻后端”的全栈岗位。这不是说要让前端去写 Java 微服务而是要求你懂 HTTP 传输、懂 WebSocket 推送原理、懂接口设计、能排查整个链路上的问题。为什么这么改因为现在的前端项目越来越不“纯前端”了。实时协作工具要处理 WebSocket 消息推送给前端大屏项目要对接多种数据源的接口音视频项目要处理流的传输和播放。我见过太多“前后端对接像两个星球”的团队前端抱怨接口字段天天变后端抱怨前端连 JSON 结构都看不懂。说到底是对整个技术链路缺乏共同语言。全栈化之后一个人从接口设计到页面实现全链路打通沟通成本直线下降。我们最近接的一个数字孪生项目就是把“页面开发数据对接可视化渲染”打包给一个全栈工程师负责交付速度比过去“前端写完等后端”的模式快了将近一倍。对我而言这比再招一个只会写页面的前端划算得多。4. 我踩过的坑与排查实录一个前端项目抢救全记录4.1 快速切换菜单卡死被忽略的内存泄漏有一段时间用户频繁反馈后台系统“快速切换菜单会卡死”。一开始我怀疑是路由组件加载慢让开发换成了异步组件情况依旧。后来用 Performance 录制操作过程发现内存曲线像坐火箭一样往上蹿频繁触发垃圾回收GC页面进入“卡顿—恢复—再卡顿”的死循环。排查到最后定位到一个非常隐蔽的问题某个全局组件在mounted里启动了定时器但没有清理每次切换菜单这个组件实例销毁又创建一个新的定时器却在背后越积越多。说白了这不是什么高深的技术问题就是组件生命周期管理的安全意识不够。解决起来倒不难统一封装useInterval/useEventListener这类 Hooks内部自动注册清理逻辑路由切换时用AbortController取消未完成的请求组件卸载时把所有监听器、定时器、观察者统一关掉。但这类问题很难在面试中暴露因为八股题不会考“你上次是怎么排查内存泄漏的”只有真刀真枪调试过的人才有手感。4.2 大文件上传Web Worker 分片方案的现场复盘另一个让我印象深刻的场景是设计团队反馈“PDF 超过 200MB 上传时 Chrome 直接崩溃”。用户上传的是设计稿原文件动辄几百 MB走普通文件流上传浏览器内存直接被打爆。我们的解法是分片上传用File.slice()把文件切成小块再放进 Web Worker 里做分片计算和哈希处理主线程只负责调度和更新进度条。分片大小我们最后定为 2MB并发数控制在 4 个既能跑满带宽又不至于把服务器打挂。服务端接收完所有分片后按顺序合并每个分片有独立的唯一编号失败自动重试整个传输过程支持断点续传。这里有几个在实际项目中踩过的坑分片太小比如 128KB会导致请求数过多网络往返耗时反而拖慢速度并发数太大比如 10 个容易触发服务端连接数限制还有分片合并时如果服务端没有做好幂等重复上传同一个分片可能导致文件损坏。这套逻辑后来我抽成了通用的上传组件新项目直接复用再也没人因为传大文件把电脑卡死了。4.3 token 内存管理与录屏防护容易被忽视的合规技术细节最后聊两个看起来“小”但坑人不浅的问题。第一个是“前端如何获取内存中的 token”。很多项目图省事把登录凭证直接塞进localStorage但这样一旦页面被注入恶意脚本token 能被直接读走风险极大。更稳的做法是把 token 放在内存变量里模块级单例配合短时效刷新策略刷新页面时通过一个专门的恢复接口拿新 token而不是把凭证持久化到本地存储。第二个是移动端“防录屏”的需求。有些项目因为内容版权或者数据合规要求需要限制用户在 App 内录屏这本身是一个严肃的技术与合规边界问题。我需要先强调防录屏的目的是保护正当的数字内容权益绝不能用于隐藏违法违规信息。技术实现上可以监听录屏行为并做出提示也可以对敏感页面做动态水印或禁止截屏的配置但这一切都要在法律允许的范围内且必须提前告知用户。这两个问题对应的能力——对安全边界的理解、对合规意识的敬畏恰恰是我现在面试前端时非常看重的加分项因为它们没有标准答案只有一个人的工程素养和责任心。5. 如果再给我一次组建前端团队的机会我会怎么做5.1 实战型面试拿一台笔记本改三个真实 bug我现在面试前端已经完全取消了纯八股环节。取而代之的是“三个真实任务”上机考核总共 90 分钟场景全部来自我们项目脱敏后的真实问题。第一个任务给一个列表页增加搜索功能要求防抖、处理 loading 状态、接口错误时要展示空状态。这考察的是基础开发习惯第二个任务一段代码有明显的内存泄漏让你找出并修复。这考察的是调试能力和性能意识第三个任务给定一个 JSON 接口文档让你设计前端的类型定义和数据管理方案。这考察的是对数据流的理解。这套题设计出来之后效果比预期好得多。真正写过代码的人做得快、思路清晰、还会主动问边界情况而那些只会背题的人面对第一道题就开始手脚发麻。面试的意义不是刁难谁而是让候选人在最接近真实工作的状态里展示自己同时让我们看清楚他的上限在哪。5.2 内部标准与 Code Review小团队也能建立工程文化团队人越少越需要标准因为每个人都在互相维护对方的代码。我现在的做法是精简到“三个必须”目录结构必须统一组件必须走组件库前端请求必须走统一的封装层。这些标准不是我从网上抄来的是从过往项目重构里长出来的。比如我们发现总是有人把接口请求散落在组件里于是定了一个规矩“所有请求必须写成独立的 API 模块组件里只调函数。”Code Review 的节奏也要刻意设计。我们规定小步提交、当天合入、问题不过夜。每个 PR 必须有两个人的 review 才算通过。刚开始大家觉得繁琐习惯之后反而离不开了——因为每个人都在 review 里学到了别人的写法错误模式被反复纠正后代码质量有了肉眼可见的提升。工程文化从来不是靠文档堆出来的是靠一次次的 review、一次次的修改、一次次“这个问题我上次也遇到过”磨出来的。5.3 低代码与 AI 的辩证认知工具负责省力人负责判断说到低代码平台很多前端一听就抵触觉得这是在革自己的命。我的看法是低代码确实是“一部分重复前端的终结者”但恰恰是把另外一部分前端推向了更高价值。企业内部系统、报表平台、审批流页面这些逻辑固定、交互简单的场景用低代码确实快但真正复杂的前端——高性能可视化、实时协作编辑、跨端体验优化——低代码根本碰不了这些恰恰是稀缺能力。AI 辅助也是同理。它淘汰的不是“前端程序员”而是“只会写模板代码的前端操作工”。未来的优秀前端一定是很会定义问题的人能把模糊需求拆成清晰的交互模型能判断 AI 生成的代码是否有安全问题能有意识地在用户体验和性能之间做权衡。工具负责省力人负责判断这个定位我和团队反复对齐过。最后我还是会招前端的写到这里也许你会觉得我是在唱衰前端但其实恰恰相反。正是因为我理解前端开发的现状和痛点我才更明白问题不在“招不招前端”而在“用什么样的标准去招、拿什么样的方式去带”。我个人在实际操作中最深的体会是当我停止用“面经八股”去评价一个前端开始用“你能不能把一个模糊需求落地成一段干净可靠的代码”来衡量时可选的候选人范围反而变大了。而当我花时间去搭组件库、去训练团队的 AI 辅助流程、去推动前后端一体化之后团队里每个人的单位产出都在变高那种“永远缺人、永远在救火”的恶性循环才有机会被打破。如果你也正为前端招聘头疼我的建议很直白别急着加 HC先把你的面试流程改成实战题把你的重复业务代码封装成组件再认真研究一下 AI 能帮你省掉哪些边际工作。你会发现你真正缺的可能不是人而是一套更适配当下的前端生产力体系。这套体系搭起来以后招人的质量、迭代的速度、团队的稳定性都会进入一个正向的循环。