Spring Boot vs Node.js 技术选型决策指南-平芜编程栈

1. 这个问题本身就有陷阱：别再问“哪个更好”，先搞清你在解决什么问题

“Spring Boot 和 Node.js 哪个更好？”——这是我过去三年在技术社区、内推群、甚至面试现场听到频率最高的伪命题之一。它像一个精心包装的思维陷阱：表面在选技术，实际在回避最核心的问题——你正在构建什么，面向谁，要扛住什么压力，又打算怎么维护它？

我见过太多团队踩坑：初创公司用 Spring Boot 写后台管理，结果启动慢、内存吃紧、部署卡在 Jenkins 流水线里一小时；也有大厂团队用 Node.js 接支付回调接口，单机扛住 3000 QPS 后突然开始丢请求，查了一周才发现是process.nextTick队列溢出没做限流。这些都不是框架“不好”，而是把锤子当螺丝刀用，还怪锤子不够圆润。

关键词里反复出现的 “spring boot 四层架构”“node.js 安装教程”“spring boot 上传文件”“node.js 升级版本”，恰恰暴露了真实场景的割裂：一边是企业级业务系统对分层清晰、事务强一致性、数据库深度集成的刚性需求；另一边是前端工程化、实时通信、I/O 密集型脚本、快速原型验证对轻量、异步、生态即插即用的天然偏好。它们根本不在同一个技术坐标系里比拼——就像拿挖掘机和电钻比“哪个更好”，答案永远取决于你要挖地基，还是拧一颗螺丝。

所以这篇不是“对比评测”，而是一份基于真实项目节奏的技术决策地图。我会拆解四个典型战场：高并发 I/O 场景（比如聊天室、消息推送）、复杂业务逻辑系统（比如订单履约、风控引擎）、快速交付的内部工具（比如数据看板、审批流）、以及混合架构下的协同边界（比如 Spring Boot 做主干，Node.js 做网关或静态服务）。每个场景下，我会告诉你：为什么选这个、具体怎么搭、哪些坑我踩过、参数怎么调才不翻车。所有结论都来自我们团队去年落地的 7 个生产项目，包括一个日均 200 万订单的电商履约中台，和一个支撑 50 万在线用户的教育直播后台。

提示：如果你正坐在工位上，手边开着 IDEA 和 VS Code，纠结“新项目该用哪个”，请先合上编辑器，拿出一张纸，写下三件事：① 这个系统上线后第一个月要处理多少笔交易/请求？② 最关键的三个业务规则里，有没有跨多张表的强一致性校验？③ 未来半年，是否需要频繁对接银行、政务、物流等外部系统，且对方只提供 Java SDK 或 REST API？写完再往下看——这比读一百篇“性能对比图”管用得多。

2. 高并发 I/O 场景：Node.js 的主场，但 Spring Boot 也能打，关键在“怎么打”

当你的核心瓶颈是“同时处理成千上万个连接”，比如 WebSocket 实时通知、SSE 推送、长轮询网关、或者高频设备上报（IoT 场景），Node.js 的事件循环模型天然占优。它的单线程非阻塞 I/O 不是“省资源”，而是把 CPU 时间片全部让给网络调度，避免线程上下文切换的毛刺。我们做过实测：同一台 4C8G 的云服务器，纯 Node.js 的 WebSocket 服务在 95% 连接保持状态下，CPU 稳定在 35% 左右；而同等配置的 Spring Boot + Netty 实现，在连接数超过 8000 时，GC 频率陡增，CPU 毛刺冲到 70%，延迟 P99 从 12ms 跳到 200ms。

但这绝不意味着 Spring Boot 在此场景下就该被弃用。去年我们为某连锁药店搭建药品库存同步网关，上游是 3000+ 门店的安卓终端，每 30 秒上报一次库存快照，下游是 Oracle 数据库。如果全用 Node.js，虽然连接数扛得住，但每次写入都要走 JDBC Thin Driver，Oracle 的连接池锁竞争会让写入吞吐卡在 1200 TPS。最终方案是：Node.js 做接入层（负责 TLS 握手、心跳保活、JSON 解析），Spring Boot 做业务层（负责 JPA 批量写入、库存扣减校验、事务回滚）。两者通过 Redis Stream 解耦，Node.js 只管“收”，Spring Boot 只管“存”。

2.1 Node.js 的真实性能边界：别迷信“单线程无敌”

Node.js 的优势常被过度简化为“单线程非阻塞”，但实际生产中，有三个硬伤必须直面：

CPU 密集型任务会阻塞整个事件循环。比如你用crypto.pbkdf2Sync做密码哈希，或者用canvas渲染图片，哪怕只占 10ms，所有后续请求都会排队等待。解决方案不是不用，而是必须剥离：用worker_threads开子线程（注意 Node.js 12+ 才稳定），或直接扔给独立的 Python 微服务处理。我们曾因在主线程做 Base64 解码导致 WebSocket 断连率飙升，后来改用Buffer.from(data, 'base64')替代atob()，性能提升 8 倍。
内存泄漏比 Java 更隐蔽。Java 的 GC 日志能清晰看到老年代堆积，而 Node.js 的heapUsed指标平稳时，EventEmitter的监听器未移除、闭包引用的大型对象、setInterval未清理，可能让内存缓慢爬升。我们的监控策略是：每 5 分钟用process.memoryUsage()抓快照，对比heapTotal和heapUsed的差值变化率，超过 5%/分钟自动告警并 dump heap。
依赖管理混乱直接拖垮稳定性。npm install时node_modules的嵌套结构，让require('lodash')可能加载到不同版本。我们强制要求：所有项目根目录放package-lock.json，CI 流水线执行npm ci（而非npm install），且用npm ls lodash定期扫描重复版本。去年一个项目因axios的两个子依赖分别引入follow-redirects@1.14.0和@1.14.7，导致重定向头丢失，花了两天才定位。

2.2 Spring Boot 的高并发突围：Netty 不是银弹，得配对用

很多人以为 Spring Boot 做高并发就得切 Netty，但实际落地时，Netty 的裸用成本远高于收益。我们试过完全手写 Netty 服务处理 MQTT，结果发现：TLS 配置要自己啃 OpenSSL 文档，HTTP/2 的 header 压缩要手动调参，甚至连接断开后的清理逻辑都要重写。最后回归 Spring Boot WebFlux，原因很实在：它把 Netty 封装成WebClient和@RequestBody注解，你只需关注业务逻辑，底层线程模型、背压控制、连接复用全由框架兜底。

关键配置只有三处：

# application.yml spring: web: flux: max-in-memory-size: 2MB # 防止大文件上传撑爆堆内存 reactor: debug-agent: true # 开发期开启调试代理，定位 Mono/Flux 链路断裂点 server: tomcat: # 注意！WebFlux 默认不用 Tomcat，这里只是占位说明 max-connections: 0 # 必须设为 0，否则启动报错

真正让 Spring Boot 在 I/O 场景稳住的，是它与生态的咬合能力。比如我们要做设备状态推送，Node.js 需要自己实现 MQTT Client 的重连、QoS2 确认、离线消息缓存；而 Spring Boot 集成spring-integration-mqtt后，只要配置MqttPahoMessageDrivenChannelAdapter，框架自动处理断线重连、消息去重、本地队列缓冲。我们线上环境实测：MQTT Broker 断连 5 分钟后恢复，Spring Boot 服务自动补发 1200 条离线指令，零丢失。

注意：WebFlux 的@RestController返回Mono或Flux时，千万别在链路里混用阻塞式调用（如Thread.sleep()、JDBC 查询）。我们曾因一个@PostConstruct方法里调用了RestTemplate.getForObject()，导致整个 WebFlux 线程池被占满。修复方案是：所有外部 HTTP 调用必须用WebClient，数据库操作必须用R2DBC（而非 JPA），否则就是“披着响应式外衣的阻塞式代码”。

3. 复杂业务逻辑系统：Spring Boot 的护城河，Node.js 的妥协点

当你面对的是“订单创建 → 库存锁定 → 支付回调 → 发货单生成 → 物流信息同步 → 售后申请 → 退款核算”这样环环相扣的长流程，且每一步都涉及多表关联、分布式事务、幂等校验、状态机流转，Spring Boot 的分层架构和生态成熟度就是不可替代的护城河。“spring boot 四层架构”之所以成为热词，不是因为它多高深，而是它把业务复杂度的混沌，强行规训成可测试、可审计、可替换的模块。

我们为某银行做的信贷审批系统，核心流程包含 17 个业务节点，每个节点需调用不同外部系统（征信、反欺诈、税务、工商），且要求所有操作留痕、所有状态变更可追溯、所有失败步骤支持人工干预。如果用 Node.js 实现，光是状态机定义就会陷入地狱：xstate库的配置语法冗长，错误处理分散在每个onTransition回调里，单元测试要 mock 一堆 Promise。而 Spring Boot 的@Transactional+@StateMachine组合，让代码变成这样：

@States({ @State(id = "SUBMIT", initial = true), @State(id = "CREDIT_CHECK"), @State(id = "ANTI_FRAUD"), @State(id = "APPROVED"), @State(id = "REJECTED") }) @Transitions({ @Transition(source = "SUBMIT", target = "CREDIT_CHECK", event = "startCheck"), @Transition(source = "CREDIT_CHECK", target = "ANTI_FRAUD", event = "creditPass"), @Transition(source = "CREDIT_CHECK", target = "REJECTED", event = "creditFail") }) public class LoanStateMachineConfig { ... }

更关键的是，Spring Boot 的“约定优于配置”在复杂系统里是救命稻草。比如“spring boot 目录规范”看似死板，但当你团队有 20 人协作开发时，没人需要问“数据库配置在哪改”“日志格式在哪定义”“健康检查端点怎么暴露”。所有新成员第一天就能跑通mvn clean package，第二天就能在src/main/java/com/bank/loan/service/impl/下找到业务逻辑，第三天就能用@MockBean写出覆盖 80% 分支的测试。这种确定性，是 Node.js 的src/目录下堆满utils/helpers/lib/core/时无法提供的。

3.1 Node.js 处理复杂业务的现实路径：别硬刚，学着“借力”

Node.js 并非不能做复杂业务，而是必须放弃“全栈 JavaScript”的执念，主动拥抱 Java 生态。我们有个政府项目，需要对接省级社保平台（只提供 Java SDK）和市级医保平台（只提供 .NET DLL）。如果全用 Node.js，要么花三个月封装 JNI 调用 Java，要么用edge.js调用 .NET，结果都是维护噩梦。最终方案是：Node.js 做前端聚合层（渲染页面、处理用户交互），Spring Boot 做后端适配层（封装 SDK、统一异常、转换 DTO），两者通过 gRPC 通信。Node.js 侧代码精简到 200 行：

const client = new GrpcClient('localhost:50051', grpc.credentials.createInsecure()); client.getInsuranceInfo({ idCard: '11010119900307231X' }, (err, response) => { if (err) console.error('医保查询失败:', err.message); else res.json(response); // 直接透传，不碰业务逻辑 });

这种“Node.js 做胶水，Spring Boot 做肌肉”的模式，在以下场景特别高效：

对接遗留系统（COBOL、AS/400、Oracle Forms）
需要强类型校验的金融计算（利率、复利、摊销）
涉及硬件驱动的工业控制（PLC 通信、Modbus 协议）

我们甚至用 Node.js 写了个 CLI 工具，专门生成 Spring Boot 的@Data实体类——把 Swagger JSON 解析后，输出带 Lombok 注解的 Java 代码。这比让 Java 工程师手写 POJO 效率高 10 倍。

3.2 Spring Boot 的“重”不是缺陷，是设计选择

很多人吐槽 Spring Boot “启动慢”“内存大”，但这是为换取运行时确定性付出的合理代价。Java 的 JIT 编译器在应用运行 10 分钟后，热点代码会被编译成机器码，此时单次方法调用耗时比 V8 的 JIT 快 15%-20%。我们做过压测：一个含 12 个 MyBatis 查询的订单详情接口，在 Spring Boot 中 P99 延迟稳定在 42ms；而同等逻辑的 Node.js Express 接口，在 5000 并发下 P99 跳到 110ms，原因是 V8 的垃圾回收在高负载时无法及时释放对象。

另一个常被忽略的优势是诊断能力。当线上出现OutOfMemoryError，jstack能精准定位到哪行代码创建了 10 万个ArrayList；jmap -histo能列出内存中所有对象实例数；Arthas甚至能在不重启的情况下，动态修改某个方法的返回值来验证修复效果。而 Node.js 的heapdump生成的.heapsnapshot文件，需要用 Chrome DevTools 手动分析，对 Java 工程师友好，对前端工程师却像看天书。

提示：如果你的业务逻辑里有大量if-else嵌套、状态判断、规则引擎，Spring Boot 的@ConditionalOnProperty和Strategy Pattern组合会让你少写 60% 的胶水代码。比如风控规则，我们定义RiskRule接口，每个实现类对应一种策略（AgeRule、IncomeRule、CreditScoreRule），Spring 容器自动注入所有实现，运行时根据配置risk.rule=income动态选择。Node.js 里你得自己写switch或Map查找，还要手动管理实例生命周期。

4. 快速交付与内部工具：Node.js 的闪电战，Spring Boot 的持久战

当老板说“下周要上线一个员工考勤统计看板”，或者“市场部需要一个活动报名收集页”，又或者“运维要个自动清理日志的脚本”，这时候比拼的不是框架性能，而是从想法到可用的小时级交付能力。Node.js 在这个战场几乎是降维打击——它没有编译环节，npm init三分钟建好项目，express-generator一键生成骨架，chart.js加xlsx两行代码导出 Excel，nodemon热更新让改完代码 Ctrl+S 就生效。我们团队内部有个“15 分钟挑战”：谁能在 15 分钟内用 Node.js 搭出一个带登录、数据录入、图表展示的完整小工具，赢者请喝咖啡。至今没人输过。

但“快”是有代价的。去年市场部提了个需求：“做个微信扫码领券页，用户扫完跳转到小程序，同时记录扫码 IP、设备型号、地理位置”。Node.js 两天搞定前端页面和后端接口，但第三天发现：微信 JS-SDK 的签名算法要用crypto.createHmac，而地理位置解析需要调用腾讯地图 API，这两个都得自己写鉴权和重试逻辑。到了第五天，运营反馈“领券后没收到短信”，我们才想起要集成短信平台，又得加aliyun-openapiSDK……最终这个“小工具”变成了 3000 行代码、7 个 npm 包、3 个环境变量的半成品。

而 Spring Boot 的“慢”，恰恰是把隐性成本显性化的过程。spring-boot-starter-web自带spring-boot-starter-validation，表单校验一行注解搞定；spring-boot-starter-data-jpa让数据库操作变成repository.save()；spring-boot-starter-mail集成邮件发送无需关心 SMTP 连接池。我们用 Spring Boot 做内部审批流，从创建项目到上线只用了 4 小时，因为：

@Entity定义流程节点，JPA 自动生成表结构
@Scheduled注解写定时任务，不用装node-schedule
Actuator 的/actuator/health端点直接暴露服务状态，不用自己写ping接口

最关键的是，Spring Boot 的“重”让交接成本趋近于零。那个考勤看板，三个月后原开发者离职，新同事第一天就能读懂@RestController里的@GetMapping("/api/attendance")，第二天就能在application-prod.yml里改数据库连接，第三天就能用@Test写出新的统计逻辑。而 Node.js 的小工具，往往散落在routes/controllers/utils/里，没有统一入口，新同学得花半天时间画出调用链路图。

4.1 Node.js 快速交付的“安全绳”：必须建立的三道防线

为了不让“快”变成“烂”，我们在 Node.js 项目里强制推行三道防线：

TypeScript 是底线。any类型禁止出现，接口定义必须覆盖所有 API 响应字段。我们用tsoa自动生成 Swagger 文档，每次npm run build时校验类型，失败则 CI 拒绝合并。去年一个项目因res.json({ data: user })里user对象缺少avatarUrl字段，导致前端报错，TypeScript 编译阶段就捕获了。
ESLint + Prettier 强制统一风格。.eslintrc.js里启用@typescript-eslint/no-explicit-any和no-console规则，prettier配置semi: true和singleQuote: true。CI 流水线执行npm run lint:fix，确保所有 PR 的代码风格一致。
Docker 镜像标准化。基础镜像固定用node:18-alpine（体积小、漏洞少），Dockerfile里明确指定NODE_ENV=production，npm ci安装依赖，COPY package*.json ./和COPY . .分层缓存。我们甚至写了脚本，自动检测package.json里是否有devDependencies未移入dependencies（比如dotenv在生产环境必须存在）。

4.2 Spring Boot 的“快”：不是启动快，是迭代快

Spring Boot 的“快”体现在业务逻辑的可维护性上。比如我们要给考勤系统加个“加班申请”功能，传统做法是新增 Controller、Service、Repository 三层，但 Spring Boot 的@RestController和@Service注解让这三步变成“复制粘贴改名”。更狠的是，我们用spring-boot-devtools+lombok+mapstruct组合，让实体类映射代码减少 70%：

// UserDTO.java @Data @Builder public class UserDTO { private Long id; private String name; private Integer overtimeHours; // 新增字段 } // UserMapper.java @Mapper public interface UserMapper { UserDTO toDto(User user); // MapStruct 自动生成实现，无需手写 }

当需求变更时，只需改UserDTO的字段，toDto()方法自动适配。而 Node.js 的interface UserDTO改了，对应的userToDto()函数也得手动改，漏掉一处就埋下隐患。

提示：对于内部工具，Spring Boot 的spring-boot-starter-thymeleaf比 React/Vue 更高效。Thymeleaf 模板直接渲染 HTML，无需打包、无需 CDN、无需考虑跨域，<div th:text="${user.name}">默认值</div>这种语法，后端工程师 5 分钟学会，前端工程师 5 分钟嫌弃，但交付速度碾压所有 SPA 方案。

5. 混合架构实战：Spring Boot 做主干，Node.js 做触角，这才是现代企业的真相

现实世界里，几乎没有公司只用一种技术栈。大厂用 Spring Boot 做核心交易系统，用 Node.js 做前端构建工具链（Webpack/Vite）；创业公司用 Node.js 快速验证 MVP，等用户量上来后，把订单、支付、风控模块逐步迁移到 Spring Boot；传统企业用 Java 维护 ERP，用 Node.js 写移动端 API 网关。所谓“技术选型”，本质是在不同模块间划清责任边界，并建立高效的协同机制。

我们当前主力项目就是一个混合体：主站（商品浏览、搜索、下单）用 Spring Boot，保证事务强一致；营销活动页（秒杀、抽奖、裂变海报）用 Node.js，利用其快速渲染和 CDN 缓存能力；物联网设备管理平台（设备注册、固件升级、远程诊断）用 Node.js + MQTT；而所有数据报表、BI 分析、风控模型训练，跑在 Spark + Flink 的大数据平台，通过 Kafka 与前后端解耦。

5.1 通信协议选型：REST 不是唯一解，gRPC 和 Message Queue 各有山头

混合架构最大的陷阱，是盲目统一通信协议。我们吃过亏：早期所有服务都用 REST，结果 Spring Boot 调用 Node.js 接口时，因Content-Type: application/json的字符编码差异（UTF-8 vs UTF-8 BOM），导致中文字段乱码；Node.js 调用 Spring Boot 的@RequestBody时，因日期格式2023-01-01T00:00:00Z解析失败。

现在我们的协议分层策略是：

同步调用：内部服务间用 gRPC（Protocol Buffers 定义接口），跨语言兼容性好，序列化效率高。Spring Boot 用grpc-spring-boot-starter，Node.js 用@grpc/grpc-js，.proto文件定义一次，两端自动生成代码。
异步解耦：用 Kafka 做事件总线。Spring Boot 发送OrderCreatedEvent，Node.js 消费后触发短信通知；Node.js 上报DeviceOnlineEvent，Spring Boot 消费后更新设备状态。Kafka 的分区机制天然支持水平扩展。
前端通信：统一用 REST，但严格约定：日期用yyyy-MM-dd'T'HH:mm:ss.SSSXXX格式，数字用BigDecimal字符串传输（避免 JS 的浮点精度丢失），错误码用4xx/5xxHTTP 状态码 +{ "code": "ORDER_NOT_FOUND", "message": "订单不存在" }结构体。

5.2 部署与运维：别让 Docker 成为新牢笼

混合架构的运维痛点，不在技术本身，而在环境一致性。我们曾用 Docker Compose 部署 Spring Boot + Node.js + MySQL，本地跑得好好的，上生产环境却报java.net.UnknownHostException: mysql。查了半天，发现是 Docker 网络模式问题：Node.js 容器用host模式，Spring Boot 容器用bridge模式，两者 DNS 解析路径不同。

解决方案是：所有容器统一用docker network create --driver bridge mynet创建自定义网络，服务名作为 DNS 名。docker-compose.yml关键配置：

version: '3.8' services: spring-boot-app: image: registry.example.com/spring-boot:1.0 networks: - mynet depends_on: - mysql nodejs-app: image: registry.example.com/nodejs:1.0 networks: - mynet depends_on: - spring-boot-app mysql: image: mysql:8.0 networks: - mynet environment: MYSQL_ROOT_PASSWORD: password

这样，Node.js 里fetch('http://spring-boot-app:8080/api/orders')就能直接解析，无需硬编码 IP。

更关键的是日志聚合策略。Spring Boot 的logback-spring.xml输出 JSON 格式日志，Node.js 的pino也配置transport输出 JSON，所有日志通过 Filebeat 采集到 Elasticsearch。我们在 Kibana 里用service.name: "spring-boot-app"或service.name: "nodejs-app"过滤，还能用trace.id字段串联一次请求的全链路（Spring Boot 用spring-cloud-starter-sleuth，Node.js 用zipkin-instrumentation-express）。

提示：混合架构最大的风险不是技术不兼容，而是团队技能断层。我们强制要求：Java 工程师每月至少写 100 行 TypeScript，Node.js 工程师每季度至少 review 一个 Spring Boot 的 PR。技术栈可以混合，但人的能力不能割裂。真正的架构师，不是决定用什么，而是让不同技术的人能顺畅协作。

6. 选型决策树：一张表，五个问题，直接给出答案

说了这么多，回到最初的问题：“Spring Boot 还是 Node.js？” 我把过去两年所有项目决策过程，浓缩成一张决策树表格。它不追求理论完美，只回答“你现在该选哪个”：

问题	选项 A（选 Spring Boot）	选项 B（选 Node.js）	为什么这么分？
1. 你的核心瓶颈是 CPU 计算密集，还是网络 I/O 密集？	CPU 密集（如图像处理、加密解密、科学计算）	I/O 密集（如 WebSocket、API 网关、爬虫）	CPU 密集任务在 Node.js 会阻塞事件循环，Spring Boot 的多线程模型更稳；I/O 密集时 Node.js 的单线程非阻塞模型减少上下文切换开销。
2. 业务逻辑是否涉及多表强一致性事务？	是（如银行转账、库存扣减、订单创建）	否（如用户注册、内容发布、文件上传）	Spring Boot 的`@Transactional`对 MySQL/Oracle 的 ACID 支持成熟；Node.js 的事务控制依赖 ORM（如 TypeORM），在复杂场景下易出错。
3. 团队主力技术栈是 Java 还是 JavaScript？	Java 工程师 ≥ 3 人，且熟悉 Spring 生态	前端工程师 ≥ 3 人，且熟悉 Node.js 生态	强行让 Java 工程师写 Node.js，或让前端写 Spring Boot，交付质量和维护成本会指数级上升。技术选型的第一原则是“人尽其才”。
4. 是否需要对接大量 Java/.NET 遗留系统？	是（如银行核心系统、ERP、政务平台）	否（如纯 Web 前端、移动 App、IoT 设备）	Spring Boot 调用 Java SDK 零成本；Node.js 调用需 JNI 或进程间通信，维护成本高。
5. 项目生命周期预期是否 > 2 年？	是（如企业级 SaaS、政府项目、金融系统）	否（如营销活动页、内部工具、POC 验证）	Spring Boot 的可维护性、可测试性、生态成熟度，在长期项目中优势碾压；Node.js 的快速交付在短期项目中无可替代。

这张表不是教条，而是我们踩坑后总结的“最小可行决策路径”。比如你填：① I/O 密集 → ② 否 → ③ 前端工程师为主 → ④ 否 → ⑤ 否 → 结论：Node.js。如果填：① CPU 密集 → ② 是 → ③ Java 工程师为主 → ④ 是 → ⑤ 是 → 结论：Spring Boot。

但真正的难点不在填表，而在诚实回答每个问题。很多团队说“我们是 I/O 密集”，结果一查日志，90% 请求都在等数据库响应——这本质是数据库瓶颈，不是框架问题。我们现在的标准动作是：先用Arthas或clinic.js抓取 5 分钟火焰图，看 CPU 时间花在哪，再决定优化方向。框架选型，永远是问题诊断后的自然结果，而不是技术信仰的宣言。

最后分享一个真实案例：某在线教育公司要做“直播课互动答题系统”，初期用 Node.js 做 WebSocket 服务，跑得飞快。但三个月后，他们发现老师端要实时显示“答题正确率柱状图”，而这个数据要从 MySQL 的 5 张表 JOIN 计算，Node.js 的mysql2驱动在高并发下连接池耗尽。他们没换框架，而是把计算逻辑抽成 Spring Boot 微服务，Node.js 只负责广播结果。现在系统稳定运行一年，峰值 QPS 12000，故障率低于 0.01%。技术没有高下，只有适配与否。