可以的，但不要设成同一个频率以免打架。另外最好配合弱信号踢掉，否则可能离强信号很近也不切换。

这种伪漫游与正规漫游相比最大的缺点就是切换时间长，可能长达一秒，所以玩游戏的时候不要跑来跑去。

出国镀金……老外的大学是只有学位证没有毕业证，你这单一个毕业证是否能够被老外认可还是个问题。

看得不是很明白，你是总共每 30 分钟产生一条数据，还是每台设备每 30 分钟都要产生一条数据？

5 秒钟的那个算临时数据，不该进数据库，直接内存里处理就行。

这有啥可争的？非 200 的 http code 也可以返回 body 啊。http 该错就错，body 里附加内部定义的错误码和信息就行了。

国际上时间戳更流行，因为老外需要不停的处理时区问题。数据库里存的都是格林尼治时间，各客户端根据自己的时区再转换。

纯中国市场的话倒是无所谓，后端要求咋样就咋样呗。

我是从那个 html 文件下手，把 URL 对应的内容放在 noscript 里，这样不仅搜索引擎友好，也真能让没启用 js 的房客看点内容。

违法接口的主要客户是操盘者，他们一般使用大量个人账户，而非机构专用账户，来制造涨跌氛围，从而骗取散户跟进。

以前他们都是养一个团队来人工切换帐号和下单，现在有了软件，他们就会成本更低、下单更快，还能及时撤掉没必要成交的单以进一步降低操盘成本。这才是监管部门要打击的。

@feigle 原谅他们吧，毕竟大部分人都没有真正接触过这行，甚至连一个从事这行的朋友都没有。

一提自动交易就是印钞机，一看有监管就是害国害民。根本不知道大部分从业者都在赔钱，也不知道交易所不但不收手续费反而会付佣金给自动交易者以加强流动性。更不会知道这两者结合会产生一种特殊的自动交易者——交易赔钱，全靠佣金赚钱。

oracle cloud 可不是无限免费流量的

现在都是拿空间换时间，这种需求只要不是大到离谱的数据量都可以放内存里用 HashSet 实现。内存才多少钱，O(1)的复杂度不香吗？

银行类的外包还好，毕竟银行基本不招人，全靠外包。有些外包公司甚至就是专门为这家银行开的，在这样的公司干并不会感觉降身份。

只是银行的系统天天被人骂，这样的工作经验以后不太方便作为亮点去说。

正式一点的开发可以考虑一下.Net Core ，又稳又快。用 Nuget 管理包比其他主流语言都方便，搭建开发环境也比其他主流语言快，装个 VS 就全有了。

以前我也是 Ubuntu 粉，但整个 Ubuntu 社区的氛围都太激进，包不怎么考虑兼容性不说，还经常一登录就看见 System Restart Required 提示。这哪是做 Server 的态度？

现在全面转向 Debian 了，稳如狗，真香！

安卓平板缺乏生态，几乎没有厂家会为安卓平板做专用的 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 ，这样就把对状态同步的需求限制到了一个很小的范围内，从而降低状态同步成本。

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