@MuXia 忽略我之前的回复，有错误。各数据库的日期时间保存格式，都不相同，我说得只在 Mysql 上是正确的。映射那里也写错了，与 JDBC 规范不符合。

正确的应该是：
java.time.LocalDateTime ，无时区日期时间（显示值即值，没有内部值，对应的现实时间随时区浮动），JDBC 类型是 TIMESTAMP ；
java.time.LocalDate ，无时区日期（显示值即值，没有内部值，与现实时间没有直接对应关系），JDBC 类型是 Date ；
java.time.LocalTime ，无时区当天时间（显示值即值，没有内部值，对应的现实时间随时区+天浮动），JDBC 类型是 Time ；
java.time.OffsetDateTime ，偏移量日期时间（对应现实完整时间，内部值固定，显示值随时区偏移），JDBC 类型是 TIMESTAMP ；
java.time.OffsetTime ，偏移量当天时间（对应现实当天时间，内部值固定，显示值随时区偏移），JDBC 类型是 TIMESTAMP ；
java.time.ZonedDateTime ，基本等同于 OffsetDateTime ，区别只是一个是 CST 时区，一个是+/-数字时区。

详细可见 ： https://docs.jboss.org/hibernate/orm/5.6/userguide/html_single/Hibernate_User_Guide.html#basic-provided 表 2 。注意上面的 Date 、Time 、TIMESTAMP 都是 JDBC 类型，具体是什么类型取决于各数据库厂商提供的 JDBC 驱动。另外 TIMESTAMP 是时间戳 + 时区，不是只有时间戳。

这里面 Mysql 提供了个狗屎。它的 DateTime 只是歪打正着的跟 java.time.LocalDateTime 对应，但也只在 JVM 时区跟 数据库时区一致的情况下才这样，不一致的时候要出问题。而它的 Timestamp 则完全无法使用。

要是抄来的东西很容易能超过原作者，那国内软件行业早就是全宇宙老大了。软件行业重要的从来都是编码的人，不是代码。

常规数据库有两种日期时间格式，一种是年、月、日、时、分、秒、毫秒组合存储，另一种是时间戳存储，即自 1970 年 0 点开始的毫秒数，内部是数值类型。第一种类型没有时区（查询出来的显示值，不随环境变量当中的时区而改变），Mysql 还细分为 Date 和 DateTime ，Oracle 则统一为 Date ，对应的 Java 类型是 java.time.LoacalDate 和 LocalDateTime 。第二种类型有时区（查询出来的显示值，随环境变量当中的时区的不同而不同），有的数据库单位直到毫秒，有得能到微秒，对应的 Java 类型是 java.sql.Date 或 java.sql.Timestamp （取决于要哪个单位）。

一般来说，如果是新项目，一律考虑使用 Date / DateTime - java.time.LocalDate / LocalDateTime ，即使要国际化（时区上你可以在程序层面再控制转换成 ZonedDateTime ，甚至还可以将时区国际化直接交给前端处理），在数据库上处理时区会是个灾难。

@ysc3839 #10 你的测试，并不能说明啥情况，影响的因素太多了，比如这是因系统自带而重新安装的驱动，又比如这是恶意软件已经入侵的系统文件里面的东西。你用 LTSC 测试也不靠谱，因为 LTSC 虽然叫做企业版但实际上是官方精简版，出现各种莫名其妙问题是正常的。

Windows 的 100M 隐藏分区必然存在，除非是私改的 Windows 。然后 Windows 重置，是运行在 Window RE 环境上，与主系统无关，它不需要主系统的任何驱动。

如果考虑到恶意软件，以及病毒对系统的破坏，这个时候重置确实不如格盘重装，但这个时候不用提醒，一般人也不会考虑重置。而通常情况下，重装并不比重置好多少。

docker 镜像下损耗真大，连原来的 1/10 都不到。

@ysc3839 #8
我如果不是看了驱动程序位置的位置——C:\windows\System32\DRIVERS\***.sys ，我就准备找时间自己去测试了。你还是放出你的测试实况吧。至于你说得网络相关文件损坏，去了解一下自从 Win7 就有的隐藏分区。

OEM 密钥我没试过，但要真如你说的，Windows 重置功能压根就不用出，因为该功能跟直接重装系统的最大区别，就是 OEM 系统不好重装。

@julyclyde #5 消息丢失是订阅方的问题，不是发布方的问题。RabbitMq Exchange 就是个典型，消费方下线的时候，生产方发布的消息就奔向太空了。

说轮询弥补消息丢失其实不完全对，真正弥补消息丢失的，是发布方保存（暂存）消息+订阅方轮询。

简单得很（不简单），把 OA 依赖得用户授权也拆成独立模块。拆分从来都是业务拆分，不是物理位置拆分。你这个系统（含用户）、OA 的拆分导致业务双向依赖，是很不好的拆分。业务依赖方向应该是：应用程序，OA ，系统底层。其中只有应用程序是可启动的，后面的都是不可启动的库。

关键词：子域、限界上下文、值对象、最终一致性。

这两个提醒属于费工夫不讨好的提醒。

用在生产库上没用：1 ，这种备份作用很有限，一天一备份间隔时间太长，热机备份不能直接用来恢复，冷机备份又要先停机； 2 ，啥都备份等于啥都没备份，这种备份压根没法用来恢复数据。

用在个人库徒增工作量。

对于在程序之外动生产库的操作，一减少二增加操作审查流程，要比上面的方式有效多了。

会楼主一下，如果是动了磁盘分区，那神仙也救不了。

重置别说其他盘，默认情况下连用户文件都能保留。我猜你选择了最高级别的格盘重置，并且还动了磁盘分区。
@ysc3839 #2 重置就是重装。OEM 系统你用其他安装方式会丢失激活凭证，更别说你要选择保留 windows.old 那就跟重置没啥区别。要想彻底干净，必须格盘，跟你是重置还是重装没关系。

首先来说，经历了几个次世代之后，两个平台都没啥缺点了了，所以入门级别选哪个都行，发烧友级别要两个都要。

再次就看你要哪个风格了，XBOX 代表欧美风格——开放但不时弄些骚套路，PS 代表日系风格——严谨但也极度保守。

@frodez 实际上你并不知道，甚至只是了解一下 Java 的异常机制。Java 的异常机制是：该是自己的事就 catch 住自己处理，不是自己的事就 throw 出去。该自己处理的自己处理，不该处理的抛出去而不要隐藏，这是即正确又方便的事。按照你的思路，来了错误不管是不是自己的就硬去处理，那才是不正确的事。

此外，统一的错误处理逻辑也不是偷懒，它要在全局层面管理异常，需要花费更多而不是更少的精力。那种捕获到异常就只提示一个“有错误”的统一错误处理才是偷懒，但这不是全局异常处理专属的，if (err ） then print "有错误"，也能这样偷懒。

@Cmdhelp #4 Lambda 就会让你多一份技能，而 Stream API ，会引导你走向流式数据处理的大门——艺多不压身。
@statumer #12 当数据量级小的时候二者没区别，当数据量级上去之后，stream API 对性能更好。

抛弃上面的不说，Stream API 在编码友好性（主要是链式操作），跟可读性上（ Java 8 的还因为 API 不完善导致由局限，9 、10 之后就差不多完善了）都有很大的提升。OP 的观点只是略有不妥，而上面有些人，那是不学无术还要瞎叫。

Spring 6 / Spring Boot 3 要以 JDK 17 为基准版本了，这回 JDK 8 终于要到头了。

很多人不会，不代表不主流。JVM8 也不是主流，不管是 Eclipse 还是 Idea ，老早就强制升级 JVM 了，所以至少 IDE 端，已经早就不在 JVM 8 跑了。