Apple 的文档中提到了该indexPath参数：
指定单元格位置的索引路径。数据源在被要求输入单元格时会收到此信息，并且应该将其传递。该方法使用索引路径根据单元格在表格视图中的位置进行附加配置。
但register(Class|Nib):forCellReuseIdentifier:只指定要使用的重用标识符，而不是节或一组索引路径。
我想也许UITableViewCell有某种方法可以将它的手放在索引路径上，所以它可以，比如说，如果在一个部分的第一行，它可以绕过它的角落，但我没有看到它。在创建时，它得到的只是它的样式和重用标识符（initWithStyle:reuseIdentifier:）；在重用时，它被告知的只是prepareForReuse.
鉴于dequeueReusableCellWithIdentifier:仍然支持旧的，如果它不能依靠有机会去做的话，它可能会做什么样的基于索引路径的配置呢？
我查看了 Table View Programming Guide，但它自 iOS 5 以来一直没有更新。
dequeueReusableCellWithIdentifier:和之间最重要的区别dequeueReusableCellWithIdentifier:indexPath:是它们是不同的方法！因此，它们可以表现不同，而且确实如此。这与 indexPath 无关，真的；我们只需要一种方法来区分它们。
特别是，如果您调用dequeueReusableCellWithIdentifier:indexPath:，这表明您正在使用新的 iOS 6 注册和出队系统。因此，如果您未能注册此标识符，您将收到一个很好的崩溃和一条解释问题的日志消息。这个方法永远不会返回 nil；它总是返回一个单元格，要么通过创建一个新单元格，要么通过重用一个单元格。
另一方面，简单明了dequeueReusableCellWithIdentifier:是旧的并且必须向后兼容。如果你没有注册这个标识符，它不会抱怨：它只会返回 nil，让你高高在上。你必须自己创建细胞，就像在过去糟糕的日子里一样。
编辑：但另请参阅@svena 的答案！新方法 (with indexPath:) 具有我不知道的第二个优势：单元格在返回给您时大小正确。
根据WWDC 2012 Session 200 - What's New In Cocoa Touch，
如果您使用- dequeueReusableCellWithIdentifier:forIndexPath:出列单元格，它将是正确的大小，您将能够在单元格的contentView.
这几乎是来自 UIKit 工程师 Chris Parker 的一句话。
直到 iOS 6，如果你想进行布局调整，你必须继承你的UITableViewCell并覆盖。- layoutSubviews从封装的角度来看，这可能仍然是更好的解决方案——但是，有时您只需要进行微小的调整，现在您可以- tableView:cellForRowAtIndexPath:改为这样做。
我相信它用于调用该tableView:heightForRowAtIndexPath:方法（如果存在），允许正确调整单元格的大小。
我一直认为 UIKit 会在分组表格视图中将顶部和底部单元格的角变圆，当UITableViewDelegate方法：
- (void)tableView:(UITableView *)tableView willDisplayCell:(UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath *)indexPath
叫做。但是，知道索引路径并没有多大用处，除非单元格还知道同一部分中有多少行，因此它可以确定它是否是最后一个单元格。
我假设向该方法添加索引路径dequeueReusableCellWithIdentifier:是为了提高性能，也许正如@jrturton 建议的不同重用池或只是确定单元格在分组部分中的位置。
据我从 WWDC 视频中记得，iOS 6 中添加了一些额外的方法来支持单元格的重新排序、插入和删除，所以这可能也是这里的因素吗？