解决中间人抓包（比如路由器抓包）：上 https，这样可以防止中间人抓包。
解决客户端抓包（比如爬虫）：本质上是人机识别，用验证码、行为识别那套。
以上和 session 、jwt 刷新都是无关的。

@karloku 同感。问题和 jwt 根本没有关系，抓包的场景下，cookie 中的 session 不也同样能被抓包么。而且奇怪的是，为何很多人觉得加上刷新机制后就能防止抓包呢，刷新过程不也会被抓包么。我认为关键还是在于解决抓包。

按我个人理解，多个篮子是从横向的空间维度分散风险，“好好看管好这个篮子”，意味着把时间拉长，是从纵向的时间维度分散风险。

你也想教？

看到对账，考虑用事件模型？订单请求生成事件，事件一边入库用于对账，另一边入 mq 发起库存扣减、订单生成等事务操作。

@reself 对了，r 就是 re.compile(r'[(](.*?)[)]', re.S)

@reself 前提是括号中有值。括号内是空的话就不行了，mapper 改一下就行。

mapper = lambda x: ''.join(re.findall(r, x)) or x
df_new = df.applymap(mapper)

这逼装的，尬得一逼。。。

要区别人机判定问题和中间人攻击问题，不要混在一起。
另外，算法公开影响安全性是伪命题。现在流行的加密本身就假设算法是公开且易知的，只需要保证密钥的安全性。

飞行员回到地球并不会更老也不会更年轻，因为忽略了加速度。这是双生子佯谬。

@laminux29 从模电开始也太扯了，怎么不说从量子力学开始呢

既然开始有人问了，那看来庄家准备出货了

@susunus 浮点数只能表示数轴上的离散点，计算结果只能近似到最近的点，除非刚好能用 2 进制表示，例如 0.5，否则都是近似值。数轴上的点数量是无穷的，用有穷的浮点数来做计算，有偏差的概非常大。所以浮点数只能用在能容忍偏差的场景，比如图形绘制。除了数值偏差，浮点数还有众所周知的不能用==判定相等的特性。

@jinsongzhao 你确定是机会而不是坑？被卖了了还帮人输钱，什么狗屁机会，膝盖跪久了起不来了

分库分表，稍微具体描述点的话，可以垂直切分或(和)水平切分。

水平切分的话，根据业务集中度可以平均切分或(和)热点切分，热点可以按访问量、按访问的地理差异、按网络延迟等。

垂直切分的话，其实类似于读写分离，将写少读多和写多读少的拆开，拆的时候可以是业务级、表级甚至字段级。