道理我都懂，但是这个不是可以切换为纯白的样式么？？

https://ww1.sinaimg.cn/large/760b39b3gy1go34c3vp6kj20f40lwac0.jpg

单纯就 『求职者需要实名认证』这件事来说，我觉得没什么问题。


至于潜在的信息泄露，或者信息滥用，如果确实有发生，那肯定是大问题，但是似乎没有直接证据表示发生了信息遗漏或滥用？

DNS System

@dingdangnao #2
很久以前就有百度云记事本了：

https://baike.baidu.com/item/%E7%99%BE%E5%BA%A6%E4%BA%91%E8%AE%B0%E4%BA%8B%E6%9C%AC

https://apps.apple.com/cn/app/%E7%99%BE%E5%BA%A6%E4%BA%91%E8%AE%B0%E4%BA%8B%E6%9C%AC/id594413988

@ssshooter #7
我觉得 Cloudflare 应该不至于犯这种低级错误，建议确认一下情况。

既然已经 powercfg 了，那先查查唤醒？

powercfg -lastwake
powercfg -devicequery wake_armed
powercfg -waketimers
powercfg -requests

@alfchin #1
楼主说的是 xxx.com. 最后面的那个 『点』


实际上，域名是树形结构，最基础的就是根域，也就是这个 『点』；
所有的域名最后都应该有这个 『点』，只是日常使用中通常不写而已。

如图：
https://ww1.sinaimg.cn/large/760b39b3gy1go1wl5z5v1j21i00u07c3.jpg

米聊于 2021 年 2 月 19 日 12 点 00 分停止服务

刚好头七，头七回魂夜诚不我欺

https://ww1.sinaimg.cn/large/760b39b3gy1go17oegugfj20hs0a2tis.jpg

@beryl #17
当你再下第三个订单的时候，keys product_{product}_{user}_* 就变成 2 了，
此时你再想下第四个订单，就需要等第二个订单超过 24 小时。

这个方法的缺点还是 keys product_{product}_{user}_* 的效率比较低，性能差。

有一个优化方案是做一次剪枝，大部分用户不存在 24 小时内购买过商品，那么我们设置一个 『用户是否在 24 小时内购买过商品』的 key 就好了。

也就是每次用户产生购买行为，都 set product_{product}_{user} timestamp expire_time （不论原 key 是否存在，都续期 24 小时）

这样对于大部分用户，只需要查询 product_{product}_{user} 不存在，就可以认为不存在限制了。

而对于 product_{product}_{user} 存在的用户，再进行 keys product_{product}_{user}_* 查询，确认具体是否超过了限制。

@beryl #11
2021-02-27 18:00-20:00 的时候，第一次购买的 key 已经过期了。

此时 keys product_{product}_{user}_* 只能查出 1 条购买记录，没啥问题啊。

@beryl #9
我说的不能购买，就是指第二次购买后覆盖了过期时间。


我的方法里，key 是包含了 timestamp 的，第二次购买的时候设置的是另一个 key，不存在覆盖问题。

@beryl #6
如果按照：
set product_{product}_{user} count expire_time(当前时间+24 小时)

那么距离第一次购买 24 小时后，仍然无法购买了。


可以改成

set product_{product}_{user}_{timestamp} timestamp expire_time(当前时间+24 小时)

取数量的时候 keys product_{product}_{user}_* 就好

@loliordie #6
@SpiritQAQ #8
不同品牌显示器的场景我一直用，好像没出现过类似问题。

我有锁屏的习惯，长时间不使用的话会直接 Sleep Display 或者锁定屏幕，不知道是否有关。

『 24 小时内』 指的是滚动的 24 小时，还是固定的 24 小时（ 1 天）。

前者：昨天 8 点 1 次，18 点 1 次；今天 0 点不能购买。
后者：昨天 8 点 1 次，18 点 1 次；今天 0 点可以购买。