问题
场景：在点击某个按钮后，页面没有真正的跳转时，我们一般会自定义一个显示等待，然后在点击操作成功后，通常会加以不验证操作，比如url，或者说定位一下别的页面的元素，但是这种情况下就可能会报错超时。
解决
比如 我隐式等待设置10s等待，然后显式等待也是10s，就会出现如下结果：点击按钮，成功，但是没有跳转成功，这时，程序将进行验证操作，比如find元素，但是这时如果你用的时find_element（其实一般都是用这个），你这个东西实际上不是瞬发的，它默认带上了隐式等待的10秒轮询，你原本的意思是让这个find 操作，麻溜搞，找不到，马上报错，返回显式等待，重新整，但是因为你设置了10秒的隐式等待，就会导致这个你预想的瞬间操作，会在隐式等待影响下，不断轮询10s，等10s结束后，好它终于报错超时，被等候多时的显式等待异常捕获，然后显式等待本想重新进行操作，但是因为10s过去了，显式等待最长等待时间也是10s，自然马上就报错超时了。就会导致这个问题。
至于如何解决这个问题，也很简单，在显式等待操作中，插入一步重新设置隐式等待时间，设为1s或者干脆设为0（取消）等到验证操作成功执行后再设置回10s。
解析
至于这个问题为何之前没有遇到过，和之前ad老师上课时，其实有同学问过如果同时设置了显式等待和隐式等待，那么这个超时时间究竟是看哪个，也就是哪个的优先级搞，当时的结果是显式等待优先级搞，但是现在看来，又不是如此说法了，首先，我们以前用的显式等待实际上都是用官方封装好的显式等待方法，所以不排除官方本身就又对这个隐式等待作调整。
换句话说，实际上selenium在找元素层面，底层或多或少都是find_element方法，即本质上如果不作特殊处理，（比如手动调整隐式等待时间），那么实际上所有找元素的操作最先执行的都是隐式等待的轮询，因为我们通过解析显式等待可以发现，实际上显式等待并没有脱离底层find_element的框架，只是加了一些逻辑判断和循环，才诞生如此效果，所以，如果我自定义显示等待，而且没有作处理，并且操作中很直白使用了find_element，那么岂不是比如显式等待设置20s，然后隐式等待设置10s，那么当元素真的不存在时，在第一轮显式等待操作中的find动作，会受隐式等待影响，不断进行find轮询，10s后，才继续第一轮显式等待的后续操作，也就是很可能在整个显式等待生命周期中，可能显式等待动作只执行了不到两轮，当然了，其内核find倒是执行了足够多的次数，倒也不一定说对最终目的（对某个元素的轮询）有很大影响，但是如果这些显式等待操作比较繁琐且皆需要执行足够多的频率时，可能就要设置一下隐式等待的时间。