我在发送响应后开始更新会话，这似乎是提高速度的好方法，因为它现在是一项非阻塞任务。
但我担心以这种方式更新会话时，数据库中的最小速度可能会导致问题。
想象一下，我想为下一个请求设置一个会话闪存消息，但下一个请求/响应发生在会话更新之前。用户不会看到它，或者他会在不同的请求中看到它。
最坏的情况是您需要重新生成会话 ID。如果更新很慢并且下一个请求来得更快，则用户将被注销，因为他将要求一个不存在或过期的会话（他在 cookie 中收到新的会话 ID 作为响应的一部分）。
所以我想知道的是这是否已经被研究过，人们是否在使用它，我应该什么时候做，什么时候不应该做，是否有修复等等。
如果您已经发送了一些输出，则无法重新生成 session_id。正如您所说，他需要在 cookie 中接收 new_id，这是必须首先发送的 http 标头的一部分。如果用户有多个具有相同会话 ID 的请求并且您更改了 session_id，则重新生成 session_id 可能会导致您提到的问题。例如一个 html 页面和一些很常见的图像。如果您需要重新生成 session_id，您应该在没有其他需要会话的资源的页面中“单独”执行它，以便它是原子操作。
现在我不确定您使用的是哪种语言，但例如 php 在内存中收集会话信息并在进程结束时将它们持久化。从而使这个非阻塞...
确实，如果会话信息必须通过多个进程同步，则必须小心。然而，这对于大多数网页/应用程序来说并不常见。在这么短的时间内（页面之外+资源下载），您很少有多个请求。
基本上，在发送响应后更新会话信息通常是一个好主意。可以这样想：如果数据库很慢，它可能很难提供过时的会话信息。所以无论如何你写的可能会在那时完成不是吗？;)