故障排查

我的台式机习惯常年保持开机状态。通常，我会在出门或晚上不使用时仅关闭显示器。

主机莫名奇妙蓝屏无法启动，UEFI格式的引导，系统一直无法正常加载，切换到老的MBR格式的引导后，系统可以正常启动了。

常规操作，开启系统的远程桌面，另外一台机器测试，网络什么的都是正常。登录和以前一样，用了微软的账户登录系统。

远程桌面登录的时候，报错：登录失败，没有其他的任何信息。

C++ Linux 服务发生崩溃。服务依赖于某个静态库进行编译。

静态库执行了修改，头文件增加了成员变量，重新发布了静态的二进制库文件

服务依赖新的二进制库文件，能正常编译，运行就会崩溃，崩溃的地方明显没问题，有点类似上次编译器升级的崩溃，未定义行为，崩溃的堆栈不可信。 更新服务编译时依赖的头文件，能正常变异，运行也都正常

详细解释这是为什么，涉及到什么计算机的知识，我猜测和内存布局相关，举例进行详细说明。

本地有一个 Git 仓库，其中的子模块在拉取时处于一个临时分支。我在该临时分支上提交了一些代码，随后将子模块切换回了 main 分支。然而，这些提交的代码似乎丢失了，无法在 main 分支中找到。我也找不到那个临时分支的记录。

美股有三个交易时段，分别是：盘前、盘中、盘后；接口推送数据还是数值增量的逻辑（尽可能的节约带宽），仅在第一次发送全量，第二次开始所有字段都是增量推送逻辑。

为什么不用最优方案？牵扯到不同项目组，有些都已经上线多年。我方属于新对接，所以只能尽量兼容。

业务模型：后台服务借助 TCP 与集团的行情网关建立连接。每次连接时，需先行发送一个授权请求，随后持续发送心跳包以维持连接状态。 然而，某一天，收到了服务断开连接的告警信息。通过仔细排查日志后发现，后台服务一直在持续发送心跳包，但对方却毫无回应，可连接却始终未断开。

国内服务器部署docker，部署以后，如果公司没有提供镜像中心，开发首先要做的就是配置一个国内的镜像加速地址。巧了今天有台服务器，配置了镜像加速地址，但是发现拉取镜像的时候，一直拉取不到。

报错信息：Error response from daemon: Get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

20250106 时隔两天，所有的服务器都恢复了，这事居然不上热搜，国内所有的镜像代理都挂了

one loop thread，耗时已经在微秒层面，更换服务器，从最多积压六万数据包，到几乎没有积压

在单线程循环处理数据的场景中，CPU的性能取决于主频、缓存大小、指令集架构等因素。一般来说，主频越高、缓存越大、指令集架构越先进的CPU在单线程处理数据时性能越好