@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 不是一个系列。

你对润这个字，有误解。

主键跟索引是两码事。

主键是键，在关系数据模型中是用来当做不同行之间的区分的。根据自然意义的需要，你应当从列当中选择最具代表性，且最少数量的列，当作主键。但这不是必须的，当选不出来的时候，你可以不要主键，这时候会有一个默认的候选键起作用，即所有列的组合。

索引是在主数据之外，用来辅助查询的额外数据。这其中，如果是树索引，且将主数据直接放到树的叶子节点上，这就是聚集索引。其他情况下是非聚集索引，这时候索引数据跟主数据是分开放的，索引上放的是主数据的地址或引用。

关系数据模型的键，不管是选择出来的主键，还是所有列组合的默认键，是一种天然的索引。这二者之间就这么点联系，其他时刻二者都是独立概念。聚集索引必然要用到这个天然索引，不然是无法将主数据跟索引放在一起的，非聚集索引就无所谓了。是否有主键，不影响是否能用聚集索引，但是是否有主键、主键是否单列、主键的值是否顺序，会极大的影响聚集索引的性能表现。

至于聚集索引有什么好处吗，我也不知道，大概是省了一份索引的空间占用吧。缺点倒是大得要命，它让性能参与主键选择策略。

你可以将 JSON 类型映射到 Jackson 的 JsonNode ，然后用 Jackson 的 API 或者 JsonPath 来读写这个 JsonNode

Spring JPA 的实现 Hibernate ，没有为 PostgreSQL JSON 类型提供基本类型映射，所以这个你只能自定义 BasicType 或者 Converter 。

通过 ID （单个或多个）查询数据，但却没给 ID ，这通常是错误调用，应当抛出异常，但这个异常就仅仅是参数无效异常，并不是提前暴漏出去的错误。

但是，非通常场景，比如说无需区分结果为空的原因是没给 ID 还是给了 ID 但没对应的数据，那穿个空的 ID 列表就是正常参数，无需抛出异常。

其实这个的关键还是要看你对 customerIdList 这个参数的定义，是允许空还是不允许空。

有两个问题：
第一，签名生成过程要私钥，授权开始时间还好说因为你这是人工授权，软件每次运行时间这种实时信息是没法进入签名的。软件每次运行时间这一块，你不联网是很难验证的。
第二，签名之后的证书信息或加密信息，你总要随软件主体一起给出，这个不用硬件加密狗就总有被复制的可能性。

错别字纠正：专门搞技术只是个技术 -> 专门搞技术只是个借口

@ZSeptember #15 你对这个技术误区的理解也是误区。专门搞技术只是个技术，真正的目的是避开酒局、无法自主控制的办公时间、不按套路出牌的甲方等各种烦心事。如果国内把业务沟通都限定在正常上班时间内的台面上，那时候就该找不到五年以上经验的编码人员了。

不止 ERP ，大型企业级应用（面向的用户是企业内部人员），对前端基本没啥要求，你们公司就一个前端更说明这一点。这种职位的非核心性，决定了你在前端技术上是不会有啥提升了。但这跟你的前途关系不是那么大。

如果你计划不跳槽，那么你在公司的前途是由你的业务经验（注意是技术开发的业务经验，不是业务员那种业务经验）而非前端技术决定的。ERP 业务熟练了，你就有了向项目经理、售前顾问这些职位上发展的可能性。就算你不打算往这方面发展，一个业务熟练的前端开发，也足以让你在当前岗位上具备不被廉价毕业生或廉价外包项目代替的资本。