还可能有时间因素，比如 2 个月的工作量要求必须 1 个月出货，其中还有 15 天在拉扯需求到底要什么。

纯粹说明一下个人对 @labdum 引用的那个文章的看法。

那个文章的作者大概不是对他列举的每一门语言都足够了解。我对其它语言了解不多，但是一如那个文章回帖里说的，C#的写法不太行，而且都 .NET 6.0 的测试环境了，创建如此大量 Task ，要不要考虑下 ValueTask 的可行性。我相信列举的其它语言的写法也有类似问题，所以那篇文章的参考价值是：一个某某语言的初级程序员在不充分了解语言特性和机制的情况下写出的未优化的代码的内存开销有多遭。

@oamu 抱歉，不会直接贴图，请问这个主板怎么怎么插两条 8G ，两条 16G ？

https://i3.mjj.rip/2024/06/17/c601dbfcec2176dca607b98bb9060270.jpeg

https://i3.mjj.rip/2024/06/17/c601dbfcec2176dca607b98bb9060270.jpeg

Test

Test

Test 

Test [img]https://i3.mjj.rip/2024/06/17/0b8355203d07d71007b1381da8014219.png[/img]

8+8+16+16 如果频率一致没问题，如果发现降频，主板设置成内存的标准频率就行。另外是插 13 、24 还是 12 、34 **一定**查看主板上内存插槽的说明，有些主板就是 12 配对、34 配对，这种情况下默认按照 13,24 插就成了两对 8 + 16 的配对，会出现不稳定问题。

我觉得这个逻辑有点问题：既然有赛博洁癖，理论上就不会在电脑里乱装软件，只会安装那些质量够高、必须安装的软件，这样电脑也不会乱，进而不会有重装系统的必要。就像喜欢整洁的房间应该一开始就不会乱丢东西，丢了一大堆了就看着不顺眼想换个房间。所以解决的办法就是别在电脑里乱装软件，另外备个虚拟机可以随便装，也方便还原什么的。

不需要和其他程序员交流并且其他程序员也不会找你的程序员。

让我想起很久之前看过的一个英语视频，说是现在不管什么事儿动不动就 Awesome ，即过度夸张了含义又忽略了很多其它更合适的词汇。确实现在就是这么个浮夸的时代。

也可能是电源质量问题，虽然瓦数够，但纯电源个体质量问题？

能户外尽量户外。如果说游戏，建议《我的世界》

小时候父母支持我买了人生第一台电脑，后来和来自中部省份的同事说起当时那台电脑的配置和价格，同事说就那些钱，当时够在他们那里买套房了。——没想到父母对我的支持这么大！
小时候看到路上一辆别克小车觉得特别漂亮，而家里也有十几辆 MatchBox 的模型小车，特别喜欢车，现在也已经换到第 5 辆车了，确实已经没有那买十几辆车的财力了。。。

当然，如果需求变更，下单时间查询原来只是某天到某天，现在改为某天某时到某天某日，上述做法导致前后端都需要修改，所以如果想避免/预判需求更改导致的代码更改，那么前端依然按照需求要求带时分秒或不带时分秒，而后端则根据传入的参数是否带有时分秒数据而分别进行查询。

我觉得这个问题不能一刀切，需要根据是否需要“时间”这个概念来确定如何保存和查询。

对于数据存储来说，例如，对于“下单时间”这个概念，显然时分秒是必要的，而对于生日这个概念，（通常）时分秒是没有意义的，所以前者需要存储时分秒数据，后者只需要存储年月日数据而时分秒都是 0 或者存储系统支持纯年月日类型的话更好。

对于查询，如果是上述下单日期，同样基于业务要求来决定是否需要传入和处理时分秒数据。比如业务有需求要查询某日几点几分到几点几分的数据，则接口参数需要包含时分秒而查询就是基于大于等于并且小于等于的范围。而如果只是需求查询几号到几号的数据，则接口参数不需要包含时分秒或者时分秒为 0 而执行时基于大于等于 BeginDate 并且小于 QueryEndDate + 1 day 的范围。如果是上述生日数据，因为本身存储不带时分秒，所以接口参数也不带时分秒或时分秒为 0 而查询基于大于等于并且小于等于的逻辑。

一来人各有志，二来宏观来看每个方向都有试图努力理解和推进的人才会扩大人类进步的可能性，无论这种进步是哪个方向的。

多年以前有天翼云的免费试用服务器，后来打算取消这个服务器然后发现无法在线无人工干预取消，必须联系电信经理然后她再联系天翼云的人员取消，前前后后折腾了好久，这要是临近到期的时候，搞不好都给我整欠费了……