另一个可能的原因是UITableView被嵌入到UIScrollView中。我今天遇到了这个问题，因为我无意中使用了滚动视图而不是普通视图作为控制器的根视图。

对于Xcode 6.4, Swift 1.2。在IB中选择“标签”被改变了。我不知道是怎么改变的，为什么改变。将其设置为“单一选择”使我的表格视图单元格再次可选。

即使另一个答案已经被接受，我将为观察这个问题的人补充一个可能的问题和解决方案:

If you have automatic reference counting (ARC) turned on, you may find that even after assigning your controller as a delegate of the view, the view's messages to the controller are not being received because ARC is deleting the controller. Apparently the UITableView's delegate pointer does not count as a reference for the ARC, so if that is the only reference to it, the controller will be dealloc'd. You can verify whether or not this is happening by implementing the dealloc method on the controller and setting a breakpoint or NSLog call there.

解决方案是在其他地方使用强引用跟踪控制器，直到确定不再需要它为止。

以防你和我有同样的问题 显然，如果tableView处于编辑模式，这个方法不会被调用。你必须设置allowsSelectionDuringEditing为true。

通过这个问题:编辑时，' UITableView '不调用didSelectRowAtIndexPath ??

在我的例子中，我在加载时动态计算TableView的SuperView的高度。由于一个错误的计算，TableView被定位在SuperView之外。TableView绘制得很好，但是所有的交互都被禁用了(并且didSelectRowAtIndexPath从未被调用)。很难检测到，因为没有视觉上的迹象表明TableView是不可访问的。

这些答案对我都没用。大约一个小时后，我发现了一些非常阴险的事情:

我在另一个表格视图的单元格中有一个表格视图。我决定创建一个包含内部表视图的封闭视图。我将这个视图命名为contentView并在xib中连接它。

UITableViewCell已经有一个contentView并对它做了一些奇怪的事情。当我将属性重命名为mainContentView并将视图重新连接到这个重命名的属性时，问题自行解决了。