1、不要在didSelectRowAtIndexPath里获取Cell
根据MVC还是MVVM架构来说，用户点击Cell后应该通过indexpath来获取Model，而不是Cell。 数据驱动，model和indexpath是一一对应的。然后再看文档
在iOS 15之前的iOS版本中，如果单元格不可见或indexPath超出范围，则此方法返回nil。在iOS 15及更高版本中，如果表视图在指定的索引路径上保留了一个准备好的单元格，即使该单元格当前不可见，此方法也会返回一个非nil单元格。
可见 cellForRowAtIndexPath 并不是那么可靠。而数据总是在的，所以通过indexpath来获取Model是更靠谱的。
2、不要把获取的Cell直接当作EasyDemoCell类型来用
不要直接将获取的Cell当作EasyDemoCell类型使用。为了提高代码的健壮性，建议至少使用 isKindOfClass 进行类型判断，以避免潜在的崩溃问题。这种防御性的编程方式可以确保在使用Cell之前进行合适的类型检查，提高代码的可靠性。
3、作为跳转页面的判断不应依据字符串比较来实现
为了提高代码的可维护性和降低耦合度，跳转页面的判断不应仅仅依赖字符串比较。最好的做法是创建一个返回Bool值的方法，以更面向对象的方式进行判断。根据设计原则，我们应该依赖接口而非具体实现。
在MVVM架构中，这些判断逻辑应该由ViewModel (VM) 提供。通过在ViewModel中提供一个方法，根据其返回值来决定是否进行页面跳转，我们可以更好地遵循设计原则，并使代码更具可维护性和灵活性
4、最后发个通知来实现其他页面跳转，实在是不靠谱
最好的方式是通过直接导航来实现页面跳转，而不是依赖通知。使用通知作为页面跳转的触发机制，特别是在点击Cell时再发通知，不仅不可靠，而且会引入不必要的复杂性。直接采用导航的方式更加直观和可维护，提高了代码的可读性和健壮性。
总结
正确的路径能避免各种意外状况，就如选择公路而非土路，提前了解情况可以避免石子、水坑等问题。当然，在了解情况后探索捷径也是可能的。正所谓“成也萧何，败也萧何”表达了在决策和选择中，关键在于是否做了充分的调查和了解，以及是否采用了正确的方法。
