现有 switch 、ps4pro 、x1x 、ps5 和 1070 台式机的全平台玩家告诉你
选 PS5 。
个人对价格并不是很在意，追求的是在哪个平台的体验更好。最重要的是看厂家的态度。大部分游戏厂商都是亲 ps 的，尤其是日厂。
现在女神异闻录 5 、神海、旺达与巨像、神秘海域、声名狼藉次子、吃人的大舅、血缘仍然是 ps4 上的独占游戏。
合金装备 5 是索尼做的汉化。蝙蝠侠阿卡姆是 ps 平台画质更好。
漫威银河护卫队、如龙会利用 ps 手柄上的扬声器功能，说明人家更愿意适配 ps 。
控制在 ps5 上有用上自适应扳机功能，体验非常好。
其它的尼尔、仁王、怪物猎人世界、最终幻想、COD 等游戏都有明显的亲 ps 倾向。

1 、Lambda 是肯定要用的，要不然多麻烦
2 、时间的我也喜欢用时间戳计算然后转成 Instant （时间段长度固定，与时区无关的情况下）。其它几个用的比较少，数据库里存的和返回给前端的都是毫秒时间戳，交给前端去格式化。但 Date 、Calendar 肯定不用。
3 、try-with-resources 会用，但用的不多。因为如果你调用的方法会抛出检查型异常的话，那么放在开头的括号里的很麻烦。（我倾向于方法生命无 throws ）
4 、stream api 用的挺多的，但 for 也在用。
因为 stream 中间有个函数会抛出检查型异常的话，处理也比较麻烦，不优雅。或者只是 steam api 用得太多了。

只考虑 LTS 版 Java ，现在开新项目已经可以直接上 Java 11 了。
那乐观估计，2025 年至少得开始学 Java 17 了。

顺便问一下，学新版本是只看新的部分还是直接重学当复习比较好呢？

这种结构不属于 Java 的“包袱”而是财富，Java 根本没有规定要这么处理。
搞成这样的本质原因是大部分人根本不知道怎么设计一个项目的代码结构，目前的结构是优胜劣汰下来的、有成功经历、受到广泛认可的，统一的设计也促进了 Java 生态圈的发展。

但这种结构确实不适合直接拿到别的语言里，只能拿来参考。之前接触 nodejs 、python 后端的时候，按 Java 的方式写会怪怪的，不按它的写又不知道怎么组织，很头疼。

All in two ，NAS 就负责存储。
/t/860324

中间为啥要放个 Nodejs ？

Typora 用的 Mac 的 webview ，虽然体积小了，但性能不好：/t/837163
1.2 版本以后对图片做了优化，顺畅了不少，但我感觉性能还是比不上 Electron 版。

同#2 ，不过那是阮一峰 ES6 ，先把他的 ES5 学了
https://wangdoc.com/javascript/

引用知乎的：
db 访问分为这么几种
1. 写 sql ，各个 db 差异要自己适配
2. 写 dsl ，屏蔽了 db 差异，自动适配
3. 运行时或编译时自动合成 sql ，屏蔽 db 差异

我是第 3 种动态生成 sql 的，用的是 JPA 的 Specification ，代码大概是这个样子：
Specification<RecordPO> spec = (root, query, cb) -> {
Path<String> termPath = root.get("term");
Path<Long> beginTimePath = root.get("beginTime");
Path<Long> endTimePath = root.get("endTime");
Predicate predicate = cb.equal(cb.literal(1), 1);
if (null != qo.getTerm()) {
predicate = cb.and(predicate, cb.equal(termPath, qo.getTerm()));
}
if (null != qo.getBeginTimeGreaterThanEqual()) {
predicate = cb.and(predicate, cb.greaterThanOrEqualTo(beginTimePath, qo.getBeginTimeGreaterThanEqual()));
}
if (null != qo.getEndTimeLessThanEqual()) {
predicate = cb.and(predicate, cb.lessThanOrEqualTo(endTimePath, qo.getEndTimeLessThanEqual()));
}
query.orderBy(cb.asc(root.get("endTime")));
return predicate;
};
return spec;

@Maxwells8 非大神。它安装文件夹下，有一个 WPF UI 文件夹。应该就是了

@ZhiyuanLin op 没写清楚，#22 提到了要跨平台。要不然 C#是真的好。

凭良心说，Electron 确实没啥问题，是比较成熟的方案。现在随便拉一个多平台应用有很大概率是 Electron 写的，硬件相关厂商的也有不少。坑应该都有人踩，而且 js 开发好招。
上面有人说的 Tarui 其实也是用 web 技术做 ui ，但 Electron 带一个 Chromium ，Tarui 用系统自带的 webview ，安装包体积小。我没有接触过 Tarui ，但对自带的 webview 不是很放心（/t/837163 ），也可能会有一致性问题，目前还不建议。

如果是我来开发，我可能就选 Electron 。
但真的不想推荐这东西，安装包体积倒还好。主要还是卡，光点个按钮看不出来，看看冷启动速度，窗口缩放时的速度、帧率等地方还是感觉得到的。
开发者友好，用户体验不太友好。

还有一种不改文件名的方式，是加入查询参数。
比如 a.js?ppp=xxxxxxxxx

现代点的前端就是这么干的，webpack 就可以。
把需要的静态资源分割成块，每一块计算哈希值。文件变化后对应块的哈希值变了。同时帮你修改生成的 index.html 。
这样没变的块仍然可以走缓存（比如说依赖的类库啥的），变了的块就用新的。

改名字，html 不缓存。
举个例子，如果原来的 js 文件是 a.js ，新的 js 文件是 b.js 。
在 html 里原来的 link 指向 a.js ，现在就变成指向 b.js 。浏览器发现文件名不同就会再发出请求。a.js 的缓存仍然有效，但 a.js 已经不会再使用了。

软粉表示大惊小怪，微软技术力本就强的一批，但决策极其拉跨。

如果一个配置参数很常用很合理，jvm 为什么不直接弄成默认的或者自动检测？
调优肯定有意义的（要不然为啥有这个设置），但那是针对特殊场景。

正常来说，应该是算法、程序和数据库基本没什么优化的空间了再考虑这个。
刷 oj 超时，第一步不会想着换编译器吧。
而且 jvm 都调了，操作系统不调下？底层硬件不调下？