为什么 Symfony2 建议避免使用 'legacy' php 会话？

Question

我有一个使用标准 PHP 构建的 Web 应用程序。我正在通过使用 Symfony2 构建一个子应用程序（用于站点的管理员/所有者）来学习 Symfony。到目前为止一切顺利..
我的 symfony 应用程序确实从“父”应用程序调用了一些初始化代码，并且该初始化代码设置了该子应用程序可能或可能不想使用的一些（旧）会话变量。

但我在 Symfony 文档中注意到他们建议避免使用旧的 PHP 会话。 http://symfony.com/doc/current/components/http_foundation/sessions.html http://symfony.com/doc/current/components/http_foundation/session_php_bridge.html

他们为什么提出这个建议？

是否仅仅是因为 Symfony 会话管理“更好”，（并且使用旧版 SESSION 超全局在某种程度上是一种反模式）——或者，是否存在任何其他特定的不兼容或可能导致的问题我的“父”应用程序中的代码正在使用旧会话这一事实？还是其他/额外的原因？

Answer 1

http://symfony.com/doc/current/components/http_foundation/session_php_bridge.html上其实有解释，但不是很明显：

1. SF2 也使用了 $_SESSION，但它“封装”了session 服务中的功能。您不必担心session_start 和所有这些 - 只需正确配置它，然后通过服务访问它。

2. 文档中提到了存储会话数据的“包”。这些“包”是具有 SF 特定结构的数据容器。如果遗留服务完全控制$_SESSION，它可能会损坏这些结构。另一方面，遗留服务可能会创建 SF2 不知道的结构，并且可能会损坏。

例如，这是 Symfony2 中 print_r(array_keys($_SESSION)); 的结果：

Array
(
    [0] => _sf2_attributes
    [1] => _sf2_flashes
    [2] => _sf2_meta
)

总的来说，我不会说 SF 的会话处理是好是坏——作为一个框架，它只是为会话管理的常见问题提供了一个实现。

最多可以认为它优于“幼稚”的实现，尤其是（对不起：）“PHP 新手”，他们不了解会话处理的所有含义。

并且由于会话的性质（尤其是 PHP 中的 $_SESSION 超全局），您无法 100% 避免与遗留代码的冲突，这就是为什么他们指出并提出如何处理此类问题的解决方案。