最近一个做收藏的用户向我们提出一个需求，这个项目是湖南省收藏协会提供支持的一个项目，需求其实也到很简单：1、有社区论坛互动；2、做一个像etao那样的购物分享网站。其实一淘那个导购系统，就算从底层做也不复杂，甚至拿来任何一个开源程序，诸如dede、wordpress等等都可以做到，而且确实是不错的解决方案。但是需要社区论坛，如果我们从底层来做，那这个工作量太庞大了，就包括腾讯、小米这样的巨头也不会傻到自己重新来做，而国内首选的就是腾讯旗下的Discuz，而我们团队有Discuz的开发者，因此对于这个项目决定采用Discuz的解决方案。

如果用discuz来做，这个项目功能上主要是首页的导购功能，而社区论坛主要是写一些前台的界面（因为DZ的默认界面使用得太广泛了，现在的人追求个性嘛）。而用户对于导购系统的要求是：能分类检索、能按照来源检索、能自定义排序方式、把所有分类合并在一个页面上查询。如果单纯的多字段那么dz的分类信息功能就具备这样的功能。

诚然，要完全符合用户的需求，我们需要在功能上也进行一个改进的，于是我们为此创建了一个新的入口文件hui.php（其实跟新建一个dz的插件类似），然后把数据结果输出在模版中。涉及到的数据表也有好多个，但因为是基于Discuz,很多功能实际上已经有了，诸如多字段、数据提交、分页等等，因此实际上这个也不是特别复杂，这个功能扩展代码量一百多行。

但其中一个细节，再次让我提醒自己一定要不要省事，因为省了事可能会带来更多的麻烦。这也是我们这里的这篇文章的重点，因为在调用分类信息图片字段的时候，这个字段是采用先把内容包装到一个数组（内容包含图片的存储路径和这个图片的id），然后序列化保存在数据库中。而我们在做这个扩展的时候要读取这个图片的存储地址，我们就得把数据库里面的数据查询到然后反序列化得到一个数组（就是一个与保存相反的过程）。

但是这个时候出现了一个问题：普通帖子发布后，在这个扩展调用图片是没问题的，但帖子一修改就出问题了。我就猜想肯定是修改帖子的时候会有一个动作改变，造成了这个结果。于是我在数据库里看下这个字段，结果如图所示：

到了这里，我想有基础编程经验的人都应该知道是为什么了，其实对于这个问题我想我们在学习这个知识点的时候是再清楚不过了，但我就是偶尔想减少一点东西（实际上是可用性低的源头！）。就是在取数据的时候没有通过stripcslashes()把数据中的转义符过滤掉，因此造成了数据不能被反序列化。而原因就是DZ为了保证程序的安全性，在帖子被二次修改的时候会把这个字段加上反斜杠转义符。而我们在读取这个数据的时候必须先过滤掉这个转义符，才能把这个数据正常进行后期处理。

很多人很多时候，都想省略自己当时想当然认为不不必要的东西，而实际上就是这样的想当然就可以为以后埋下风险。实际上我个人开发习惯还算可以的，但就是看到这个扩展的复杂度低就放低了自己的要求，这才导致“很菜”的问题出现。因此我想，后面不管简单还是复杂，都得按照一个规范的方式进行。