用指针应该有办法判断，但并不是好办法，最好还是听楼上的意见自己处理关闭

酒路 wineflow

别搞那么多花样 SSL 是最稳的 诞生的目的就是为了解决不可信网络的可信通信
如果不支持 SSL 那就自己网络层加上公私加密 毕竟是经过全球验证的可靠通信算法

@xtf2009 难以相信会有这样大的区别，可能其他问题导致的可能性更大，磁盘 IO 性能是否同一水平，另外低版本 mysql 可能会存在索引失效的情况，如果能在同一机器重建相关表测试下可能更有说服力

所以我不放心中心化的密码管理，选择自己再次额外 encode 密码才交给第三方，虽然麻烦，但安全第一

https://github.com/del-xiong/lastpass_dopass

我也反对一楼的看法，怯场和是否有准备毫无关系，完全 2 码事,拿着演讲稿瑟瑟发抖的人可不少，而厉害的人临场发挥从来也不差，怯场我觉得主要是在心态和经验方面欠缺。
经验只能慢慢补，心态可以通过阅读一些厚黑伦书籍调整好
可以从这里的心灵鸡汤开始 https://www.ximalaya.com/qinggan/6072012/27786312
当你真正想通和理解这篇文章的中心思想，已经走出了第一步

fastapi 吗

我们单表最大就在 x 千万级，配个 1w 多的机器毫无压力，朋友的 mysql 也有在亿级使用的，不过由于特殊查询的原因，已经在考虑换数据库
如果还担心 hold 不住，直接上云，阿里 polar 入门级一年也就几千，我们也在使用感觉挺棒，感觉普通亿级数据支撑应该问题不大

可以自己维护一套连续 id 序列来优化

但是意义不大，深度分页并没有什么实际存在意义，至少目前来说我还没遇到过太有意义的场景

发现一个 clue，首页针对用户和爬虫访问做了区分展示

没有任何经验能适用任何情况，这个篮子理论应该是指在对风险了解不多不可控的情况下应分摊风险，但反之如果你对每个渠道风险都极了解可能有更好的方案
附一个案例
```
美国海军有这样一种观点，即舰队规模越小越好。这样，遭遇德国潜艇造成的损失是有限的。因此，美国海军参谋部让每个舰队分成尽可能多的编队，并按顺序出海。然而，数学家们在使用概率论分析后发现这个理论是不正确的。

舰队和敌人的潜艇可能会相遇，也可能不会相遇。这是一个随机事件。舰队布置得越多，遇到敌人的可能性就越大。因此，美国海军接受了数学家的建议，命令舰队在指定海域集合，然后集体通过危险海域，然后分别驶往指定港口。结果，运输船队沉没的概率从 25 %降低到 1 %，大大减少了损失，确保了材料的及时供应。

```

50w 总数据 即使 18w 我觉得还是偏慢了 考虑磁盘性能不足

作为对比 我测试下我这边的速度 2000w 数据表 查询 20w 记录的一个单字段 也不过才 2 秒左右

重建索引试试？低版本 mysql 有可能索引失效 bug

另外磁盘是什么型号，测试下，大概率磁盘导致

索引不正常吧 单字段查询 5 千万都不会这么慢

@imn1 浏览器可以禁用更新的，你也可以下载 portable 版本，爬虫浏览器基本不需要更新，配置一次就一直可用，楼上提到的 rod 也自带了全套工具直接 docker 即可使用无需考虑环境了

@ladypxy
@xiadong1994
盗刷带来的麻烦就是银行始终需要比国内更加敏感的风控，这已经敏感到影响到正常用户的支付了，我们之前有老客户本来之前支付的好好的，后面支付就莫名其妙被限制了，联系我们再联系渠道，渠道再联系银行才成功，虽然用户似乎没损失钱但损失的时间也是成本，商家就更惨了可能直接丢单子

@ysmood 感谢大佬提供的 rod，以前试过挺好用的
不过 rod 是基于 devtools ？如果是那仍然可以被检测到，要破解也没有楼上提到的那么容易，除非能够修改浏览器内核
空了我会再测试一番

@dsg001 headless 使用的也是 webdriver 和 selenium 一样

路过打击一下楼主
selenium 也并不万能，因为发现 webdriver 会向浏览器写入多项特征数据导致能够被识别，如果目标网站做了对应的防御，爬取难度会非常大，而且这些特征有些是无法移除或修改的，例如 navigator.webdriver，这点深受使用者吐槽，老外都骂 google 做了婊子还要立牌坊，不过 google 应该是为了保证网站的知情权吧

已经有开发者发起挑战，宣称将基于 chromium 开发无法检测的 webdriver 浏览器