我的回答将是更一般的答案，但也可以应用在这个问题上。

如果根视图(ViewController的)或根视图的第一个子视图(子视图)是UIScrollView(或UIScrollView本身)的子类，并且如果

self.navigationController.navigationBar.translucent = YES;

框架将自动设置预先计算的contentInset。

为了避免这种情况，你可以这样做

self.automaticallyAdjustsScrollViewInsets = NO;

但在我的情况下，我不能这样做，因为我正在实现SDK，其中有UIView组件，可以由其他开发人员使用。那个UIView组件包含UIWebView(它有UIScrollView作为第一个子视图)。如果该组件被添加为UIViewController的视图层次结构中的第一个子组件，自动嵌入将被系统应用。

在添加UIWebView之前，我已经通过添加frame(0,0,0,0)来修复这个问题。

在这种情况下，系统没有找到UIScrollView的子类作为第一个子视图，并没有应用insets

如果你在iOS 15或更高版本中遇到这个问题，请执行以下操作:

if #available(iOS 15.0, *) {
    self.tableView.sectionHeaderTopPadding = 0
}

下面的操作(Swift)解决了这个问题，但当你不需要头文件的时候，这是有效的。

func tableView(tableView: UITableView, heightForHeaderInSection section: Int) -> CGFloat {
    return CGFloat.min
}

如果你这样做，你将不得不放弃第一部分，并使用其他内容。

UITableViewDataSource实施:

func numberOfSectionsInTableView(tableView: UITableView) -> Int {
    return <number_of_data_sections>+1
}

func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
    // the first section we don't use for data
    if section == 0 {
        return 0
    }

    // starting from 1, there are sections we use
    if section == 1 { 
        let dataSection = section - 1

        // use dataSection for your content (useful, when data provided by fetched result controller). For example:
       if let sectionInfo = myFRC!.sections![dataSection] as? NSFetchedResultsSectionInfo {
            return sectionInfo.numberOfObjects
        }
    }

    return 0
}

func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
    let dataIndexPath = NSIndexPath(forRow: indexPath.row, inSection: (indexPath.section - 1) )
    // return cell using transformed dataIndexPath
}

func tableView(tableView: UITableView, heightForHeaderInSection section: Int) -> CGFloat {
    if section == 1 {
        // return your header height
    }
    return CGFloat.min
}


func tableView(tableView: UITableView, viewForHeaderInSection section: Int) -> UIView? {
    if section == 1 {
        // return your header view
    }
    return nil
}

func tableView(tableView: UITableView, heightForFooterInSection section: Int) -> CGFloat {
    // in my case, even when 1st section header was of zero heigh, I saw the space, an that was a footer. I did not need footer at all, so always gave zero height
    return CGFloat.min
}

就是这样。模型不知道任何变化，因为我们在访问数据时转换了节号。

我刚刚从接口生成器中删除了UITableView，再次创建它，奇怪的35px消失了。

它似乎有一个奇怪的错误在接口生成器。

上面的很多答案都太俗气了。如果苹果决定修复这种意外的行为，它们在未来的任何时候都会崩溃。

问题的根源:

UITableView不喜欢头的高度为0.0。如果你要做的是有一个高度为0的标题，你可以跳到解决方案。 即使以后你给你的头分配了一个非0.0的高度，UITableView也不喜欢一开始就被分配一个高度为0.0的头。

解决方案:

然后，最简单可靠的修复方法是确保头高度在分配给表视图时不为0。

这样做是可行的:

// Replace UIView with whatever class you're using as your header below:
UIView *tableViewHeaderView = [[UIView alloc] initWithFrame:CGRectMake(0.0, 0.0, self.tableView.bounds.size.width, CGFLOAT_MIN)];
self.tableView.tableHeaderView = tableViewHeaderView;

这样的事情会在某些时候(通常是在滚动之后)导致问题:

// Replace UIView with whatever class you're using as your header below:
UIView *tableViewHeaderView = [[UIView alloc] initWithFrame:CGRectZero];
self.tableView.tableHeaderView = tableViewHeaderView;

我也一直在想这个问题。我很确定这是iOS7的漏洞。 最终帮助我的，是xib中的观点顺序。在一个视图中，表视图被正确显示，在另一个视图中，表视图有额外的35px空间。两者之间唯一的区别(UITableView)是，在显示不好的视图中，UITableView是第一个子，而在显示正常的视图中，它是第二个。

这对我来说很有用，只是改变了视图的顺序。我真的不喜欢为了解决问题而添加额外的代码。