窝草，面试都能模拟的。。。面试不是就两个方面嘛：技术；侃大山。模拟前面的没意思，几斤几两自己不知道么，模拟后面的我不是闲的。。。

lzsb

@yanjinbin 印象中 effective java 有这一则的，避免类被不必要的构造。工具类正是该使用场景吧。有些源码的 utils 里也有这么写法的。

园区，java，凑个热闹

时间管理，找李笑来啊

干，我猜鹿晗。但也可能是王宝强，毕竟阿汤太优秀。

写 Java，大多是生计所迫啊。特别是 WEB。

有看过这样的类比，大多数程序员工作时是用购物时的心态写的，阿这个我要，阿这个可以换成这个，阿这个颜色好像更搭，阿这个东东我到底需不需要，阿这样会不会太多了……

编程的视野是受货架决定的。

这里主要 Java 的超市比较大。比较大。而且实惠又耐用，逛的人自然多了就。

但光会逛也不行呐，bug 们可都在超市门口等着呢。

关于密码这个，如果是公积金密码的话，会有密函发到单位的。并不是默认 00000 或 111111。
别输了几次还密码错误记，结果账号被禁个一天。。。

@baiyi 看下 95，我上面说错了，骚瑞 all。

流口水 ing，楼主好帖！

个人写 Java 维持生计，Spring Cloud，一把梭。

@gmywq0392 干，应该是 hacker news。第二段有个错误，“如果 token 里的加密算法是由客户端决定的” 应该为 “如果 token 里的加密算法是可以由客户端决定的”

hack news 上有很多讨论，看上去主要是对一个既有的 token 没有一个理想的失效机制，但在 token 里面放个 expire 的方式感觉就能解决了哇。v2er 有兴趣可以看下他们的讨论，看看我们还有什么未论及的弊端。
1. https://news.ycombinator.com/item?id=13865459
2. https://news.ycombinator.com/item?id=11895440
3. https://news.ycombinator.com/item?id=14290114

还有一个问题就是 jwt 头的算法标识，如果 token 里的加密算法是由客户端决定的，那么服务器的每次校验签名，都是根据那个算法来的，这个会让服务器显得很肉鸡。这个个人觉得相当尴尬，不是我们开发人员能允许的存在。

另外啊，使用上来讲，jwt 和传统的 session cookie 就像传值和传引用一样，如果想够纯粹那就不能每次都 hit db or redis etc，这时 token 里的内容就会敏感起来，会担心它的泄密与可靠，在这个点上，假设 token 是不对外暴露的（ https ），难以模仿的或者说模仿成本过高的（哈哈一个可行性猜测），那么适用性就广泛些。做不到以上的话，还是建议只用作微服务间内部的通信凭证，与 C 端的通信，由服务网关那维护 session 的机制。哈哈这里又 stateful 了。

LG 的几款旗舰还不错啦，可以看看的。

frp

这么个法子不知道对不对。
先按照你业务约束的 id 权重顺序写个数组*。
然后做 table(或者说是 object)给他个 comparable 函数，具体就是用 item 的 id 去按照*的索引排序。然后再取该 table(或者说是 object)的 first item 不就…

无所谓的熵增。

@pigzilla Java 系的开发框架，可谷歌。

facade，一定有人读错哈哈。