关于这个“怪异”还是加了个双引号的，因为他只是表象看起来如此，但在查清楚后，就会有种莫名的想抽自己脑门的冲动，先说一个这个引的session 问题的背景，一台旧服务器因为硬件升级不再做主服务器来用户了，也就将它转为测试用了，原来的环境为全通过yum 安装的php + apache 至于配置什么的全是默认的，因为现在主服务器上的环境为nginx + php-fpm 为了更好的测试，以求测试服务器（旧服务器）也需一样的环境，因此也来了一通yum安装，一番设置过后，网站是毫无疑问的运行了，但就在登录时，一直报图形验证码错误，一开始，还以为是自己眼花呢，但几次下来确定不是自身的问题，就开始了如下的探索问题的过程
1.确定是session 引起的问题
2.怀疑是session 名称（php.ini 中的session.name）引起的，但细想这是不可能的，这只是个名称而且，并不影响。
3.怀疑是cookie 域或是session 域的问题，（因domain 一栏为空），在加了域后发现问题依旧。
4.通过跟踪session 发现能在存储session 时成功保存，但在下个请求时无法取到相应的session值。
至此“怪异”就出现了，按常理来说，成功存取后，就能保存的服务中，但取时却为空，是不是很奇怪，亦或是各位看官已经有了答案了，如果没有，请看下面的道破其所以然
1.在php中生成session后会在保存session 时将数据写入以session id 名称生成对应的文件保存在对应的文件中，这个对应的文件路径则由php.ini 文件下的 session.save_path 决定
2.至于为什么在设置session请求中能看到要保存的session 数据 ，这只是一个表象，简言之就是为$__SESSION 这个全局变量赋值了，但没有保存至 save_path下面，以至无法在获取请求中获取到,
那可能要问了为什么不能保存呢？关于这个问题，是因为权限，因为这save_path 的权限为600 只对拥有者有读写权限，因此要看你的php-fpm 是由谁执行的，并与save_path 的目录权限进行对比，这就是问题的所在。
总结：
1.在一些老的配置环境下，对于save_path的拥有者大部分为apache ，但在改用nginx+php-fpm时会为启动线程指定执行者，如果没有注意到这一点，修改执行者为非apache 那就会出现上述的session “怪异”问题
2.对于原来生成的session 文件建议是修改为php-fpm 执行者所有，或者是清空目录文件，如果不这么做的话，有可能还是会出现如上所述的问题，因为session id 相同生成的文件相同，至使还是没有相应的权限修改或添加。
3.这是一个隐藏的比较深的问题，但是又是一个最基础的问题。