前端做全栈就是容易出问题？聊聊最近抬头的鄙视链

最近 React Server Components 和 Next.js 接连曝出安全漏洞，社区里又有人说："你看，前端做后端就是容易出问题。"

这话让我想起自己刚做全栈时踩的坑。

日志清理？没配。完全靠健康检查销毁重建来"清理"磁盘。

这些对后端来说是常识，但对当时的我来说，完全是盲区。

我是怎么过来的

很幸运，我有一个项目，从日调几千做到上亿。从协议转换，慢慢长成业务网关。

单核QPS提升10倍，亿级日调用！QQ频道前端网关升级之路

这个过程给了我从 0 到 1 的机会——有足够的空间去试错、去踩坑、去复盘。

遗憾的是，很多人没有这个机会，一上来就面对重要的生产项目，没有犯错的余地。

只有付出心血，在犯错中、在大量细节中提炼出来的知识或技能，才能形成深度。

深度是一幅精美的山水画：阳光的倒影，风中的树叶，无人关注的边角一笔笔勾勒的小草。———— 你欣赏的其实是背后的心血，十年磨一剑的积累。

再精美的山水画，也会随时间褪色

曾经熟练的技能，疏于使用或切换领域时的思维惯性，都可能让你犯下低级错误。

就在最近，还写了一个扫全表的 select。虽然是 AI 生成的，但问题是我没意识到要 review 这一点——连写了几个月前端，思维没转过来。

前端和后端确实存在思维方式的差异。

前端习惯"拿到数据就渲染"。后端习惯"先想想这条查询会不会搞崩数据库"。

这不是谁对谁错，是长期工作形成的直觉不同。

跨领域踩坑，除了知识欠缺，也还有思维惯性。

微信的全栈文化

在微信推全栈，会发现很多问题犯得很低级。

但同时盛行复盘文化。踩完坑，复盘，下次就不会再犯。最后总会跑出一些很强的个体。

而这些 top，贡献了 80% 的技术深度。

我的很多文章，也是平时复盘攒出来的。

要不要推全栈

对个人，我觉得是好事。我一直把"独立完成一个产品"作为目标。

对团队，是一个权衡。但我想说的是，全栈的价值不只是"一个人干两份活"。

全栈能做出更优的决策

举个例子：一个页面需要同时展示用户信息和登录记录，后端应该提供一个接口还是两个？

纯后端视角：两个资源，拆开提供，方便解耦。

纯前端视角：能一个请求搞定的，绝不想发两个。

但如果你同时理解前后端，答案会更清晰：

• 如果两个请求可以并发，拆开更好——前端并发请求，更快渲染
• 如果两个请求有依赖只能串行，合并更好——减少一次网络往返

这种判断，需要同时理解前端的调用方式和后端的数据模型。

前后端分离的困境

分离带来了分工，但也带来了问题：

困境一：阻碍代码向最优方式演进。 后端的数据模型、前端的调用时机、数据如何展示，需要综合考虑才能达到 1+1 > 2。分离之后，这种综合考虑变得困难。

困境二：鼓励了跨项目的代码重复。 后端写了校验逻辑，前端为了即时反馈又写一遍。简单校验还好，复杂校验就是双倍困难。后端不会主动关心前端是否重复了自己的逻辑——除非前后端是同一个人。

困境三：无法给 AI 提供完整的上下文。 在 AI 辅助编程的时代，代码生成的质量取决于 context 的完整度。前后端分离意味着 AI 只能看到一半的图景——要么不知道数据从哪来，要么不知道数据怎么用。全栈项目能给 AI 更完整的 context，生成的代码质量更高、效率更高。

全栈的价值，就在于能跨越这条边界，从整体视角做出更优的选择，不管是给人，还是给 AI。

前两个观点我写在四年前，现在依然没变。第三个是 AI 时代的新困境。

但前提是

• 团队人才密度够高，能扛得住跨领域踩坑的阵痛
• 有完善的质量保障体系，不会因为踩坑导致生产事故

在微信，这两个条件是满足的。

写在最后

回到开头的话题。

React/Next.js 出了安全漏洞，就说"前端做后端容易出问题"——这个归因太草率了。

Log4j2 出了满分漏洞，没人说"Java 做后端容易出问题"。

安全问题是复杂度问题，不是身份问题。 新范式、新框架，踩坑是必经之路，和前端还是后端没关系。

前端做后端会踩坑，后端做前端也一样。

问题不是"要不要跨领域"，而是有没有试错的机会，踩完坑能不能复盘，复盘后能不能不二过。

鄙视链没有意义。共勉。