web全栈工程师

上周帮朋友改一个后台管理系统的登录页，前端 React 组件传参死活对不上，程师后端 Express 路由拿到的栈工是 undefined。我打开控制台，程师发现请求头里 Content-Type 设成了 application/json，栈工但 body 里却塞了个 FormData。程师改了两行代码，栈工问题没了。程师这种事在全栈日常里太常见了——你没法只盯着浏览器或者只盯着数据库，栈工中间那条缝才是程师真正的工作面。

很多人把全栈工程师理解成“前端也会、栈工后端也会”的程师叠加态。不对。栈工我见过前端转全栈的程师人，写 API 时把校验逻辑全扔给前端，栈工结果 Postman 一调就崩。也见过后端转全栈的，页面里塞满 div 套 div，CSS 全靠 !important 硬怼。真正的全栈不是两边都写，而是知道数据从用户点击到落库，中间经过哪些层，每层该信任什么、该拒绝什么。

拿一个实际场景说。用户提交表单，前端做即时校验——邮箱格式、密码强度——这是体验层。但后端必须再做一遍，因为 HTTP 请求可以伪造。数据库层面还得加唯一索引，防止并发写入重复数据。这三层校验不是冗余，是各司其职。全栈工程师的价值就在于，写前端时能想到后端的边界条件，写后端时能预判前端的展示需求。

技术栈的选择上，别被“全栈”两个字绑架。有人用 Next.js 一把梭，API Routes 写业务逻辑，Prisma 操作数据库，部署到 Vercel。这套组合拳打小项目确实快，但遇到复杂事务、长任务队列就吃力。也有人坚持前后端分离，前端 Vue + Vite，后端 Go + Gin，中间用 OpenAPI 生成类型定义。没有银弹，只有权衡。我去年做一个实时协作的看板工具，WebSocket 用 Node.js 写，但图像处理部分单独拆了个 Python 服务——全栈不等于一个人干完所有事，而是能判断什么该合、什么该分。

调试能力比写代码能力更关键。浏览器 DevTools 的 Network 面板、后端日志的 traceId、数据库的慢查询日志，这三样东西要能串起来看。有一次线上用户反馈“保存失败”，前端报 500，后端日志显示数据库连接超时，但连接池配置明明够用。最后发现是某个查询没走索引，全表扫描把连接占满了。这种问题，只懂前端的人会去查请求体，只懂后端的人会去查 SQL，全栈的人会先看请求频率和响应时间分布。

工具链也在变。以前全栈意味着 MEAN 或 LAMP，现在更散。Bun 运行时、Hono 框架、Drizzle ORM、tRPC——新东西层出不穷。但底层没变：HTTP 协议、关系代数、状态管理、缓存策略。花时间学这些，比追新框架划算。我见过有人用 tRPC 写了个全栈应用，但连 REST 和 RPC 的区别都说不清，一旦出问题就抓瞎。

最后说个实在的。全栈工程师容易陷入“什么都会一点，什么都不精”的陷阱。我的建议是：选一个方向做深，比如前端性能优化或者后端高并发，然后把另一侧的知识补到“能独立交付完整功能”的程度。面试时别吹“精通前后端”，直接说“我独立做过一个日活两千的预约系统，前端用 React Query 管缓存，后端用 PostgreSQL 的 advisory lock 防重复预约”。具体案例比标签管用。

这行当没什么神秘。无非是遇到问题、定位问题、解决问题。只不过全栈的人，工具箱里多几把扳手而已。