另外 redis+token 就是 session 方案，不管你的 token 是 jwt 还是其他 token 。

jwt 所谓的无状态，是指自包含状态，每次请求时携带状态。

如果状态下沉到持久 /缓存层，jwt 所谓的无状态并没什么太大的优势。


强烈建议各位看下 redis 官方博客这篇文章： https://redis.com/blog/json-web-tokens-jwt-are-dangerous-for-user-sessions/

oauth2 不是给三方授权的吗？一方系统用不着啊

@lanlanye FP 也不用入邪教，就对写清晰好测的函数，从小到大构建系统整体或者局部有帮助就行了。 我之前看的是《 functional programming in scala 》以及杂七杂八文章。比如所谓的无状态，其实是把状态推到其他地方隔离起来了，这样关键性的一部分函数就可以是纯的了。

保价的事我有经验，先打客服，不同意没关系，直接 315 投诉，乖乖给你打电话来协商解决。

DDD 就很玄，不如 fp 思想来的实在。

跑步，少碳水多蛋白质，晚上少吃。 两个月瘦回正常范围。

@tinotino654321 跟依赖循环没多大关系。主要是依赖应该不应该放在构造函数？能不能被 mock ？ 你可以想象如果提供给外部使用，就需要问自己两个问题：1. 什么是必须的什么是可选的？ 2. 什么是可以被修改的什么是不能被修改的？

如果依赖是创建对象时必须的，肯定是构造器注入。否则应该用 setter 注入，最次是 field 。

以上是基于：1. 依赖是否必须在构造对象时提供，2. 方便 mock

但实际使用使用是另一回事。用 spring 那一套，即便用 filed 注入一般也没什么问题

牛逼

xps15(狗头

java optional 表达能力有限，能获得收益的场景并不多。

刚好之前做了一点工作。主要是 decoder ，contract 参考`https://github.com/giiiiiithub/web-components/tree/master/feign-client/src/main/java/com/jj/web/feign/client`

聚合谁来做的问题，后端懒得做让前端做了。这后端有点懒了，api gateway 其职责之一就是组合内部服务 api 对 client 提供服务。

github light

环境先搭建起来

需要注意的是如果用了事务，用 this 会导致事务不生效。

@olist 擦，还真是，第一个不是选择排序。。。。。确实是一种没见过的排序方法

能防用户拍照嘛

第二个是选择排序，每轮选择最小的排在左侧，跟标准写法比 swap 次数多了。

第一个是循环次数比第二个要多的选择排序，不过是降序。。。。