后端Leader放话：“你们前端算个什么？”，我直接怒了[特殊字符]从零基础到精通，收藏这篇就够了！

最新推荐文章于 2025-11-26 15:59:01 发布

原创最新推荐文章于 2025-11-26 15:59:01 发布 · 707 阅读

21 ·

CC 4.0 BY-SA版权

文章标签：

#前端 #web安全 #学习 #网络 #csrf #安全

“你们前端算什么？不就是切图仔？”。当后端Leader甩出这句话时，作为前端开发者，我已经在项目中见过无数技术上的争论，但这一次的冲突，真的是让我彻底爆发了。

我先是一愣，紧接着，我直接怒喷了：“你问我前端算什么东西？现在我就告诉你！后端做不了的我前端做，后端做得了的我前端更要做，先斩后奏，CTO特许，这就是前端！ ”

整个会议室静默了几秒，大家的目光都集中在我身上。是的，我当时情绪激动，但实话说，这场冲突背后我真是一点错没有。

😤【事件背景】

需求：

一切都源自我们这个项目的需求——实时消息通知。我们需要实现一个用户可以实时接收设备消息的功能，设备发送的最新信息，用户不需要刷新页面，就能看到新的消息。
前端观点：

作为前端开发者，我自然知道，SSE是最适合的技术。它可以通过一个持久连接推送数据，实时性高，不用频繁请求，节省带宽和服务器资源，尤其适合我们这种需要实时获取信息的场景。

我早早地提出了使用SSE的建议，认为这是最符合需求的技术方案，既能保证用户体验，又不会给服务器带来过大的负担。
后端观点：

后端一听就开始摆出技术顾虑：“SSE不稳定，长连接会带来巨大的服务器压力，万一用户掉线了，怎么恢复？轮询反而更简单、更稳定，服务器也能更容易控制。”

后端的另一个舔狗，似乎觉得前端的需求不过是“小打小闹”，直接说：“你们前端不就是做点页面展示，搞得这么复杂干嘛？们前端总想着搞些花里胡哨的东西。”

后端语录：

“轮询怎么了？微信早期也是轮询！”

“页面加载3秒很慢吗？我们接口200ms返回已经很快了啊！”

“你们整天搞虚拟滚动，不如让用户少发点消息！”

“这个数据为什么没缓存？你们前端不会用localStorage吗？”
无奈妥协：

这种话听得我简直气炸了。可是领导要求尽快上线，我也懒得理他们，再和产品商量了之后，临时采用了每秒轮询一次的做法，尽快上了线。
线上问题：

上线第二天，刚到公司，后端Leader就发来一张服务器告警截图，说请求量爆炸，让我查原因。我一看就知道：轮询导致服务器压力变得越来越大，响应时间也在逐步增加。更糟糕的是，客户端的界面也因此变得越来越卡顿。
爆发冲突：

这时候很讨厌的那个后端舔狗还在旁边一边吃包子一边补刀：“你们前端怎么请求这么频繁，连个请求控制都不会做吗，服务器都快炸了，真服了”。这一句话，直接让我彻底失控了。

我直接说：“你们不是坚持轮询吗？现在又嫌请求频繁，就你们事多，干啥啥不行，吃啥啥不剩！”

后端Leader听到后，直接说：“你们前端算什么东西，不就是切图仔”

这时候我再也不忍了，直接怒喷：“你问我前端算什么东西？现在我就告诉你！后端做不了的我前端做，后端做得了的我前端更要做，先斩后奏，CTO特许，这就是前端！够不够清楚？ ”

眼见事态失控，CTO走了进来说：前端要的实时性是产品生命线，后端的稳定性是商业底线，都闭嘴，先解决问题。

😓【折中方案】

在一番拉扯过后，我们终于达成了妥协。我坚持要提高用户体验，要求尽量减少轮询的频率并结合一些缓存策略来降低服务器负担；后端则表示愿意优化服务器的性能，准备对SSE进行适当的技术调研，看看是否可以在未来的迭代中支持更高效的长连接。

最终，我们决定：在当前的架构下，采用轮询解决问题，同时为未来的系统升级保留SSE的支持。

😕【技术升级】

两个月后，后端和我一起完成了升级SSE的改造，解决了技术债务。

前端实现（使用 EventSource）

// 创建 EventSource 实例，连接到后端的 SSE 流
const eventSource = new EventSource('http://localhost:8080/sse');

// 处理接收到的消息
eventSource.onmessage = function(event) {
    const data = JSON.parse(event.data);
    console.log('Received message:', data);
    // 在这里处理数据，如更新UI等
    updateUI(data);
};

// 监听特定的事件类型
eventSource.addEventListener('customEvent', function(event) {
    const data = JSON.parse(event.data);
    console.log('Received custom event:', data);
    // 对 customEvent 做特定处理
    handleCustomEvent(data);
});

// 错误处理
eventSource.onerror = function(event) {
    console.error('SSE connection error:', event);
    // 可以尝试重连，或做其他处理
};

// 连接关闭
eventSource.onclose = function() {
    console.log('SSE connection closed');
};

// 更新UI的函数
function updateUI(data) {
    // 假设有一个 DOM 元素显示消息
    const messageContainer = document.getElementById('messages');
    const messageElement = document.createElement('div');
    messageElement.textContent = `Message: ${data.message}`;
    messageContainer.appendChild(messageElement);
}

// 特定事件的处理函数
function handleCustomEvent(data) {
    // 自定义事件的处理逻辑
    console.log('Handling custom event:', data);
}

后端实现（使用 Java 和 Spring Boot）

import org.springframework.http.MediaType;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.servlet.mvc.method.annotation.SseEmitter;

import java.io.IOException;
import java.util.concurrent.TimeUnit;

@RestController
public class SseController {

    // SSE 端点，向客户端推送消息
    @GetMapping(value = "/sse", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
    public SseEmitter stream() {
        SseEmitter emitter = new SseEmitter();

        // 启动一个后台线程来推送数据
        new Thread(() -> {
            try {
                for (int i = 0; i < 5; i++) {
                    // 模拟服务器端发送的数据
                    String message = "Message " + (i + 1);
                    emitter.send(message);  // 发送消息
                    TimeUnit.SECONDS.sleep(1);  // 每秒发送一次
                }

                // 发送自定义事件
                emitter.send(SseEmitter.event().name("customEvent").data("Custom event data"));

                emitter.complete(); // 完成
            } catch (IOException | InterruptedException e) {
                emitter.completeWithError(e); // 错误处理
            }
        }).start();

        return emitter;
    }
}

😕【总结】

前后端思维差异

看似只是一个关于“轮询还是SSE”的争论，背后却折射出了前后端之间深刻的思维差异。前端和后端的工作本质上是对立的：我们前端关注的是用户体验和表现，而后端更关注的是系统性能和稳定性。这种目标的不同导致了我们在技术选型上的分歧。
前端为什么这么生气？

前端开发者习惯了站在用户体验的角度，追求的是尽可能简洁、实时、高效的交互。我们希望用户能够无缝感知到数据的实时变化，而不是等待。

比如，SSE在这类应用中显然比轮询更加符合需求——它能保持连接，实时推送数据，几乎不需要消耗额外的带宽。
后端为何坚持轮询？

后端的思维显然是从稳定性和可控性出发。后端说的也有道理：长连接确实比短连接更容易出问题，尤其是当并发量极高的时候，保持这么多长连接对服务器的压力是巨大的，尤其是在我们当前的架构下。并且，如果连接断开，再恢复，可能会造成消息丢失或同步不及时。

所以，后端选择轮询，从其角度来看，是一种更容易控制和可预见的方案。