我能想到的一个方案是，给令牌设计一个特定的字段，比如授权时间。服务器通过 Redis 等缓存，设计一份全服务可用的“用户 ID—允许的最早授权时间”的键值对数据。 鉴权服务器（ auth.mycompany.work ）每次令牌发放，都以当前时间设置令牌的授权时间。 业务服务器（ nextcloud.mycompany.work ），每次令牌验证，额外验证令牌的授权时间是否大于缓存中获取的“允许的最早授权时间”。任意一个服务登出时，以当前时间更新缓存中的“允许的最早授权时间”。

@edis0n0 #5 这个就是 OAuth2 或者类似的过程。

这里面有两次重定向。

第一次重定向，访问 nextcloud.mycompany.work 发现没有登录，它给你重定向到 auth.mycompany.work 。重定向之后的过程就是本地浏览器根 auth.mycompany.work 的通信过程了，如果是标准的 OAuth2 , 每个来源网站的首次登录都会蹦出一个界面让用户同意授权，这里大概率会略去或者隐藏这个过程。

第二次重定向，当浏览器跟 auth.mycompany.work 完成认证授权过程之后，auth.mycompany.work 指示浏览器重定向回之前的 nextcloud.mycompany.work ，并附上 token 。然后，nextcloud.mycompany.work 再指示浏览器通过 LocalStorage 或者 Cookie 保存令牌。令牌保存之后，后面的过程就跟常规的令牌认证过程没区别了。

如果是标准的 OAuth2 且不使用简单模式，在两次重定向之间，会有一个授权代码换访问令牌的过程，不过单点登录过程可以不要这个步骤。



一退全退这个，光凭 OAuth2 就办不到了，上面有人说的“一个应用退出会通知其他已登录应用”的方案也不可行，因为令牌认证模式不是会话认证模式，服务器没法单方面登出。服务器需要借助一些其他手段，能够让令牌集中失效才行。

ISO9001 或 CMMI 规范，是要求文档记录全过程的，这过程就包含代码量，这些将作为项目开发成本估量的指标点。这只是其中一个指标，并且还是考核项目不是考核人的。

不管是对人还是对项目的考核，任何以固定公式计算的考核，就是这公式有上百个考核点，那都是不靠谱的。就更别说代码量、BUG 数量这种单指标考核了。

字符串可以用空字符串代替 NULL ，只要全局约定好即可。但是还是不如不区分 null 或 empty ，统一使用 StrUtil.isEmpty/isNotEmpty 来判断更好。因为有些数据库，比如 Oracle ，它本身是不区分 char/varchar 类型列的 null 和 空白的（这些列 column is null 跟 column = '' 总是返回相同结果）。null 字符串的显示，确实不好处理，但这是纯 UI 层次的问题，ORM 层不应该考虑。

非字符串类型，那就不用说了，如果没有默认值，那就必须提供 NULL 。

如果业务上应该有默认值，最好还是以默认值代替 NULL 。但是记住，这是业务逻辑的要求，不是性能的要求。现行数据库（ Mysql 除外），基本都不会因为 NULL 值影响性能。

利用 Redis 搞延时任务，要用 zset ,不能用 timeout 。具体的我就不说了，因为我也是看别人的，以关键词“分布式之延时任务方案解析”来自行搜索吧。

插电正常，不插电卡，应该跟 Windows 的电源管理有关。“更好的性能”模式这是 OEM 的功能，随着操作系统的升级随时都有可能失效，要开高性能模式你最好还是直接去 Windows 电源管理上面控制。此外，如果是老旧机器，随着散热系统的老化，CPU 频率会被限制的。

但是，即使接电源的情况下，横向情况下，i7 U ，不一定能打台式机的 i3 。如果再纵向比较的话，8 代 i7 U ，可能不如 11 代 i3 U 。Intel 的 U 系列 CPU ，是超级拉跨的。

TrafficMonitor 试了下，不太好用。这是个仪表盘，如果仅仅是用天气预报的时候，干扰性太大了。

@lscbqr #34 你以为人家试用期没过，实际上人家及时止损了。

小地方就别想维权了，没啥用。有两个东西必须要，辞退正式通知、离职证明，不给就耗着。试用期赔偿也就三天，这方面反而公司耗不起。

@vczyh #37 再仔细想一下你说得这两个需求，是不是都用户界面需要的功能，这俩需求即不是 UserServive ，有也不是 OrderService 的目标。

这里的层和模块大致可以如此划分：

用户界面层：用户（再细分为用户注册登录等身份识别部分、我的订单等个人资料纯查询部分）、下单、。以上模块之间存在沟通，但不存在依赖。例如商品结算的时候，虽然它要调用下单方法，但它并不依赖订单模块，因为它这里只需将用户 ID 、商品 ID 等不变的值，作为方法参数传递出去即可。实际上这里商品模块是不能调用这一层的下单方法的，它直接调用的是业务逻辑层的下单方法，由业务逻辑层的下单方法处理完成之后再转给用户界面层的下单模块。这里完全可以认为，购物车结算的时候，购物车只需要把参数扔出去即可，谁负责接受并不归它管。你要有足够的资源，这里完全可以把方法调用模型，换成发布订阅 /推送模型。

业务逻辑层：UserService （这一层就只有身份识别相关的了，各种“我的资料”不归它管了）、OrderService （含写方向的下单、读方向的查询，以及所有与订单数据相关的业务）、UserOrderViewService （这是用来解决用户订单关联查询的，如果只是我的订单这种查询功能，用不到这个，那个靠订单模块就够了，但如果用户界面层有更复杂的查询就可以考虑加上这个）。这里涉及到一些读写分离的思想，但还没到读写分离设计模式的地步，用起来还是很容易的。


对于上面的划分，有几点需要说明一下，如果没理解的话看完下面的回去再看一遍应该就能理解了。

第一，方法 /函数调用，不等于依赖关系，Java 早期的简单分层模型，让人习惯了 Controller 只调用 Service 、Service 只调用 Dao 的模式，进而误以为调用方法就是依赖被调用方法的，实际情况不是这样。你可以在编写 Dao 前编写 Service ，但在 Dao 接口正式编写出来前，你这个 Service 是绝对用不了的，连打桩单元测试都不行，这是依赖。而方法调用不一定是这样，比如上面的下单这个处理，虽然最终运行的时候，是商品模块的某个方法，调用了下单模块的某个方法，但是商品模块可以自行独立开发然后打桩测试，完全不用管对方是否已经完成（双方都可以这样，甚至都不用提前协商好方法参数声明），这是没有依赖关系的方法调用。 简单来说，没有对方就能自行打桩测试的，是无依赖关系的方法调用。

第二，同层之内允许从上到下的调用链，而如果是同层同模块内部，允许双向依赖——不分场合的禁止双向依赖，是违反内聚原则的。

第三，有些跨多个模块的信息，可以设计成不变值（在 DDD 中有专有名词：值对象）。例如向商品 ID 、名称、价格这些信息，可以组合成“商品信息{ID 、名称、当时的价格、当时的描述信息}”不变值，整体作为订单的一个属性。这样对于订单详情界面来说，它只需要从 Order 实体 /表 当中就能获取全部信息，而不用再弄个 OrderGoodView 。

@vczyh #32 如果 User 依赖 Order ，并且 Order 又反过来依赖 User ，那说明你们并没有把 User 跟 Order 解开。上面再套一层，还是没有解开，治标不治本。而且还是用毒药治那种，因为层是个很重的东西，加一层的成本是很高的。

相互依赖，一个原因是同层之间不同模块没解开造成的。对于你这个例子，根据用户 ID 获取所有订单信息，这实际上只是 Order 自身的事，跟 User 屁关系都没有。请注意用户 ID 作为不变的值，即使它是通过 User 生成的，它也不属于 User 而是属于全局，或者所有对它感兴趣的模块。

另一个原因，是根本没用好层造成的。分层既然隔离了技术，那自然要把基于技术的模块划分也给隔离了，不同层的模块划分原则是不一样的。还拿你这个例子来说，根据用户 ID 获取所有订单信息，在 UI 层往往是属于“我的……”这种用户个人资料模块的，但在业务逻辑层，或者数据模型层，它是属于 Order 模型的。

@cxtrinityy #10 就目前来说，IPv6 在中国普及，路还长着呢。我玩一个手机游戏需要用到 V6 的线路，结果不管是家里的 WIFI 还是 手机的 4G 网络，经常断，跟它一个服务器的 V4 线路就屁事没有。基本可以猜测联通的 V6 特么的还是 V6 on V4 ，不是原生 V6 。同样是网络升级 IPv6 跟 3G 、4G 、5G 这些比起来，那是孙子当中的孙子。工信部都快成冷衙门的标杆了，推啥啥不成。

@codehz #3 好东西，其他的用了，天气没法用，要开全局梯子才能用。
@zed1018 #1 刚才发现了，跟刷新机制无关，它现在是在“热门资讯”标题和选择的天气小部件之间轮换显示的。热门资讯内容来自于 https://www.msn.cn/zh-cn/feed ，里面的内容，已经不可控制了，可配置的那个个人兴趣已经不管用了。现在还只是显示个“热门资讯”这四个字，不久后应该就是名为资讯实为广告的内容了。鉴于 MSN 中国的过往表现，那可能连广告都不如，就只是些网上爬的没营养的各种震惊体。

请先了解以下竞价排名。

@phoulx #153 加上一个或多个 X ，所有字都对应唯一的码。

对上负责对下不负责的体制下，盯着某律条文没啥意思。

人怂，只能采用最暴力的手段，莫言。

魔兽争霸“官方”平台，自魔兽争霸升级 1.33 版本之后，平台就适配不上了，凡是战网平台开启自动更新的，现在战网平台和“官方”平台均没法玩。人要天天吃饭，游戏没人那么精贵，但基本上也要月月维护。真正的软件，不是你随便弄两个廉价劳动力就能搞定的。

还有，就算不是游戏从业者或者软件从业者，也应该知道运营、运维不是廉价的，至少不比码农廉价。

超时那个问题，把 future.get() ，换成:
try {
future.get(long timeout, TimeUnit unit);
} catch (TimeoutException e){
// 超时时候的处理，这里你想咋处理就咋处理，但是当前这个任务肯定是失败了。
}