本文共 3848 字，大约阅读时间需要 12 分钟。
本文翻译自：
Starting in iOS7, there is additional space at the top of my UITableView 's which have a style UITableViewStyleGrouped . 从iOS7开始，我的UITableView顶部还有一个额外的空间，其样式为UITableViewStyleGrouped 。
Here is an example: 这是一个例子：
The tableview starts at the first arrow, there is 35 pixels of unexplained padding, then the green header is a UIView returned by viewForHeaderInSection (where the section is 0). tableview从第一个箭头开始，存在35个像素的无法解释的填充，然后绿色标头是由viewForHeaderInSection （该部分为0）返回的UIView 。
Can anyone explain where this 35 pixel amount is coming from and how I can get rid of it without switching to UITableViewStylePlain ? 任何人都可以解释这35像素的来源以及如何在不切换到UITableViewStylePlain情况下摆脱它吗？
Note: 注意：
In modern iOS: 在现代iOS中：
tableView.contentInsetAdjustmentBehavior = .never
#1楼
参考：
#2楼
I'm assuming that is just part of the new UITableViewStyleGrouped styling. 我假设这只是新的UITableViewStyleGrouped样式的一部分。 It is in all grouped table views and there doesn't seem to be any direct way to control that space. 它在所有分组的表视图中，并且似乎没有任何直接方法可以控制该空间。
If that space is being represented by a UIView , it would be possible to search through all the subviews of the UITableView to find that specific view and edit it directly. 如果该空间由UIView表示，则可以搜索UITableView所有subviews以找到该特定视图并直接对其进行编辑。 However, there is also the possibility that that space is just a hardcoded offset before headers and cells start and there won't be any way to edit it. 但是，也有可能在标头和单元格开始之前，该空间只是硬编码的偏移量，将无法进行任何编辑。
To search through all subviews (I would run this code when the table has no cells, to make it a little easier to read the output): 要搜索所有子视图（我将在表没有单元格的情况下运行此代码，以使其更易于阅读输出）：
- (void)listSubviewsOfView:(UIView *)view { // Get the subviews of the view NSArray *subviews = [view subviews]; // Return if there are no subviews if ([subviews count] == 0) return; for (UIView *subview in subviews) { NSLog(@"%@", subview); // List the subviews of subview [self listSubviewsOfView:subview]; }} #3楼
For IOS 7 if you are allocing a tableview in a view controller you may look into 对于IOS 7，如果要在视图控制器中分配表视图，则可以查看
self.edgesForExtendedLayout = UIRectEdgeNone;
your problem seemed similar to mine 你的问题似乎和我的相似
Update: 更新：
Swift in iOS 9.x: iOS 9.x中的Swift：
self.edgesForExtendedLayout = UIRectEdge.None
Swift 3 : 迅捷3：
self.edgesForExtendedLayout = UIRectEdge.init(rawValue: 0)
#4楼
Try changing the contentInset property that UITableView inherits from UIScrollView . 尝试更改UITableView从UIScrollView继承的contentInset属性。
self.tableView.contentInset = UIEdgeInsetsMake(-20, 0, 0, 0);
It's a workaround, but it works 这是一种解决方法，但是有效
#5楼
I played around with it a bit more and it seems like this is a side-effect of setting the tableView's tableHeaderView = nil . 我玩了更多，似乎这是设置tableView的tableHeaderView = nil的副作用。
Because my tableView has a dynamically appearing tableHeaderView , when I need to hide the tableHeaderView , instead of doing self.tableView.tableHeaderView = nil; 因为我的tableView有一个动态出现的tableHeaderView ，所以当我需要隐藏tableHeaderView ，不必执行self.tableView.tableHeaderView = nil; , I do: ， 我做：
self.tableView.tableHeaderView = [[UIView alloc] initWithFrame:CGRectMake(0.0f, 0.0f, self.tableView.bounds.size.width, 0.01f)];
I like this solution better than setting a somewhat arbitrary contentInset.top because I use the contentInset.top dynamically as well. 我比设置一个任意的contentInset.top更喜欢此解决方案，因为我contentInset.top动态使用contentInset.top 。 Having to remember to remove an extra 35px whenever I recalculate contentInset.top is tedious. 每当我重新计算contentInset.top时，必须记住要删除额外的35px， contentInset.top很繁琐。
#6楼
In my case this was what helped me. 就我而言，这就是帮助我的原因。 I'm supporting ios6 also. 我也支持ios6。
if ([[[UIDevice currentDevice] systemVersion] floatValue] >= 7) { self.edgesForExtendedLayout = UIRectEdgeNone; self.extendedLayoutIncludesOpaqueBars = NO; self.automaticallyAdjustsScrollViewInsets = NO;} 转载地址：http://fncnb.baihongyu.com/