应该是代码的问题，某种特定情况触发的吧。132 是 service 不是 mapper 也耗时超过两秒（ 132 那个函数是不是进入会开事务？）。138 那里，一个 service 构造要 10ms 也有点奇怪（有申请什么资源？）。不是启动就应该注入完了？还要动态生成 service ？

可能考虑以后量大的时候能够容易扩展？ in 的值多了也不走索引。

@lazywen 同遇到，也没有解决思路。

二周目奋战到 2/3

每轮从[1..m]的 m 个数选择，找出和为 n 的且最后一次选择是 1 的排列，以这些排列总数作为分母 s，s[i]作为第 i 个人输的排列总数(i 由 1 开始)，对于每个排列长度 l，s[l%n] += 1，s[i]/s 就是第 i 个人输的概率。

@hnbcinfo 现在那里还能买到非智能电视？几年前买电视就没有找到非智能电视。
假如不是追求视觉，我推荐三星，三星冷启动（出门都会关所有电源）秒开，又没有广告，感觉是可以替换传统电视的智能电视。不过不知道三星电视现在还有没有用自研的系统，还是转投安卓了。

@noe132 #1 这种二进制编码的方案只能找 64 瓶里只有 1 瓶有毒的情况吧，混合出来的 64 瓶远远不只 1 瓶有毒。多瓶叠加在一起，无法用 6 只老鼠来找出吧。
没有想到单次校验的。
我的想法是 8 瓶分成 2 批，再用这种位编码的方式来找出每组里有毒的。具体会产生两种情况：
2 批都有死或者都没有死，这样用位编码方式来算，用 4 只来试就可以。
另外一种情况就是只有 1 批有死。这种情况有分为两种子情况：1. 没死的那批，00 是有毒的。2. 2 瓶有毒都在 1 批。
针对子情况 1，找没有死的去喝 00，挂了就出结果。没有挂的话，那么现在还活着的还有 4 只，4 只对应有毒的那批的 4 瓶。那么结果也可以出来。

@0o0O0o0O0o #193 感觉你误会了我的意思，我回复的前半段是支持楼主的观点，tls+双向证书可以替代签名。后半段只是拿个类似的安全问题吐槽。并不是要在 app 上实现双向证书 tls，我只是吐槽安全把问题弄得复杂到业务实现 tls 双向证书。

@nikan999 hash 用于完整性校验没有问题。我回复中提到涉及的 hash 的问题是，拿一个公开的盐来 hash，然后把这样的算法定义为签名，这样的认知上的一个问题。

我站楼主，双向证书的 https 就可以解决楼上很多人说的认证问题。现在很多第三方支付的接口用 rsa 的就是要先登管理平台上传商户证书的。
今天才和安全怼过这个问题，搞到最终的方案就是在 https 上套多一层业务自己实现的“tls”。安全还称 app 上加盐 hash 能够防串改，称 app 上的加盐 hash 是签名。公开的盐都不知道是谁的名。

2018 可以不用 mod.rs 。写 mod xxx，有什么不好，这样更明确清晰。

交给 rustfmt 烦恼

虎门新盘都 3 万多了，回老家也买不起房系列

珠三角以为都是北方吧。

好吃不好吃的大米是怎么分的？

幽城幻剑录

详细看了一下：
1. com.mysql.cj.protocol.a.NativeProtocol 的 configureTimezone 方法，会获取 mysql 服务器变量 system_time_zone，我的 mysql 中这个变量是 CST ；
2. 接着，通过 TimeUtil.getCanonicalTimezone 这个方法，把 CST 转成唯一的时区表现格式；
3. TimeUtil.getCanonicalTimezone 最终是从 sun.util.calendar.ZoneInfoFile 里获取到 CST 的映射：{ "CST", "America/Chicago" }；

所以，客户端误认为服务器使用 Chicago 的时间，上送时间时就会转换成对应的 Chicago 时间，但服务器实际是使用北京时间，所以导致服务器保存的时间与实际相差了 13 个小时。

@JasonLaw 具体我也没有深入研究，我猜是服务器返回了 cst，mysql connector 就按美国 cst 时间来计算，传给服务器的时间就是西五区时间，也就是我国时间减十三小时。
其实，我主要想表达你说的默认时区是西五区的说法是有问题的。一般来说有默认时区也应该是 GMT 。

@JasonLaw 不是默认时区是-05:00，是中国的时区缩写是 CST，美国 Central Standard Timezone 缩写也是 CST，mysql 默认认为 CST 是美国那个时区。

没有人好奇，楼主看不懂的是链表的什么问题吗？会不会不是我们想的链表呢？

最近看回大半年前写的 leetcode 代码也是脑壳疼。