qiayue

摆摊不如去地推

去附近二手家具店买二手 1000 元，能挑到很不错的

我这边排查了一上午，最后统计 IP 发现主要是聚集在江苏，并且找了一些用户聊，都是江苏移动的 4G 不行，wifi 就可以。
大约昨晚 23 点开始出问题的，到今天 12 点恢复了。

我花了 1 小时上线了一个小程序，因为用的 webview 嵌入已经做好的网页版，并且网页版做了微信公众号授权登录，所以小程序真的就是一个浏览器。
写代码加审核发布时间加起来 1 个小时。

@cmdOptionKana 时间戳是唯一的，不存在 UTC 时间戳还是本地时间时间戳。
时间戳的定义式从 1970 年 1 月 1 日零点到现在经过的秒数。

时间戳可以格式化为各地时间，如时间戳 0 值，你格式化为 UTC 时间，就是 1970 年 1 月 1 日 0 点，你格式化为北京时间，就是 1970 年 1 月 1 日 8 点。

@leokino 学习了

@leokino 我是这样考虑的，每个微信号的唯一 id 和公众号唯一 id 肯定是在数据库不同的表里分别记录的。
也肯定会有一张表，记录了微信号和公众号（小程序、App 同理）的关系，在首次产生关系时保存一条记录，同时生成一个 openid 。

在实际使用时，对于传过来的每一个 openid，如果都去缓存或数据库中校验 openid 是否合法，没多大必要，第一步直接通过一个固定的算法去校验合法性，之后解开得到公众号 id 和微信号 id，再去处理业务，会不会更好。

@leokino 的确没学过，但从使用场景来说，能够还原不是更好吗？

我猜是生成的，而且是可以反解的。
你有没有发现，同一个公众号下的不同关注者的 openid 前缀是一致的。
我猜，openid 分成前后两部分，前一部分可以解析出公众号唯一 id，后一部分可以解析出微信号唯一 id，甚至中间有一位是校验位，拿到一个 openid 先用校验位判断是否是合法的 openid 。

至于你说算法是否可能被破解，我觉得总有办法可以解决。