amazon

以我的经验，jd 后面更优惠

new ArrayList<>().var 回车 shift+tab

依据是老婆喜欢

不太懂电车啊，但是楼主发的这个理想 L7 的续航是认真的？

滴滴现在是有点贵，现在朋友喊我去喝酒都不敢去了，代驾回家小两百块，都差不多可以买瓶酒自己在家喝了。。。

楼主碰到好人了

我老婆说跟车跟电车是脑子坏掉了

sony 回音壁

Factory ，你的对象都有百来行才能构建完成了，应该是个比较复杂的业务场景了，引入 factory 是个常见的做法，可参考 DDD

一点点个人理解：
1. 传输方式和传输内容是两个概念，早些年只有 web 端所以可以用 cookie 传，现在既要考虑 web 又要考虑 app ，所以一般不在 cookie 中传认证信息，而放在 header 或者 url 中
2. 传输的内容可以是一种特定格式的，也可以是无意义的字符串；特定格式之一就可以是 JWT ，自定义格式通常是无意义的字符串
3. 如果传输的是 JWT 格式的，得益于它的自包含特征，服务器端可以不依赖任何存储机制，实现 SNA 架构；但是特定格式的例如楼主所谓的 session token ，仍然需要一个共享的 redis 存储服务之类；在这点上采用 jwt 是有优势的。
4. jwt 只是一个 token 格式，把生命周期的问题全部归到它头上是不合理的；不能因为大部分的滥用否定这项技术
5. 解决 token 有效期过长的问题，业界通行的方法是 access token 加 refresh token 的方式，access token 的有效期很短，refresh token 的时间长；这两种 token 并没有严格的格式定义，采用随机串和 jwt 格式都是目前通行的做法
6. access token 和 refresh token 的方案很成熟，但是很多人不按照这个标准来用，总是自己实现各种认证服务各种造轮子，然后再说 jwt 不行
7. 修改密码让现有登录信息去失效这个问题，采用无状态的架构是比较难实现的（包含 refresh token 这种方式），因为在这个需求下时间本身就是一个状态属性；这个时候用 session token 这种需要中心式存储的架构来解决这个问题是合理的，但是反正架构都改了，总是要在服务端同这个存储中心进行交互的，这样即使是使用 jwt ，在里面再存储个关联到 redis 中的变量然后走和 session 一样的认证逻辑也可以了，只不过是多次一举而已。

身份认证方案是个很有意思的话题，有各种方案和解决办法，各有各的优势和不足，例如 Rails 中很早就有将信息存储在客户端（ cookie ）而不在服务器端进行任何存储的方法，但是又实现了 session 机制的安全性和生命周期需求。

我的刚刚也调整了，符合条件的大多数银行都是 9 月 25 号自动调整，不用申请

这两年我们自己吃和送都是买的美心

sftp 就可以了

竟然真的有不买商业险的，楼主猛人