Web开发圈子里有个老梗：前端工程师觉得后端只会写接口，后端觉得前端就是画皮。但真到项目延期、互相甩锅的时候，两边又都说不清楚问题到底卡在哪。
这篇文章用一个盖房子的类比，把前后端的分工掰开了揉碎了讲。读完你会明白，为什么有些网站看着漂亮却慢得像蜗牛，有些功能强大却难用到让人想摔手机。
Frontend：你看到的每一面墙，都是有人精心算计过的
想象你走进一栋房子。墙面什么颜色、沙发摆哪、开关在哪个顺手的位置——这些全是Frontend（前端）的活儿。用户能点、能滑、能骂娘的部分，都归这帮人管。
前端的核心就三件事：别让我等、别让我想、别让我烦。
技术栈倒是不复杂，HTML搭骨架，CSS搞装修，JavaScript塞交互。但简单不等于容易——同一个按钮，在iPhone 12和五年前的安卓机上长得一样、点得动，背后是几百行兼容性代码。
有个细节很能说明问题：前端工程师花在"让设计师满意"上的时间，往往不到三分之一。剩下七成在跟浏览器打架、跟网络延迟妥协、跟产品经理改需求。
Backend：藏在墙里的电线，断了全屋黑
Backend（后端）是另一套叙事。你按开关灯亮了，不是因为开关有魔法，是因为墙里有电线、配电箱、发电机，还有一整套你看不见的响应逻辑。
后端处理的是：谁有权开这盏灯、电费算谁的、如果十个人同时按开关会不会短路。
用户永远感知不到后端的存在——直到它崩了。
登录失败、支付卡顿、推荐算法抽风，全是后端的问题域。这里的技术栈杂得多，Python、Java、Go、数据库、缓存、消息队列，选型直接决定系统能扛多少并发、出事了能不能睡着觉。
原文里那个比喻很准：再豪华的装修，水管堵了也是白搭。反过来，电网再稳，没门没窗的房子也没人住。
为什么两边总是互相嫌弃
前后端的矛盾，本质是两种思维模式的碰撞。
前端活在用户的眼睛里，每一像素都是战场。一个加载动画慢0.3秒，转化率掉5%——这种数据逼着他们追求极致体验。后端活在服务器的日志里，QPS（每秒查询率）、P99延迟、故障恢复时间才是硬指标。
项目延期时常见的一幕：前端说"接口还没好"，后端说"需求又变了"。两边都没撒谎，但问题出在协作的灰色地带。
比如一个搜索功能，前端想做即时联想、拼音纠错、历史记录高亮，后端只给了个关键词匹配接口。这时候该谁妥协？技术上两边都能做，但放错地方，维护成本差十倍。
全栈是个伪命题吗
行业里总有人鼓吹"全栈工程师"，一个人从前写到后。现实是，中小公司确实需要这种角色救火，但真到复杂系统，全栈往往等于"全不精"。
更务实的做法是：前后端各自深耕，但在架构设计阶段就坐一张桌子。API（应用程序接口）怎么定义、错误码怎么规范、缓存策略谁负责——这些"墙里的电线"如果前期没对齐，后期就是扯不完的皮。
原文没提但值得补充的是，现代开发正在模糊这条边界。Serverless让前端能直接写业务逻辑，低代码平台让后端也能拖拖拽拽出界面。但模糊不等于消失，只是分工的颗粒度变了。
一个盖房子的老师傅说过：好房子不是装修决定的，是水电工和设计师能不能听懂对方说话。网站也一样。
你现在的工作，是更靠近用户看得见的那面墙，还是藏在墙里的那根线？如果让你选，你愿意为哪边的故障背锅？
热门跟贴