我为什么说全栈正在杀死前端？

大家好，我又来了🤣。

打开2025年的招聘软件，十个资深前端岗位，有八个在JD（职位描述）里写着：“有Node.js/Serverless/全栈经验者优先”。

全栈 👉 成了我们前端工程师内卷的一种方式。仿佛你一个干前端的，要是不懂点BFF、不会配Nginx、不聊聊K8s，你都不好意思跟人说你是资深。

我们都在拼命地，去学Nest.js、学数据库、学运维。我们看起来，变得越来越全能了。

但今天，我想泼一盆冷水🤔：

全栈正在杀死前端。

全栈到底是什么

我们先要搞清楚，现在公司老板们想要的全栈，到底是什么？

他们想要的，不是一个T型人才（在一个领域是专家，同时懂其他领域）。

他们想要的是：一个能干两个人（前端+后端）的活，但只需要付1.5个人的工资。

但一个人的精力，毕竟是有限的。

• 
  
• 当我花了3个月，去死磕K8s的部署和Nest.js的依赖注入时，我必然没有时间，去研究新出炉的INP性能指标该如何优化。
  
• 当我花了半周时间，去设计数据库表结构和BFF接口时，我必然没有精力，去打磨那个React组件的可访问性，无障碍（a11y）和动画细节。
  

我们引以为傲的前端精神，正在被全栈的广度要求，稀释得一干二净。

全栈的趋势，正在逼迫我们，从一个能拿90分的前端专家，变成一个前后端都是及格的功能实现者。

关于前端体验

做全栈的后果，最终由谁来买单？

是用户。

我们来看看全栈前端主导下，最容易出现的受灾现场：

1.能用就行的交互

全栈思维，是功能驱动的。

数据能从数据库里查出来，通过API发到前端，再用v-for渲染出来，好了，这个功能完成了😁。

至于：

• 
  
• 列表的虚拟滚动做了吗？
  
• 图片的懒加载做了吗？
  
• 按钮的loading和disabled状态，在API请求时加了吗？
  
• 页面切换的骨架屏做了吗？
  
• 弱网环境下的超时和重试逻辑写了吗？
  
• UI测试呢？
  

抱歉，没时间。我还要去写BFF层的单元测试。

2.无障碍，可访问性（a11y）

你猜一个全栈，在用 <div> 还是 <button> 来实现一个按钮时，会思考 aria-* 属性吗？他会关心Tab键的焦点顺序吗？

根本不会。

因为可访问性这个东西，是纯粹的纯前端范围，它不属于全栈能力范围。

3. 性能优化

当一个全栈工程师的注意力，被数据库索引、Nginx缓存、Docker镜像大小给占满时，他还有多少脑容量，去关心LCP、CLS、Tree Shaking、Code Splitting？

useMemo？PureComponent？能跑就行了，别搞那么复杂。

前端，正在从用户体验的第一负责人，被降维成了全栈流程的最后一个环节——那个把数据显示出来UI就行。

一个前端的专业性

最让我发慌的，是一种风气的转变。

五年前，我们团队，会为一个如何把白屏时间再减少100ms的议题，在白板前吵一个下午。我们会为该用padding还是margin来实现间距 这种像素级的细节，在CR（Code Review）里吵架。

现在呢？

CR时，大家都在聊：你这个BFF的Controller层，不该写业务逻辑、你这个数据库类型定义不规范。

没人再关心那个前端按钮逻辑了。

全栈，正在杀死前端的专业性。它让前端这个职业，变得不再纯粹，不再专注一个领域。

我不想做全栈开发😠

聊了这么多，我不是在贩卖焦虑，也不是在抵制学习后端知识。

作为8年老前端，我现在给自己的定位是：一个T型前端工程师。

我必须是团队里，对浏览器渲染原理、JS性能优化、CSS布局、组件化架构、可访问性理解最深的那个人。这是我的前端身份，是我的技能。

我懂Node.js，是为了能和后端吵架时，提出更合理的BFF接口设计。

我懂Docker，是为了能理解我的代码，是如何在CI/CD上闪退的。

我懂SQL，是为了能理解为什么我的一个查询，会导致查询慢。

请大家别再神话全栈了😒。

全栈的尽头，很可能是全废了，这个也不精，那个也不精。

我宁愿要做一个95分的前端专家，和一个95分的后端专家，让他们强强联手；

也不想要两个及格的全栈工程师，最终交付一个50分的、能跑就行的垃圾代码💩。

欢呼大家，尊重前端这个职业的专业性。

谢谢🙌