这是在讨论另一个 spin.js问题时提出的：因为这与那个问题明显不同，所以我坚持 SO 的“每个帖子一个问题”政策，将其作为一个新问题分支出来。
@numbers1311407 提到
spinjs 会将请求排队并按顺序提交，每个连续的请求仅在其前任完成后发出。
但这似乎大错特错！为什么 Spine 应该承担如此多的控制权并对来自客户端的所有 POST（例如）进行排序？如果 POSTS 在相关的 URI 上怎么办？即使 Spine 尝试通过对每个客户端的所有 POST 进行排序来达到一定程度的合理性，它仍然无法防止来自不同客户端的并发和冲突 POST。那么，何必呢？
但这似乎大错特错！
当您考虑脊椎的设计目标时，这是有道理的，即实现 MacCaw 所谓的“异步 UI”（您在相关问题中链接到的博客文章的标题）。这种范式试图从用户体验中消除传统请求/响应模式的所有痕迹。不再“加载”图形；即时响应的用户交互。
这种范式期望采用不同的开发方法。持久化到服务器变得更像是一个后台线程，在正常情况下，它永远不会失败。
这意味着在正常情况下，您的应用程序逻辑不应该依赖或关心脊椎请求的顺序或调度。
如果您的应用程序高度依赖服务器响应，那么 spin 可能是错误的库。
为什么 Spine 应该承担如此多的控制权并对来自客户端的所有 POST（例如）进行排序？
由于 Spine 的非阻塞设计理念，您的应用程序放弃了您可能在另一个库（如 Backbone）中拥有的流控制，其中您可能会在发出请求时执行诸如禁用“提交”按钮之类的操作，或者以其他方式阻止用户发送垃圾邮件具有非幂等请求的服务器。
例如， Spine 的Model#save立即返回，就客户端而言，在服务器甚至收到请求之前就已经发生了。这意味着spinejs需要按照请求来的顺序来收集和处理请求，以确保它们被正确处理。考虑一个用户在“保存”按钮上卡住一条新记录。第一次单击将发送 POST，第二次单击将发送 PUT。但是按钮垃圾邮件用户不知道也不关心这一点。Spine 需要确保 POST 成功完成后再发送 PUT，否则客户端会出现问题。
将非阻塞 UI 输入的顺序敏感性与第一点结合起来，即您的应用程序不应过多地关注持久层，您可以开始了解为什么spinjs 序列化请求。
即使 Spine 尝试通过对每个客户端的所有 POST 进行排序来达到一定程度的合理性，它仍然无法防止来自不同客户端的并发和冲突 POST。那么，何必呢？
因为解决方案的重点是为单个客户端提供一致的、有点用户防错的 UI 体验。例如，如果客户端创建、更新、然后删除记录，spine 应该确保所有这些请求都以正确的顺序成功到达服务器。处理客户端之间的冲突帖子是一个单独的问题，而不是请求队列的重点。