$_SESSION的标准存储区是文件系统，每个会话只有一个文件。这是有代价的：
- 当两个请求访问同一个会议上，一个请求将战胜其他和其他请求需要等到第一个请求已完成。由文件锁定控制的竞争条件。
使用Cookie存储会话数据（WordPress的，笨），比赛条件是相同的，但锁是不是内在的，但浏览器可以做的cookie管理范围内的锁定。
使用Cookie有，你不能存储大量数据，而且数据得到与每个请求和响应通过下行。这很可能引发安全问题。窃取cookie并获得数据。如果它被加密，攻击者可以尝试解密它以获取存储在其中的数据。
Wordpress的历史原因是该平台从未使用PHP会话。根项目始于2000年左右，在2002年和2004年得到了很大的推动。由于会话处理仅适用于PHP 4，而且PHP 3在那个时候更受欢迎。
后来，当$_SESSION可用时，该应用程序的主要设计已经完成，它的工作。接下来，在2004/2005年，wordpress决定启动一个商业多博客托管服务。这创造了跨服务器和cookie +数据库扩展应用程序的需求，与使用$_SESSION实现相比，数据库对于会话/用户处理来说更容易。事实上，这很容易，只是工作，所以从来没有需要改变它。
对于Codeigniter，我不能说那么多。我知道它默认存储cookie中的所有会话信息。所以会话只是Cookie的另一个名称。可以选择它可以加密，但这需要配置。据说IIRC已经这样做了，因为“大多数用户不需要会话”。对于需要的用户，有一个数据库后端（需要额外的配置），以便用户可以在其应用程序中透明地从cookie更改为数据库存储。还有一种新的实施方式，可以让您更换任何您喜欢的商店，例如本地PHP会话也是如此。这是通过所谓的驱动程序完成的。
但是，这并不意味着你不能根据现在的$_SESSION来实现。你可以用你喜欢的任何东西来替换商店（甚至是饼干:)），而且它的PHP实现应该封装在一个好的程序设计中。
这样做可以实现一个商店，您可以更好地控制锁定（例如数据库），并且可以在不支持粘性会话的负载平衡基础结构中的服务器上运行。
Wordpress是一个很好的例子，它自己实现的会话处理完全不可知论的任何PHP提供。这意味着车轮已被重新发明。从今天起，我不会将他们的设计称为明确创新，因此它充分满足了特定环境中的一项非常具体的需求，只有在了解项目根源的情况下，您才能了解这些需求。
Codeigniter可能会提前一小步（在界面上），因为它为会话提供某种（不稳定）的接口，并且可以用您喜欢的任何实现来代替它。这对新开发人员来说更好，但它也是重新发明轮子的原因，因为PHP已经开箱即用了。
在应用程序设计中，您可以做的最好的事情是让实现独立于系统需求，从而使会话数据的存储机制独立于程序流的其余部分。 PHP提供了一个非常直接的接口，$_SESSION数组和会话配置。
由于$_SESSION是一个超全局数组，您可能想阻止应用程序直接访问它，因为这会引入全局状态。因此，在一个好的设计中，你可以有一个接口，以便能够从超全球范围内完全抽象出来。
做到这一点，再加上商店加配置的抽象（例如全部在一个会话依赖容器中），无论出于何种原因，您都应该能够在任意数量的服务器上扩展和维护应用程序。如果你认为这对你有用，那么你的实现就可以使用cookies。但是，如果您需要，您将能够切换到基于数据库的会话 - 无需重新编写应用程序的大部分内容。
我没有使用Wordpress的经验。为了我的好奇心，有人可以确认它确实不会使用会话，甚至不能保持登录的基本目的吗？我可以看到使用db存储来代替扩展会话var存储。 –
Wordpress不使用会话。我知道为什么，它有历史的原因。但我很好奇哪些其他流行的Web应用程序不是那么好？你有更多的例子吗？ – hakre
Michael - Worpress绝对不会使用会话，除非您使用已启动会话的插件。 @hakre - 你能分享历史原因吗？我主要使用WP，但Expression Engine和Code Ignitor不使用PHP的会话。 – cwd