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

@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){
// 超时时候的处理，这里你想咋处理就咋处理，但是当前这个任务肯定是失败了。
}

提醒你一点：你提交给执 Executors 的是一个实现 Callable 接口的对象，不是 Callable 类的对象，这个对象不只有 call() 方法，是可以定义其他字段的。

所以你没必要在 call() 方法中去生成或申请那个资源，你可以在你实现 Callable 的类（别再用匿名类了）上定义一个字段来映射那个资源，然后在提交到 Executors 前就给它设值。这个设值过程，就跟线程池或异步执行器无关了，就是典型的单例模式。

上面不会解决你想要的超时处理。

@abc0123xyz 你要多个线程对同一个对象互斥，又要这个对象依赖的第三方对象能被多个线程复用。这是要一个并发场景下的共享对象，一部分状态是隔离的，另一部分状态是公用的，这是不可能的。

狗日的，我看你的描述头疼的很。

首先，你到底有没有这样的数据或者业务要求：最多一个线程处理它，如果是多个线程同时处理的时候，必须排队。如果没有的话，就别提在关注这一点。我看你的业务场景压根不涉及并发加锁。

台式显示器不出家门，甚至桌面都不出，做薄的好处就不大了，在考虑到做薄的坏处——刚性差、散热不好、设计成本等，自然就不会做薄了。当然高端装逼显示器，还是会做薄的，不过一般人没钱买而已。

拼音输入法重码太多，隐私跟输入效率只能二选一，不可能有完美的。如果愿意投入精力去学习的话，要像初中生那样投入精力，可以试试无重码方案的仓颉输入法，用 Rime 就可以支持。五笔据说没有记忆效应，停一段时间就全忘，而且五笔还是有重码的，所以不推荐。

没有私钥不行，因为根据私钥可以设置 pin 码这情况看，客户端每次登录都是要拿私钥重新生成签名的。

但是有一个方向楼主搞错了，SSH 无密码登录，不是服务器生成密钥对再分发的方向，而是客户端自行生成密钥对后把公钥报给服务器。这个方向是客户端主服务端从，不是服务器端主客户端从。当要在不吊销用户的情况下单独吊销登录凭证的时候，服务器唯一能做的就是 authorized_keys 中移除对应的公钥。所以这里建议要么一用户一人，要么一密钥对一人，不能共享的。

@optional 首先这是个好东西，楼主可以考虑直接用了。

然后还是要做下名词解释：
JPA 是 Java 实体持久化标准；
Hibernate 是 JPA 的一种实现库，类似的实现还有 EclipseLink 等等；
（背后的话，JPA 3.0 标准是基于 Hibernate 提取的，但这不影响 JPA 是独立标准；）
Spring Data JPA 是一个再次封装、更容易直接使用的库，它理论上是再封装 JPA ，但实际上是再封装 Hibernate ；
vladmihalcea/hibernate-types 这个，算是 Hibernate 核心的第三方扩展；

@muchenlou 我再看了以下，这个不只是类型映射的问题。PostgreSQL JSON 类型是非普遍的 SQL 类型，它连 JDBC type 都是自定义的 1111 ，这种情况 JPA 短时间（可能 10 年）内是不会考虑对它的支持的。这里就算你用 CUstom Basic Type 或者 Converter 解决了实体映射，在映射后的实体上也只能把它当成 Object/String 来用，最多当成只读的 JsonNode 。像部分修改 json 的值，通过 json 的特定属性来查询这些功能，都是用不了的。上面这些功能你必须要用脱离 JPA 标准的 NativeSql 来做。

我得建议是，不要再考虑映射 JSON 类型了。增加一个 varchar 或 clob 类型的列，映射到实体类的 String 类型上，额外限定该字段（对于实体类的上层应用来说）是只读的。原有的 JSON 类型的列，对实体类不可见，只能通过自定义 Repository 并使用 Native SQL 来访问，且自定义 Repository 需要负责这两个列的值的同步。当然如果你不需要 JSON 类型列的特定功能的话，你就直接 String 映射 varchar 或 clob 类型的列 即可，上层程序中自行处理 JSON 即可。

@HHHorz #11
@facelezz #15
看题，spring jpa ，这是 JPA 标准 Hibernate 实现，跟 mybatais 不是一个系列。