于是翻了yii框架中相关源码发现采用的是pdo查询，于是又查询了pdo相关资料知道了原因：
不能让占位符代替一组值。 假如字符串str在由N子链组成的字符串列表strlist中则返回值的范围在 1 到 N 之间。 一个字符串列表就是一个由一些被 ‘,’ 符号分开的子链组成的字符串如果第一个参数是一个常数字符串，而第二个是type SET列则 FIND_IN_SET() 函数被优化，使用比特计算 如果str不在strlist 或strlist 为空字符串，则返回值为 0 如任意一个参数为NULL，则返回值为 NULL这个函数在第一个参数包含一個逗号(‘,’)时将无法正常运行。
首先我们必须理性认识到，任哬一个即使稳定的系统中也是存在着大量的 bug不管是因为什么原因导致的错误，我们都是需要做好防范的最好的结果当然是将异常纠正過来，返回客户端一个正确的响应结果但绝大多数情况下是没办法返回正常结果的，只能返回一个客户端一个异常的信息
处理异常的方式，通常分为：
要处理好这个问题我认为比较简单的方式就是将需要处理的异常按照场景先做一个分类。
用户行为导致的错误通常不需要记录日志因为若是多人使用的情况下会导致日志量过大，但需要向客户端返回具体原因以便用户用正确的方式调用我们的接口；而垺务器出现的错误则需要记录日志因为我们是需要解决这些错误的，记录日志让我们比较方便的找到错误的原因快速解决，但不向客戶端返回具体原因因为用户没办法通过自己的行为使异常不再出现。当然我们也可以根据自己的业务决定自己的异常处理方式
在 ThinkPHP 或者其他框架中，如果出现异常则会出现框架的一个异常页面。
但如果我们开发的是 API直接返回一个页面给客户端显然不合理，因为别人在使用你的接口的时候还需要解析界面分析出结果这么做是十分不合理的，所以我们需要对框架的异常处理进行重写。以下使用 Yii2 框架作為例子讲解重写的逻辑：
为了让我们的程序可以简单的辨别出客户的不当调用导致的错误和服务器的错误我们可以写一个客户的异常类。新建 common\UserException.php 文件
// 如果传过来的不是数组则不进行对象初始化 // 判断数组有没有该键值
这就完成了全局的异常处理让我们看看效果
当我们开启 debug 模式时抛出错误：
关闭 debug 模式，抛出服务器端异常：
关闭 debug 模式抛出客户端异常：
