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

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

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

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

紧接上文，今天继续聊聊局域网的 IP 地址。上次为了同步代码，服务器配置了代理，服务器和家里的台式机打通了网络，在一个局域网里面，代理程序部署在台式机上，服务器通过代理访问外网。同步代码很慢，扔那边就没管了，隔了半个月，到服务器验证代码，发现Git代码同步失败，网络错误，也没太过脑子，细看报错信息。

国内访问 GitHub 速度较慢，可以通过配置代理来加速访问。还有个方式，找个国内的托管平台，比如码云、Coding 等。配置对应的构建流水线，将代码同步到 GitHub。

用了很多年的coding，界面简洁，近期发布公告，免费版不能继续用了，需要迁移到腾讯的新平台cnb，顺带吐槽下，阿里的托管平台，整个界面设计，班味很重。

https://cnb.cool/ttf248

业务系统设计了 Summary 类型的监控指标，计算平均耗时：request_duration_milliseconds_sum / request_duration_milliseconds_count。

查看数据，发现某个接口平均耗时很高，翻看时序图，平均耗时是突然增加的，等于就是某次请求耗时很高，拉高了平均值，想查具体是什么时候发生的请求，由于时段内的请求太少，查出来的数据一直空。

文化传播：意识形态上的影响，潜移默化。 AI编程：不做软件设计，返工很多

博客翻译项目最初设计过于复杂——先解析 Markdown 格式，再用占位符保护内容，最后送给大模型翻译。其实这完全是多此一举，大模型本身就具备识别 Markdown 语法的能力，可以直接处理原始内容并在翻译时保持格式完整。

我们的工作就从调试代码，切换到调试大模型的提示词。

模型：google/gemma-3-4b 硬件：Nvdia 3060 12GB

没错，选的非思考模型，思考模型在执行翻译任务时，效率不够高，对比了 4b 参数和 12b 参数的效果，针对翻译任务来说 gemma3 的 4b 参数已经足够了，12b 的参数在翻译任务上并没有明显的优势。

12b 参数的速度：11.32 tok/sec，4b 参数的速度：75.21 tok/sec。

在 Go 语言项目中，使用 staticcheck 查找未引用的函数是一种高效的静态分析方法。