在这个圈子摸爬滚打这么久，我听过最多的一句吐槽就是：前端不就是画画页面，调调接口吗？有什么难度？
很多写后端的兄弟，看着前端用各种脚手架两分钟就能搭出一个漂亮的管理后台，往往会产生一种错觉：前端的门槛极低，随便拉个会写 HTML 的实习生就能干。
如果你只是接个外包，写一个永远只有三个人访问的内部汇报系统，那前端确实简单。但如果你负责的是一个日活百万、牵扯到复杂交互和实时数据流转的商业系统，那么前端面临的工程复杂度，绝对不亚于后端的分布式事务。
前端和后端的难，根本不在同一个维度🤷♂️。
后端的难，难在数据规模🫵
后端的代码，运行在什么地方？ 一般跑在极其稳定的 Linux 容器中。服务器的 CPU 是多少，内存有几个 G，网络带宽有多大，一切都是绝对可控 的。如果性能遇到了瓶颈，后端的标准解法是清晰的：加机器、上缓存、分库分表、削峰填谷。
而后端的代码，面临的是一个极其稳定的环境。
但前端呢？前端的代码，是被打包成一坨 JavaScript 混淆代码，直接投到了各种各样的浏览器环境里。
你根本不知道你的代码，是跑在最新款的 iPhone 17 Pro 上，还是跑在十年前那台屏幕都碎了、只有 2G 内存的低端安卓机上。
后端的系统是封闭且稳定的，而前端的运行环境是不可控的。
在前端的深水区里，我们有 80% 的精力，根本不是在写业务逻辑，而是在对抗这种极其恶劣的浏览器宿主环境🫡。
脆弱的请求与失控的竞态？
就拿最简单的 切换 Tab 加载数据 来说。
在后端的视角里，你只要把 SQL 写对，把 JSON 吐出去就完事了。但在前端的真实工程现场，这就是一个不可控的场景。
初级前端会怎么做？用户点击 Tab A，发起请求 A；用户再点击 Tab B，发起请求 B。
如果这是在弱网环境下，请求 A 因为网络抖动，比请求 B 回来得还要晚。那么在用户的界面上，明明他当前停留在 Tab B，但屏幕上渲染出来的，却是 A 的脏数据。这就是前端极其经典的请求竞态（Race Condition）。
如果你不管不顾，任由这种脏数据污染浏览器的内存，轻则导致页面错乱，重则直接引发资金类的显示故障。
运行环境的不可靠
很多后端工程师无法理解，为什么同样是一段标准的逻辑，在本地跑得完美无瑕，一上线就全盘崩溃？
因为后端的代码，永远运行在极其纯净的、与世隔绝的 Docker 容器里，没有人能在这个容器里随便插手。但前端的代码呢？它运行在成千上万中不同的浏览器运行环境里。
用户可能装了 15 个极其流氓的 Chrome 插件。有的插件会静默拦截你正常的网络请求；有的翻译插件会强行篡改你页面上的 DOM 节点，直接导致你的 React 虚拟 DOM 树比对失败，整个页面瞬间白屏崩溃。 或者，你的页面被强行嵌在了一个极其简陋的国产安卓 App 的 WebView 里，这个 App 的底层竟然擅自重写了 JavaScript 的原生标准 API，让你的标准函数直接报错😖。
当线上出现诡异的白屏时，后端看一眼日志说：接口没问题，数据都下发了。
这个时候，前端架构师在一堆毫无规律的报错里，一个一个去排查是不是用户的广告拦截器（AdBlock）误杀了核心的业务 JS 文件，或者是某个不知名的安卓浏览器不支持最新的 ES 语法规范。
前端的工程能力，本质上就是在写各种各样的兼容性代码。 你必须假设你代码运行环境充满了不确定性、篡改或者不可靠，然后在这个不靠谱的环境里，硬生生地构建出一个看似完美的业务系统。
不要用语法，去衡量工程深度
为什么很多人觉得前端简单？因为所有的脏活累活，都已经被 V8 引擎和各种现代框架在底层默默解决掉了。
你以为的简单，是因为高人帮你屏蔽了浏览器的渲染管线、宏任务微任务的调度机制、以及 CSSOM 与 DOM 树合并时的重排流程。
后端解决的是系统深度和数据一致性 的问题，前端解决的是环境多样性和人机交互边界的问题。两者在工程的难度上，原本就是两个不同维度的。
所以别再争论谁难谁简单了。如果一个写后端的看不起前端，说明他根本没见过真正复杂的客户端架构；如果一个写前端的觉得自己比后端牛，说明他根本没经历过一次 P0 级的线上数据熔断。
你们说是不是呢？
