PHP：在$ _SESSION中存储“对象”

我只是想知道我实际上可以将对象存储在$ _SESSION中，因此觉得很酷，因为当我跳到另一页时，我仍然有我的对象。现在，在开始使用这种方法之前，我想了解一下这是否真的是一个好主意，或者是否存在潜在的陷阱。

我知道，如果我只有一个入口点，就不需要这样做，但是我还没有，所以我没有一个入口点，我真的很想保留我的对象，因为我没有那样不会失去我的状态。（现在，我还读过我应该对无状态站点进行编程，但我还不了解该概念。）

因此，在短期：是否确定存储对象的会话，是否有任何问题，它？

编辑：

临时摘要：到目前为止，我知道重新创建对象可能更好，即使它涉及再次查询数据库。

进一步的答案可能会在这方面详细说明！

我知道这个话题很老，但是这个问题不断出现，并没有让我满意：

无论是将对象保存在$ _SESSION中，还是根据隐藏在隐藏表单字段中的数据将它们整块地重构，还是每次都从DB重新查询它们，都在使用状态。HTTP是无状态的（或多或少；但是请参阅GET与PUT），但是几乎每个人都想使用Web应用程序执行的操作都需要在某个地方维护状态。好像把国家推到了角落，这在某种程度上是理论上的胜利，这是错误的。状态就是状态。如果使用状态，则会失去无状态所带来的各种技术优势。除非您事先知道自己应该因此而失去睡眠，否则这并不是失去睡眠的事情。

汉克·盖伊（Hank Gay）提出的“双重打击”论点所带来的祝福使我特别困惑。OP是否正在构建分布式且负载均衡的电子商务系统？我的猜测不是。而且我将进一步假设，序列化他的$ User类或任何其他方法不会使他的服务器无法修复。我的建议：使用对您的应用程序明智的技术。$ _SESSION中的对象很好，但要遵守常识性预防措施。如果您的应用程序突然变成了可以与亚马逊媲美的流量，那么您将需要重新适应。那就是生活。

只要在进行session_start（）调用时，PHP已经遇到了类声明/定义，或者已经安装的自动加载器可以找到它，就可以了。否则，它将无法从会话存储反序列化对象。

HTTP是无状态协议，这是有原因的。会话将状态焊接到HTTP。根据经验，请避免使用会话状态。

更新：在HTTP级别上没有会话的概念。服务器通过为客户端提供唯一的ID并告诉客户端在每次请求时重新提交它来提供此功能。然后，服务器使用该ID作为大型Session对象哈希表的密钥。每当服务器收到请求时，它都会根据客户端随请求提交的ID从其会话对象的哈希表中查找会话信息。所有这些额外的工作对可伸缩性是双重打击（这是HTTP无状态的一个重要原因）。

• Whammy One：它减少了单个服务器可以完成的工作。
• 异想天开二：这使得扩展变得更加困难，因为现在您不能仅将请求路由到任何旧服务器-它们没有相同的会话。您可以将具有给定会话ID的所有请求固定到同一服务器。这并不容易，而且是单点故障（不是针对整个系统，而是针对大量用户）。或者，您可以在群集中的所有服务器之间共享会话存储，但是现在您有了更多的复杂性：网络连接的内存，独立的会话服务器等。

考虑到所有这些，您在会话中输入的信息越多，对性能的影响就越大（正如Vinko指出的那样）。就像Vinko指出的那样，如果您的对象不可序列化，则该会话将发生异常。因此，根据经验，避免在会话中添加超出绝对必要的内容。

@Vinko通常，您可以通过将要跟踪的数据嵌入到您发送回的响应中，然后让客户端重新提交它来解决服务器存储状态的问题，例如，将数据向下发送到隐藏的输入中。如果你真的需要服务器端状态跟踪，则可能应该在您的后备数据存储区中。

（Vinko补充：PHP可以使用数据库来存储会话信息，让客户端每次重新提交数据可能会解决潜在的可伸缩性问题，但是由于客户端可以控制所有事务，因此您必须注意一大堆安全性问题您的国家）

• 无法序列化的对象（或包含无法序列化的成员）将不会像您期望的那样从$ _SESSION中退出
• 巨大的会话给服务器增加了负担（每次对状态信息进行序列化和反序列化都很昂贵）

除此之外，我没有发现任何问题。

以我的经验，对于比具有某些属性的StdClass更复杂的事情，通常不值得这样做。给定会话存储的标识符，反序列化的成本始终比从数据库重新创建的成本高。看起来很酷，但是（像往常一样），概要分析是关键。

我建议不要使用状态，除非您绝对需要它。如果可以在不使用会话的情况下重建对象，请执行此操作。在Web应用程序中拥有状态会使应用程序的构建变得更加复杂，对于每个请求，您都必须查看用户处于何种状态。网络应用程序）。最后，我建议保持会话对象尽可能小，因为这会影响序列化和反序列化大对象的性能。

您必须记住，资源类型（例如数据库连接或文件指针）在页面加载之间不会持久存在，并且您需要无形地重新创建它们。

还请考虑会话的大小，具体取决于会话的存储方式，大小限制或延迟问题。

在升级软件库时，我也会提到-我们升级了软件，而旧版本中的对象与V1软件的类名在会话中，新软件在尝试构建会话中的对象时崩溃-作为V2软件不再使用这些相同的类，因此找不到它们。我们必须放入一些修复代码来检测会话对象，如果找到会话则将其删除，然后重新加载页面。最初报告此错误时，您最初会想到的最大麻烦是（非常熟悉，“很好，它对我有用” :)，因为它仅影响最近使用新旧系统的用户。我们确实在启动之前就找到了它，因为我们所有的用户肯定都在其会话中使用了旧的会话变量，并且可能会导致所有人崩溃，

无论如何，正如您在修正案中建议的那样，我也认为最好重新创建该对象。因此，也许只存储id，然后在每次请求时从数据库中提取对象是更好/更安全的方法。