最近遇到一个项目中用的是Thinkphp这个框架开发的，其中在登录这块有验证码这个功能，其实这个功能是TP自带的,其中主要方法是buildImageVerify，位于ThinkPHP\Extend\Library\ORG\Util\Image.class.php中。该验证码的机制就是当前台每次重新绘制验证码时，那么在后台就会调用buidImageVerify这个方法，该方法主要是绘制验证码，并且把验证码上的数字或者是文字信息存储到session中。这样就完成了对验证码的存储以及output到前端，做校验这个都明白的，就是拿用户输入的验证码和session中的做比较，一致则返回true,否则返回false。当让了TP中是对验证码的md5做比较了，因为session中就是存储的是验证码md5的值，部分代码如下：

 static function buildImageVerify($length=4, $mode=1, $type='png', $width=48, $height=22, $verifyName='verify') {
        import('ORG.Util.String');
        $randval = String::randString($length, $mode);
        session($verifyName, md5($randval));  //MD5
       // 其它代码 ......
}

当在前端一直报出验证码输入错误的信息时，我大概分了几个步骤来找原因：

1.首先是确保自己的输入是正确的。

2.其次是验证代码的逻辑是否是正确的，是否有中途将session置空的操作。

3. 最后是检查跟PHP相关的配置是否有问题。

这样我就直接进入了第二个步骤，就开始调试代码，用var_dump 这个函数在验证码比较之前将POST过来的验证码和session中的验证码打印出来，结果发现session中的验证码一直为空，说明前端刷新的验证码并没有保存到session中。我继续调试返现session所存储的名字和取session中也是一致的。我开始怀疑session.auto_start的设置问题，尽管TP这个框架会自动启用session.auto_start 。检查的结果却是配置文件中是默认开启的。最后参考TP官方社区的这篇帖子：http://www.thinkphp.cn/topic/3542.html，还是同样的问题。最后我就开始检查php.ini 的配置，找到了session.save_path ，截图如下：

我尝试的访问后面的路径，但是不存在，并且在地址栏还有错误报出。因为在给session赋值的时候除了会网客户端的cookie里面写东西，同时也会想服务器上的session.save_path 这个目录下记录session的信息，文件命名默认是以session.id来命名的。所以我得出的结论是上面所配置的路径是存在的，有时候即使存在但是没有访问权限，也同样会导致session无法写入的。所以我将该路径指向了“C:\Windows\Temp” ，修改完毕后重新启动apache,验证码就ok了。