php session不起作用的解决办法：首先打开php的配置文件；然后找到session相关的配置项；接着新建session 文件，并设置权限；最后重新上传文件即可。
推荐：《PHP视频教程》
今天下班坐班车，快到站的时候，上家公司的 leader 发了个 qq 给我，意思是救火，下车后回来在电脑上详细问了下，leader 的描述如下
这个地址 你帮我看下 为啥上传完试卷发布任务 设置答题卡的时候 session 就没了
立即学习“PHP免费学习笔记（深入）”；
因为这个项目一开始后台都是我一人开发的，因此很快就找到了问题所在。流程为：用户通过 js 组件上传试卷，在上传试卷的方法中通过 session 存储刚刚上传的试卷详细信息，如名称、后缀、存入资源表的 ID 等，上传成功后，再点击页面上的其他选项，如学校、年级、难易度等，最后点击提交，在提交处理的方法里，一开始便判断刚刚上传的 session 值是否存在，不存在便跳到试卷首页。我在此方法中打印了 $_SESSION，没有值，奇怪了，以前还是好好的。于是我问了下，啥时候开始的，leader 说下午快下班时，老师打电话说上传试卷设置答题卡不成功，老跳转。接着又问了下，动服务器环境了么，leader 说没有。
既然出现了问题，那就解决问题呗。正好这段时间在看《PHP 核心技术与最佳实践》一书，里面就对 session 和 cookie 有详细的描述，同时也加深了我对二者的理解。于是我先打开 php 的配置文件，找到 session 相关的配置项，发现 session.save_path为 /data2/session，我记得以前都是设置为 /data1/session 的，怎么变了。于是我退出来去看看此路径，一开始我以为是该目录权限不够，后来一看，压根就没有该目录，难怪每个 session 不会跨页面。于是新建文件，设置权限，再上传，一切又恢复正常了。
写到这，我也想再唠叨下 session 相关的技术点。session 是存储在服务器端的，默认是以文件方式存储的（session.save_handler = files）。那 session 是如何产生的呢？session 是通过 session_start() 函数产生的 ，当此函数运行时，在 session 存储的目录里生成一个文件和唯一一个与之对应的 session id，通过 session id 可以取出该 session 文件的数据。由于每次运行 session_start() 都会产生新的 seession 文件，那么如何利用到以前生成 session 文件呢，只需 session_id($session_id)，那么便不会新产生 session 文件了，而会去读 session id 对应的 session 文件。session id 在默认情况下都是使用在客户端（浏览器）的 cookie 来保存 session id（在 chrome 浏览器上按 F12 键，点击 Resources-cookies，可以看到）,使用 $_COOKIE['PHPSESSID'] 可以获取。那个PHPSESSID是session id 的默认名称，在 php.ini 里可以通过 session.name 来设置，在脚本中用 session_name() 来获取 session id 的名称。每次浏览器和服务器对话时，浏览器都会把 session id 传给服务器的，服务器会依据传递过来的 session id 找到相应的 session 文件获取相应信息进行相关操作。而一旦客户端（浏览器）禁用了 cookie，那么服务器端变不会接收到 session id，此时需要显示传递 session id 了。两种方法：手动通过 URL 传递 session id；隐藏表单传递 session id。上述两种方法需要服务端的 php 环境中session.use_trans_sid 值为 1。
啰嗦了那么多，最后还是 linus 那句话，“talk is cheap，show me the code”。
'molaifeng', 'hobby' => 'php'); ?> testSession
代码都看懂的吧，就不解释了。
最后总结下吧，一般情况下出现跨页面 session 失效，基本上是上述列出的几点。1、session.save_path 有误，如权限不够，或是目录不存在；2、服务器php配置中的 session.use_trans_sid 值为 0；3、客户端禁用了cookie。不过我觉得第一种情况出现的频率应该挺高的。
【updated 2018-05-21】
周五晚上上线，又踩了个坑。框架是用 CI ， session 写入 MySQL 表。一开始表现形式和上面描述的症状一模一样，于是便重新设置了 seesion 的目录，并赋予了相关的读写权限，然并卵。后来发现该表是个 memory 表，以为是超出了内存表最大值，于是清空了该表，还是然并卵。最后对比了下两个版本的差异，发现在保存 session 的时候新增了两个字段，于是采用排除法，先把两个都注释了，然后一个一个打开，最后定位到了问题。原来，新增的一个值是用来保存一个类型表的所有值的，一开始在做测试时，只有几个值，后来上线时新增了一百多个值，同时那个字段只有 3000 大小，应该是撑爆了。于是先把该字段调大，让线上验证，然后改了下相关逻辑，不把表的所有值都写进去。
