引用知乎的：
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 都调了，操作系统不调下？底层硬件不调下？

@Davic1 我推荐京东上买个 type-c 转 dp 线 是因为 ①Thunderbolt 本身就是 pcie 和 dp 的融合 ②比起转接器，一根线能出问题的环节更少
不过大部分人都是笔记本 type-c 输出，显示器 dp 输入。你这种显卡 dp 输出，显示器 type-c 输入的比较少见，不知道会不会有问题。

我个人试过 ps 、xbox 和 steam 的远程游玩，只能说还是不怎么样的，非必要不建议使用。
要知道 dp 1.2 的传输带宽就有 21.6Gbps ，就算万兆网线直连也达不到这个带宽。压缩技术再好，色彩画质帧率也很受限。
如果有一端是 wifi ，就更差了。卡顿和延迟问题。另外还有外设问题，比如鼠标侧键。

还行，关键词：React 闭包陷阱

以我浅薄的知识：

买个 dp 转 type-c 的线先试试看。

你提到了主板，感觉怪怪的。要插也是插独显上吧。

@Manrod 某宝拜耳旗舰店，价格倒不记得了

我觉得这问题问得挺正常的啊，本来就是需要通力解决的问题。
假设服务器总共就 100M 带宽，200 个人一起访问好了，每个人只能分到 0.5Mbps ，别说图片了，网页加载都能长的一批。领导让前端优化加载时间，咋办？服务器不归前端管啊。

语言那么多，人的精力是有限的。深度优于广度。
我主 java ，第二 js 。不考虑深入学习其它的了。

建议加入鬼杀队

群晖的硬件确实拉胯。但整体是值这个价的。
不愿意为软件付费的，自然会觉得贵