睡眠是有周期的，一个周期大概 90 分钟。只有进入深度睡眠以前，或者 REM 期间比较容易醒，进入深度睡眠以后再醒来就比较困难，而且这时候被叫醒也是昏昏沉沉的很难受。

所以要么只睡 10~20 分钟，保证在你第一个周期进入深度睡眠以前就醒来。要么就睡 90 分钟的整倍数，大概卡着 REM 期间醒来。这样都比较容易。

当然你中午少吃点碳水不睡也行。

之前用过，写得好的话性能确实不错，写的烂那还不如用 Spring 。

然后写一段时间你就发现，你真的有那么多客户，且又舍不得开机器，值得让自己写这拧巴玩意吗？
后来就改回 Spring 了，反正那么俩并发也不差几个 CPU 钱。

这东西写点简单逻辑还行，项目大，人多以后就很难控制每个人的水平，进而导致你要花大量维护 Review 培训的成本才能保证项目不烂掉。

机器成本能看得到，但人力成本很多时候比机器更大。花掉那么多人力成本就为了省那么俩 CPU 真的值得吗？

@Toby23 可以去医院测一下放个心。单从这个血氧数据来看，应该不严重的。

个人感觉 Apple Watch 这项并不准，主要是判定很宽松。但它要能测出来，结合你的状态来说，很可能没跑了。

你可以让家人在你睡着的时候关注一下，或者下个录音检测的 App ，开着放枕头边录一晚。你自己听一下就知道有没有暂停了，非常明显。

你也可以看看血氧记录，一般血氧也会低的。

减肥可以有效缓解，或者上呼吸机也行。

5100 的 LG 42C5 ，当显示器用了。

@IanHo 应该是品控问题。我第一台到手风扇就不转，或者开机转一下马上就停。售后换了一台到现在用了 3 年了，没出现过别的问题，一直很稳。

@JoshuaEstell 确实说的有问题，应该说“利息”。还有流动性失衡，以及监管支出的成本。

@gugogo 那就是你应该付的利息啊，付了就行了。

借款的利率是和时间相关的。你 100 万借 10 年和借 1 年是不一样的。提前还款相当于你用 10 年的利率借了一年。
本质上你提前还款是违反合同的，但国家按着头让银行认了这笔亏。以前银行还要收违约金，现在也不让收了。所以就在各种地方卡你，不想让你提前还。

Bitwarden 最开始创建密码库时候就会跟你说了忘了主密码谁也没办法啊。。。

> 更何况我根本没改过主密码, 不懂什么情况现在不能登陆了, 不要说扫码之类的登录新设备
要么最开始就输错了，或者你后来忘了。我之前也有过，试了十几个密码最终找回来了。

他那个主密码比较复杂，而且是用主密码加密整个密码库的。既然你能解锁，那么你的设备肯定有主密码。你可以找找看。

Windows ，或者说所有主流操作系统，进程使用的都是虚拟内存。

当一个进程申请 100G 内存的时候，并不是直接给他 100G 。而是什么都不管，直到它真正往这空间里面写入东西的时候，再去分配一块内存，然后关联到进程的虚拟地址空间里。

比如进程申请了 100G ，然后往第 0010 位置写入数据，系统会映射一块 0100 的内存，然后转换地址让它能写进去。

但这个已提交，会直接加 100G 上去。整个逻辑简单来说就是这样。

然后你这截图里面，已提交的前面那个数字，就是所有进程申请的内存总量。它可能被使用了，也可能没被用到。后面那个 82.4G ，是你实际的物理内存加上页面文件的大小。

你可以看到这里面 50G 的已提交，已经超过了你的物理内存总量。说明除了申请完没用的以外，可能已经有一部分进程关联的内存已经被换到页面文件里了。至于为什么被换出去，你可以去看看 Windows 的内存管理，有很多条件。比如长期未使用，或者有优先级更高的进程抢占等等。

但是这些进程一旦要使用这部分内存就会产生 page fault ，操作系统就要把它们从硬盘上重新读到内存里。这个过程中整个进程就会卡住等待。就是你看见的卡顿。

你想要查原因，就去看看哪些进程申请了一大堆内存，而且属于那种大部分时间没啥活动，但过一段时间抽一下风活过来一会。

当然仔细查这个比较麻烦，需要你有一定知识背景。最简单的就是随便杀掉点你自己开的后台进程，看看还卡不卡。

一年献两次，大概三四年了吧。

对我来说没啥影响，献完了该吃吃该喝喝，甚至饿半天去献血，完后继续撸铁也没啥不适的。当然最好还是建议休息。

用血免费倒是不清楚，没用过，也不是为了免费去的。当然在献血车也见过不少拿钱互助来的，这个看个人吧。

我自己献血也就是随缘做点好事，和你路上遇见条狗踩个刹车，或者网上敲赛博木鱼差不多。那点血对我来说无所谓，我也没什么不舒服的，顶多就是费点时间。能救到人最好，救不到也跟我没啥关系。血这东西是有保质期的，期间没用到那就废了。

@ambition117 你可以看看这个： https://techcommunity.microsoft.com/discussions/windowsserver/refs-volume-appears-raw-version-doesnt-match-expected-value-after-windows-update/3058652/replies/4002933

另外出问题的这些都是累积安全更新，而且也没写过说这个更新会不兼容以前版本的 ReFS 。就是简单炸掉而已。

@ambition117 在 Azure 上稳不代表在你公司也稳啊，既然只在 Azure 上稳，那就不要把这功能放到 Windows Server 里开放给大家用。

前面 OP 也说了，谁能想到你一个 Windows Update ，就能炸掉存储卷呢。而且又不是炸一次，好几年了都不改，几次版本升级都有人抱怨升完了就炸掉了。确实是有规避办法，但作为一个企业级的功能，这么搞是闹着玩呢？

更别说规避办法就是再格式化个新版本的卷，然后把数据拷过去。这不是搞笑吗？你见过哪次 Linux 升级你家硬盘没了，需要回滚版本，然后把数据拷过去，再升级系统的？

@RedBeanIce 改了 License ，前段时间又在社区版的 UI 上删除了大部分功能。步 Redis 后尘了。

@david930 都是付费的。迪卡侬做保养一样也要收钱。

你可以去迪卡侬看看有没有修车的，手艺如何。

哪个门店近就选哪个。因为不管什么车你每年都得做次保养，清洗上油换滚珠。找个方便的就行了。

N 年前 ReFS 加存储池炸过一次以后就再也不信微软那些狗屁玩意了。这玩意不炸你就当 NTFS ，炸了你修不回来的时候哭都没地方哭。

而且支持 S3 API 的存储方案很多，你不想买商用方案，不嫌折腾你自己也可以去搞 Ceph 。MinIO 就别碰了，已经开始完蛋了。

很多家用日化，像洗洁精，洗衣液等东西，只算成本的话，最贵的其实就是包装。

以国内的化工水平，里面那些东西都没有瓶子贵。

@guoguobaba 明白了。但还是建议你找个视觉模型，把你的发票直接当图片来处理。

你这个问题是，模型没法理解“相对位置”这种概念。比如你如果把单价提取成 “单价” 和 “10.0” 两个文本块，只带着坐标的话，就比较难把两个东西关联起来。

现在各种云厂商都有专门的发票识别 API ，你也可以看看他们用的什么技术，找个类似的试试。