实际上「大数据杀熟」这个说法本来就是一种道德谴责，而不应该是法律范畴。

法律的底线是明码标价，并且一直如此。

杀熟这个词存在这么多年了，价格歧视本来就是一种营销策略，如果出了所谓法规禁止这种行为，那可真是开倒车。
可惜，还真有可能开。

不这样的话，sql 中怎么表达 datetime 类型呢

用户都被搞成这样了，好好 OAuth 非得通过扫码实现
现在 VScode 命令行操作 git 都可以通过浏览器授权登录 Github 了！！

考虑过去建设知乎宇宙吗？

移动端我的体会是，如果不考虑横屏，vw/vh 很好用。引入横屏会麻烦一点。

这个文章早就看过了，一言难尽...

pip 不会重新安装已经存在的依赖
Requirement already satisfied: requests in /Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages (2.25.0)

可以映射为对象，也可以映射为 Map 的。映射为对象对于嵌套结构就很不友好

啥型号？你这问题我遇到过
MIX2S
电源键间歇性短路，表现出电源键按死的状态，重启到一半又重启了。

又要走中小公司的路子，又要搞大公司的流程。
典型的又当又立，不正常。

这 UI 和交互也太糙了，
事项所有属性都是必填项
提交按钮没有 disabled，点了没反应
点开两次需要授权两次
Me 页面有 Empty，TODO 页面没有
Me 页面元素太多导致用户无法聚焦
表单和分割线居然是顶部对齐

还得多打磨打磨啊这

如果玩家知道 n，概率就是不可计算的了。而如果 m 等于 1，则结果只可能有一种。

描述感觉不太完整，这个题目看起来是脱胎于猜数字这个游戏，还不太一样。

我觉得还有以下约束

- 玩家并不知道目标数字是多少，因此玩家喊 1~m 个数字的概率是相等的
- 每个人每次至少要喊一个数字，至多 m 个数字，但是每次喊的必须比上一个数字大

这样的话，从 0 开始到喊道 n，可以出现的情况数量就是有限集合，可以穷举了。

*加一个 Map

双层循环肯定不行啊，爆炸了
2 次循环加一个就行了。
先循环一个 List 建立 key:index 的对应 Map，将寻找 A 或 B 中元素的时间复杂度降到 O(1)，再循环另一个 List，将结果合并，Map 里边的 key:index 可能要删掉。
你有些细节没说，具体在特殊处理就好了

这库看起来还行啊
我大受震撼的是这个，虽然说是业务使然，但我依然大受震撼。

https://github.com/alipay/alipay-sdk-java-all/tree/master/src/main/java/com/alipay/api/domain

看你们测试怎么跑的吧，方案很多。CI 里起单独的空 mysql 实例，本地可以使用 docker-compose 拉起一个空 mysql

我判断这个列表是假的。论据有以下几个

1.无论你请求的频率多快，获取的记录数都是不重复的 6 ～ 8 条。这一点其实已经很明显了。
2.请求时并未携带任何有 offset 标记，代码里也没有判断重复。显然，前端认为两次请求返回重复记录的可能性可以忽略，实际上也并未出现重复。这在逻辑上时说不通的。
3.我获取了一千次，拿到 7000 多个结果，没有任何重复的记录，返回的时间跨度是 1 分 30 秒左右。太假了

@killva4624 时间戳有可能是为了避免 get 请求的缓存，和业务是不想关的