前言
在写这篇文章之前，我将本文集（iOS开发中的坑）里的一些文章进行了调整，移至iOS开发文集当中。目的，就是为了进行一种区分，让本文集从今往后，成为一种专门记录一些不常见的iOS开发中的坑，的存在。
本文集中的文章中记录下来的坑都属于不常见的那种，很多人可能永远都不会遇到，但是当你遇到时，往往很难在网上找到相关记录。
正文
UITableView可以说是iOS开发中最常用到的几种UI控件之一，相信很多人都用过不知道多少次。今天就来说一说UITableView中那些不常见的大坑。
1.UITableView在RegisterUITableViewCell之前崩溃的坑。
光看标题可能很多人不是很明白，所以我就直接上代码。
看完上图代码，我们的第一个问题就来啦,请问上图代码运行之后，控制台的输出顺序是什么？
虽然答对了上面的问题，但是还请不要骄傲，因为我们的重头戏来了。
下面宣布答案，可能和你的猜测有些出入。
**结论：在为tableView设置了tableFooterView和tableHeaderView之后，如果调用tableView.separatorStyle方法，系统就会自动调用UITableViewDataSource代理的代理方法。如果对这个不了解，可能就会造成各种问题。不过这个问题在iOS10已经解决，不再出现。我想应该是个官方BUG。
最后，本次实验的运行环境为iOS8.4的虚拟机，由于条件简陋，我没有测试其他的iOS版本。**
2.UITableView第0个sectionHeaderView不显示的问题
得到如下结果：
可以清楚的看出，第一个section的headerView没有显现。如果在代理里进行打印，会发现根本没有走sectionHeaderView的第0个section的代理。
这个情况很奇怪。我们稍微修改一下代码，再运行一下试试。
运行结果如下：
真是神奇啊！！！
由上图的代码对比可知，造成这种结果的原因便是sectionHeaderView的高度实现的方式不同。用self.tableView.sectionHeaderHeight设置高度就会丢失第0gesection的headerView，而通过代理就不会。
我们看一下sectionHeaderHeight的介绍，发现只有代理不实现的时候，才会用sectionHeaderHeight，按照常理来说这两者在设置统一高度时，应该没有差别。所以这种情况的出现实在让人费解。
结论：这个实验还有一部分我没有放出，所以我就直接给出结论。只有当tableView是Grouped，并且section的高度是通过sectionHeaderHeight设置的时候，第0个section的headerView才会丢失。如果tableView是Plain就不会有任何问题。
3.UITableViewHeaderFooterView不能当作普通的UIView来用，因为UITableViewHeaderFooterView中有很多约束条件，所以不能用来当作普通的UIView。
