用 zfs 吧，有 snapshot ，还能组 raid ，还能 send 到远程机器。
https://openzfsonosx.org/

@w99wen 毫无意义。签名本身就是客户端提交的，签名也能伪造，毫无意义。

@Ouyangan 难道攻击者不会自己签名？客户端来的数据没有什么篡改不篡改的，不信任就行了。

@viator42 不是减少服务器端压力，是他不用写验证代码了，减少了他的工作量。报告上司把他开了吧，这样的人只会害了贵司。

@w99wen 客户端加盐有什么用？你会加，攻击者不会加？服务器端验证才是正解。

@pmpio 你以为普通话的“的”就不是源自口语？

华为荣耀 5a ， 599 或 699

@neoblackcap 我知道，懒得跟你讲，反正你也只是抬杠。

@neoblackcap 数据库自己没有缓存吗以为？

排序你都不会写，技术能力肯定有限，要你干嘛？
你是在展示自己有多无能吗？

@swfbarhr 我们是 3600 秒，出现问题的话，有一个小时的时间可用于处理，处理故障期间，服务还是可用的， token 还未过期。服务都用 systemd 管理，退出了就自动重启，一直出错就报警通知技术人员。服务不可用这种情况，除非是微信方面的问题，否则不可能出现。就一个 GET 请求，实现复杂度基本为零，可能出问题的只是微信服务器那边。

文档里说的做法已经是最佳的了：
1 、为了保密 appsecrect ，第三方需要一个 access_token 获取和刷新的中控服务器。而其他业务逻辑服务器所使用的 access_token 均来自于该中控服务器，不应该各自去刷新，否则会造成 access_token 覆盖而影响业务；

根本就没有什么并发的事情，你这就是“各自去刷新”，所以才需要锁之类。
如果认为 3600 秒还不够，甚至可以减少到几百秒。 access token 每日限额是 2000 ，你可以算算间隔可以到多少。
这事其实很简单，不用搞得太复杂，用分布式锁之类的，根本就是降低可用性。

我的做法是起一个进程定期刷新，然后存到数据库。其他进程要用，直接读数据库，不依赖更新 token 的进程。
这是一个服务进程，服务在设计的时候就应当考虑到随时可能挂掉，随时会重启。这不是一个脚本，这是一个服务。
如果这个进程无法服务，直接报警，开修。需要 token 的进程也不受影响，因为暂时还未过期，在过期前修好就是了。
并不会出现“挂了重启的话，当前 pending 的请求都会出错，或者超时”这种情况。每次都从数据库里拿的，不用上锁。

我不赞同微服务架构里分得太细的做法，例如用户一个服务，各类内容各一个服务，进程间通讯和同步带来过多复杂度，得不偿失。一个服务应当尽可能少和其他服务通讯，用中间服务来解耦。例如 token 更新服务不能工作，不影响使用 token 的服务，数据库也可以看作一个服务，这两个服务只依赖数据库，而不是直接依赖。数据库是比较稳定的，不会设计成可能频繁重启的。

验证码本质就是阻挡自动登录，你研究出来方法，公开了，他们就会升级
就如直播登录接口，自己知道就好了，私下传就好了，说出来，很快就会被修了的
有路子且有脑子的人根本不会告诉你怎么做，免得你破坏了环境，例如把某些漏洞说了出去，搞到要重新找漏洞
自己研究，或者私下交流吧，毕竟是灰色地带

@sephinh 就是这样

赶紧退货吧，别过了七天了

用 go ，监视文件夹、并行移动、限制并行数量都有了
https://gist.github.com/reusee/cc61fbbcd9229a89ad01cbb6ed97987e

总有人迷信原生，迷信 cm ，结果挡不住国内的流氓应用又说安卓生态如何如何