安卓平板缺乏生态，几乎没有厂家会为安卓平板做专用的 app 。我充话费赠过一个，不知道能干啥用，劝你别碰。

学之前跟楼主一样的想法。

学之后——我艹，真香！

@sillydaddy 再说直白点吧，重疾险就不是用来保被保险人的，而是保他家人的。所以重疾险应该买给家里的经济支柱，而不是小孩什么的。

以死亡为赔付条件的寿险也是类似的目的，只是它的赔付率比重疾低，所以便宜点。

真想保障被保险人自身，应该买医疗险。

其实保自己和保家人有一个最明显的区别——保自己的都是报销型的，因为你不知道自己遇到困境时到底需要多少钱。而保家人的都是定额赔付，因为你可以根据自己的收入和负债情况估算需要给家人留多少钱。

这个问题的根源在于大家对保险还是不懂，甚至包括一些保险销售人员。

重疾险听起来像是用来治病的，但其本来的初衷是用来防止人们因为重疾而失去劳动能力，从而给正常生活带来压力的。

所以重疾险就应该是“保死不保病”的，而不懂的人却以为自己病不是很重的时候就能获赔，从而产生了认知错位。

当然，保险公司也不是不能设计那样的产品，只是价格肯定也要更贵了。又想便宜，又想早赔，那是不可能的。保险不是彩票，从来都不是用来赚钱的，只能帮你在困境中稍微好过一点。放平心态，真正理解保险，才能真正用好这个避险工具。

@VeryZero refresh token 每次使用都要校验状态。

至于什么时候拿 refresh token 去换取一个新的 access token ，那是客户端的事。它可以在 access token 即将到期时主动更新，也可以在服务端返回失效错误后再去更新，还可以在任何自己认为需要的时候去更新（比如自己刚修改了密码，于是立刻去获取个新的 access token ）

@xtinput 其实没必要那么复杂，refresh token 更像传统意义上的 session id ，能拿到这个信息的人，基本用不到这个信息就可以直接干坏事了。

现代架构之所以用 token ，是因为后端普遍采用分布式，各服务器之间同步状态（比如 session ）的开销很大，所以干脆不用状态，而是给个 token ，后端各自验证 token 的有效性而无需与其他服务器沟通，这就是所谓的 stateless 。

stateless 在绝大多数时候都没问题，但我们却不太可能实现彻底的无状态。比如用户修改了密码，服务端想强制他重新登录，这就得通知各个服务器不要再接受之前的 token 了。

要解决这个问题，常见的有 3 种方法：
1 、找个地方（内存、数据库等）记录合法的 token ，每次验证 token 都查一下这个 token 是否还在。
2 、找个地方（内存、数据库等）记录 token 的黑名单，每次验证 token 都查一下这个 token 是否在黑名单里。
3 、让 token 自己失效。

前两种都是有状态的方法，仍然避免不了状态同步的瓶颈，所以我们一般采用第三种方法。

那怎么让 token 自己失效呢？ token 里一般都有时间信息，所以只需把有效期设得短一点，不再更新它，它就过期失效了。

这就引出了更新的问题，怎么更新 token 呢？我们一般用另一个 token ，这就是所谓的 refresh token 。服务端收到 refresh token 以后，是要检查黑名单或者白名单的，所以更新 token 这一步是有状态的。只有 refresh token 有效，才会下发 access token ，这样就把对状态同步的需求限制到了一个很小的范围内，从而降低状态同步成本。

自此，有状态和无状态实现了有机结合，在一起过上了幸福快乐的日子。

5 楼正解。简单来说就是 access token 负责效率，不查验状态直接用。而 refresh token 负责安全，每次使用都要查数据库，从而实现服务端注销等操作。

@yyingx 时区不同都不算啥，关键还有个夏令时，有的州用有的州不用，结果就是夏天的时候你就算正直往北走，时间都得变了。

@ACEonly 你这是理想情况，事实是很多网站根本没这要求，只要别人拿你邮箱注册了，你就会持续收到广告。

我为啥知道？因为我也是这种事的受害者。

老外曰：It’s part of your business.

@88274382 你这是杠你自己呢吧？小米又不是偷摸加时间限制的，都是公开的。按你的逻辑，不能接受这一点的就不买小米呗

虽然没看过文档，但感觉用随机数不如直接用时间戳，超时忽略即可。

至于说维护一个 request id （随机数）的库就更不太可能了，分布式系统同步这个数据的成本可不低。

当年 MD 可真是领先时代的，也成为继磁带、CD 之外的第三种标准媒介，很多唱片都有 MD 版发行。

可惜就是太贵，没有特别流行，但也没死，直到后来出了 mp3……

因为修改一个地方（类、方法等）很可能会导致调用方跟着修改，这是麻烦且不可预期的，很容易导致故障，所以禁止修改。

但你也不应禁止别人在你的基础上扩展，否则只能用你提供的功能就太局限了。

这是个指导原则，脑子里时刻想着这些，你在设计代码结构的时候就会更优雅。各种设计模式几乎都是这个原则的优秀实践。

@razios 因为他们解决的是同一个问题，就像馒头和米饭都能吃饱一样，虽然南方人不拿馒头当主食，但也不是不能吃

咖啡圈都推荐仿 S ，最高性价比的入门级意式咖啡机，没有之一。再加一两千买个磨就齐活了。

体制内的项目……呵呵，呵呵，呵呵呵呵呵

跟一个体制内的朋友聊天，他说他们单位刚刚定制开发了一套系统，特别牛逼，以后办公效率能提高好几倍，省长都来参观。

我看了一眼，确实很强大的样子，就问他花了多少钱，答曰 30 万。又问开发了多久，答曰一个月。

我说，这系统在中关村的话得做一百万预算，开发周期半年。你们这 30 万，领导再克扣点，到乙方手里就一二十万了，也就做个面子，难怪一个月就做完了呢。

果然，后来他又找我诉苦，说系统巨难用，领导还怪他们用着新系统，效率却变低了，现在大家都苦不堪言

换个角度想——Dell 不管你用不用都要卖你一份许可证赚钱，而联想允许你选配，你更喜欢哪种呢？

@zhoujinjing09 fargate 是类似于 k8s 的服务，跟函数计算还不是一回事，虽然都属于 serverless 。

PS：楼主如果是来寻求解决方案的，楼上已经有人给出了，配置.env 文件即可。如果只是想吐个槽……