说实话，做了三年多全栈工程师，我越来越觉得'全栈'这个词哪儿不对。 刚开始学的时候，觉得前后端通吃很酷，但真正第一个项目就翻了车。那是一个内部后台系统，我用React搭前端，Node写API，本来图省事，结果到后期发现，光是接口字段就改了十几遍，前端要适配，后端也要同步改，每次改动都得花半天。 后来拆成两个团队，前端归前端，后端归后端，反而舒服多了。
总有人喜欢把全栈理解成什么都会写：HTML、CSS、JS、Node、Python、MySQL、Redis、Docker、K8s... 但你真能在这些领域保持深度吗？ 我认识一个所谓的全栈，简历上写着一堆，连TCP三次握手都说不明白。现代工程早就不是当年一个人写个动态网站那么简单了。 你可能会用Next.js，知道它做了SSR和静态优化，但你知道为什么它比纯React慢？因为每次构建都要跑React Server Components的编译，加上Tailwind扫描所有模板文件，构建时间直接翻倍。 我实际测试过，一个中等项目，从Webpack换到Turbopack后，冷启动大概从4.2秒降到了1.1秒，但内存占用却涨了差不多500MB。别只信那些吹性能的博客。
我觉得全栈真正的坑，不是技术广度，而是上下文切换成本。 你可能前一个小时还在调试CSS的flex布局，下一个小时就要去看SQL执行计划，脑子得在两种完全不同的思维模式里跳来跳去。 我读过一个报告，说工程师被打断后平均要花10到20分钟才能重新进入专注状态。你想想，一天切换到十几次，一整个下午就没了。 所以后来我给自己定了个规矩：上午只做前端，下午只做后端，遇到跨层问题宁可加班也不想来回切。这不是效率，这是自我挽救。
那全栈没救了吗？也不是。我觉得真正有意义的全栈，是掌握一条链路上的核心逻辑，而不是所有工具。 比如你理解HTTP，你就知道为什么服务端渲染时要把fetch放在组件里而不是外面；你理解数据库索引，你就知道为什么接口慢要先看慢查询日志，而不是急着加缓存。 我现在的做法是：用BFF层做数据聚合，前端只管UI，Serverless函数处理边缘逻辑，数据库方面只用最基本的连接池，别整太多花活。 这套组合让我在一个人做项目时，能把80%的精力放在用户体验上。至于运维？我选择外包给云平台，虽然贵，但值。
说到底，全栈不是一种身份，而是一种局限——你永远不知道你不知道什么。 承认这一点，反而能静下心来把一个点做到能用的程度。如果你问我下个项目还会不会全栈上？我大概率会，但会先写个大清单，把要用的技术划掉一半。 全栈？能写好一头就不错了。
