这次的bug让我印象比较深刻，居然出在strpos函数上，从标题来说，今天我要阐述的不是经典的strpos()===false的问题，而是在我设计的一个应用中，由于比较特殊的场景，而产生的bug。所以叫做“另一个”需要注意的地方，下面我就详细说说。

    我们的项目强烈不推荐多表联合查询，这当然是系统架构决定的，同时也意味着我曾经长时间修炼的复杂的MYSQL查询语句，在当下项目中毫无用武之地。呜呼哀哉！架构决定数据库设计，在不复杂的一对多的情况，我们通常把他们放到一个表中处理。我做的应用的功能是一个用户组，需要对用户组中的用户设定一个数值来表示他的状态，另外，添加用户到组中或者踢出用户，我都把他放在同一字段中，该字段中的数据格式类似与这样： 状态#用户UID|状态#用户UID|状态#用户UID，设计的时候就是这样子设计的，要取出组中的成员很容易用explode就可以还原出来，那么，要检查一个用户UID是否存在该组中，我们自然用到strpos来做，看看他是否===false就可以了，先前我也是这么自然的思考的，但问题不知不觉的就产生了，由于用户UID的另个表中的自增主键，所以有这样的情况，例如某UID=143235，而另个UID=1432，那么用strpos判断肯定会返回true，即错误的认为本不是该组的成员，被判断为是该组成员，聪明的你一定会说用explode+in_array不就可以了么？实际上在这个应用中用户状态有5个值，他不是固定值，因此如果用explode+in_array的话，我们还需要循环一次。所以我修改了一下格式，变成：状态#用户UID|状态#用户UID|状态#用户UID|，看出不同了么？是的，最后将总是有一个竖线，这样用strpos来判断的时候用“#.用户UID.|”，就消除了BUG，用explode还原的时候array_pop一次即可消除最后的空数组。

    实际上，除了strpos，str_replace有同样的问题，因此在踢出用户的时候也没有了bug。数据格式化部分全部由PHP来处理，而我们外网的生产服务器运算能力惊人，数据库还是干好存取工作吧。

    ――为什么今天讲了这么烂的话题和这么烂的数据库设计？――哥，你懂的！……