https://www.hipparchus.org/

Hipparchus: a mathematics Library
Hipparchus is a library of lightweight, self-contained mathematics and statistics components addressing the most common problems not available in the Java programming language.

我选 webpack + swc 。swc 的插件个人感觉还是略复杂，不如 webpack 的开箱即用。合起来用慢就慢点吧……

自从开始用 ventoy 后，就再也没灌过 U 盘了，直接通过 ventoy 引导 PE/Linuex 的 ISO 了事。

看上去不错，关注了……
但我服役 N 年的 D2550 工控机目前就已经是性能过剩状态（除了功耗略高），感觉还能再战 5 年 :doge

基本可以参考冗余校验的机制（也叫纠删码什么的），比如 ZFS 的 raidz 或者 snapraid ，这俩都提供了 scrub 命令用来验证磁盘上数据是否损坏。

当然这个也不是万能的，如果损坏的数据操过了冗余数据的比例，该丢的还得丢。

可以用 Content-Type 区分。POST application/json 为创建，POST application/x-www-form-urlencoded 为查询

如果是要在 单页面多次请求异步渲染 与 单页面聚合请求一次渲染 间比较性能优劣，我觉得还是要看具体业务场景。在服务端调用多个低响应时间的接口还是有一定性能优势的。

个人觉得 remix loader 的效果，比较接近于使用 api gateway 或者 graphql ，但写起来更加清晰一些。

也曾遇到了类似的问题，解决方案和上面某些楼层差不多，自己造了一个书签管理服务的轮子。且贴出来吧：

https://github.com/zongwei007/firefly

参考了 https://github.com/pawelmalak/flame 和 https://github.com/soulteary/flare

估计与 ext4 的 inode 有关。如果对这类占用比较敏感，可以使用 mkfs.ext4 -T largefile 重新格式化看看。

apcupsd 值支持 apc 的 UPS ，山特的要用 nut ，自带的那套 ViewPower 什么的太垃圾。

还可以试试 EntityGraph 这个注解

个人在用 MySQL8 和 PG 上存 JSON 有小规模生产实践，和 SAAS 这类场景相比算是玩具水平吧。就个人实践来说，存 JSON 字段这种用法还是在 PG 上稍微舒服一些。

主要在 PG 对数据字段长度的限制很宽松，可以直接在各种大长度字段建立索引，没做多少参数调整跑起来也没遇到什么问题。相对的 MySQL 在 JSON 字段上建立索引需要先建立虚拟列，还存在索引长度限制；最近生产环境还出现了 sort_buffer_size 不足的问题（临时增大了配置解决，疑似 MySQL 的 BUG ，https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-28.html ）。

minio 的存储实际上是通过 NFS 挂的 TrueNAS 空间？

曾经在生产环境上这么干过，用的集群部署，存储大量小文件。文件数量上来后性能很差，平均响应时间 6~8s 。后来直接上了全固态后响应时间变毫秒级了。

不过，不排除是服务器当时网络不行，当时只连了一个千兆线。

@cmxz 既如此，那我就不急着测试了😏

目前的感想：叫大家出来，就为了这点事.jpg

用楼上的示例，Java11 下无法复现。反序列化到 `class.module.classLoader.resources` 这里就是空值了。

没怎么看懂你的问题。

就你的例子来说，onSuccess 触发 ids 的 mutate 是没必要的。如果是以 useSwr(ids ? ['/api/foo', ids]: null) 形式的依赖调用，在 ids 有变化后这一调用也会被自动触发，不需要手工执行 mutate 。你现在的写法也不能说肯定有问题，但是不是官方建议的写法。

如果 ids 不变也需要触发 item 的更新……还不如直接 ids.concat([]) 触发 ids 变更算了。

个人感觉 swr 官网之所以简单，是因为 swr API 从概念上说就是这么简单 :doge ，至少个人觉得比 useRequest 反倒要清晰点（虽然从功能上不完全对等）。swr 的核心理念就是数据的无感知刷新加载，在 swr 看来，甚至 loading 状态都可以不需要强调。

回到你的问题：

1. isValidating 这个属性我个人的理解和你差不多。不过在实际中我从未用到这个属性……
2. 是这样。官方的推荐做法是 ['/api/xx', ids] 的形式，参考传入参数的章节。
3. 参考官方条件数据请求的章节。这种场景属于依赖请求的概念。

别的库，react-query 暂未实践过，之前用过 useRequest （非最新版本）。

useRequest 可能是为了保证项目中 API 的统一封装，引入了手动请求之类的 API ，反而把相关组件的生命周期搞复杂了不少。写起来感觉尚可但功能不稳定，之前遇到的问题就是不能按 key 实现全局的数据缓存。

分片传输，然后分片比对哈希，最后再对所有分片的哈希做一个总体哈希验算。具体可以参考：

https://docs.aws.amazon.com/zh_cn/amazonglacier/latest/dev/checksum-calculations.html

https://zh.wikipedia.org/wiki/%E5%93%88%E5%B8%8C%E6%A0%91

小公司，一直用的 gitea + drone 的组合。

gitea 除了在组织管理方面不大满意（比如没有组织级别的工单，当然这个 github 也没有），其它没有什么不满的地方。
drone 运维功能比较残缺，出问题只能想办法各种查日志外，算是能用；基于容器的插件可以说是相当灵活了，有什么不足也可以自己撸一个也不算困难。