在做 SAP 系统的 Web 应用时，很多同学会默认一个直觉：浏览器里fetch两个接口，请求当然可以并发，响应谁快谁先回。可一旦落到 ABAP 侧，尤其是 BSP（Business Server Pages）这种经典技术栈上，你会发现同样的前端代码，在 Stateful 与 Stateless 两种模式下，后端的处理节奏会出现肉眼可见的差异：要么严格排队串行，要么真正并行抢跑。
这篇文章用一个非常小的 BSP 应用把现象复现出来，并把背后的机制讲清楚：sap-contextid这个 Cookie 到底在扮演什么角色、为什么会导致请求排队、这对性能和可扩展性意味着什么，以及在真实项目里该如何选择与落地。
Stateful 与 Stateless 到底在讨论什么
BSP 的 Stateful / Stateless 并不是在争论浏览器端有没有状态，而是在讨论 ABAP 应用服务器（SAP Web Application Server）是否为一段会话保留应用上下文（也常被 SAP 文档称为 Roll Area），以及这个上下文能否跨多个 HTTP 请求持续存在。SAP 官方文档把这点说得很直白：所谓 Stateless，不是说运行中的应用原则上不保留数据，而是指应用上下文是否会在每次请求结束后被释放。(
