web全栈

凌晨三点，我盯着屏幕上那个500错误，咖啡已经凉透了。问题出在用户登录后跳转的接口上——前端说参数没问题，后端说字段对不上，数据库说你们俩谁先查查我？

这就是web全栈的日常。你一个人要扮演三个角色，还得在它们互相甩锅时当裁判。全栈不是会写几行JavaScript再碰碰MySQL那么简单，那是旅游打卡式的学习。真正的全栈是你在生产环境里，能沿着一次请求从浏览器到服务器再到磁盘，每一步都清楚发生了什么，并且能在任意一层修bug。

我见过太多自称全栈的简历，项目里堆着React、Vue、Node、Python、MongoDB，像调料架一样琳琅满目。可真上线时，用户头像加载不出来，他只会刷新页面。问他：“你看Network面板里那张图片请求返回什么状态码？”他愣住：“什么Network面板？”

全栈的核心不是技术栈广度，是问题定位的深度。就像医生不能只会开药，得会看化验单、能读CT片、敢下诊断。去年我给一个电商小程序做性能优化，页面首屏要3秒。前端说图片太大，后端说接口太慢，运维说服务器带宽不够。我花了一下午，用浏览器DevTools看加载瀑布图，发现是某个字体文件阻塞了渲染，而那个字体只为了一个图标。删掉后，首屏1.2秒。

这种问题，纯前端可能不会去看服务器日志，纯后端可能不会去点开浏览器调试器。全栈的“全”，恰恰是这种跨层的嗅觉——知道问题可能藏在哪，然后直接走过去掀开盖子。

当然，全栈也有代价。你得接受自己永远学不完。今天刚熟悉了Kubernetes的伸缩策略，明天前端框架又出了新特性。我现在的策略是：核心链路深挖，边缘技术随用随查。比如我用Node写中间件，但不会去背EventEmitter的所有API——真用到时查文档，比死记硬背高效。但HTTP状态码、浏览器缓存机制、SQL索引原理这些地基，必须烂熟于心。

身边有些同事喜欢分“前端派”和“后端派”，互相调侃对方的技术是“玩具”。我倒觉得，全栈的价值在于“翻译”。产品经理说“用户点完按钮要立刻有反应”，前端说“那得加个loading状态”，后端说“我接口优化到200毫秒以内”，数据库说“我加个索引就能快三倍”。全栈听得懂所有人说话，还能把需求拆成各层都能执行的任务——这活儿，技术含量不在写代码，在拆解问题。

写到最后想起上周帮朋友排查一个诡异bug：线上订单偶尔丢失，但日志里没有报错。我从前端提交逻辑查到后端事务，最后发现是nginx的默认超时时间太短，长请求被掐断后前端重试，导致重复数据覆盖了原记录。改一行配置，解决了。朋友问：“你怎么想到是nginx？”我说：“因为前面全查遍了，只剩它没查。”

全栈就是这么回事——不是样样精通，是出问题时，你愿意一层层往下挖，直到挖到那个最不起眼的石头底下。然后拍拍手上的土，跟队友说：“就这儿，补个判断就行。”

(责任编辑：综合)