性能优化

前缀缓存命中率不靠引擎靠排列：本机仿真 3 轮，易变字段放开头 98.0%→0.0%前缀缓存（Prefix Cache / KV 复用）的官方说法只有一句：「从 prompt 开头完全一致的部分才命中」。但工程上真正决定命中率的是你怎么排列 prompt，不是引擎。本文在本机（Windows 10 / Python 3.11.5 / 32 逻辑核）写了一套按「累积块哈希 + 连续前缀匹配」建模的仿真台，脚本可运行、结果可复现。实测：同样 12 轮 4.7 万 token 的会话，把长文档放在易变字段之前命中率 49.5%、放在之后只剩 19.2%，相对 Prefill 成本 0.554

聚簇索引 vs 二级索引：回表、覆盖索引、索引下推有一次帮同事看一条 SQL，4 秒。我只做了一件事：把 select * 换成了具体的三个列，然后加了一个联合索引。EXPLAIN 的 Extra 从 Using where 变成了 Using index，时间从 4 秒掉到 60 毫秒。

一条 SQL 从输入到返回，中间经历了什么三年前我在一家做 SaaS 的公司，手里有一张 800 万行的订单表。有天早上监控告警，后台的订单列表页从 200 毫秒涨到 4 秒。我先看了下 SQL，很普通：

Linux实战笔记

GraphQL vs REST API 设计实测：灵活查询与性能权衡逐项对比<p style="text-align:center"><img src="https://platform-outputs.agnes-ai.space/images/t2i/task_ZAk6EM0B3ldcGPqyWwMWse5VkzmGN19T/output_58d85eea7ecd40638201c4fc8145774e.png" alt="封面图" style="max-width:100%;height:auto" /></p>

开虚拟线程后接口反而更慢：JDK 21 synchronized 锁住载体线程的排查本文摘要：虚拟线程开启后接口反而变慢，JDK 21 中被争用的 synchronized 钉住载体线程。并发坍缩到 CPU 核心数，换 ReentrantLock 可恢复。

前进的李工

飞书企业知识库设计+后端高频八股作者：程序员木子｜AI Agent 关键词： AI 应用开发、企业知识库、RAG、HTTP、HTTPS、TCP、MySQL、Redis、MVCC 文章说明：本文根据面试题记录整理，重点围绕设计一个飞书企业知识库和后端基础高频问题展开。

祥Sir的SRE笔记

CPU 100% 不一定是故障：压测打满、业务饱和、突变打满的判断与排查前言"CPU 飙到 100% 怎么排查"是 SRE 面试的必考题，但十个候选人八个开口就是工具连招：top、vmstat、iostat、pidstat、perf——报得挺顺，方向全错。本文先拆掉"CPU 100% = 故障"这个隐含前提，给出三种性质的定性判断，再按 us/sy/wa/si 四分法展开每一条排查命令的实际用法，最后附一个最邪门的真实案例：sys 90%、strace/iostat/数据库视图全部干净，根因是大内存进程 fork 触发的内核页表锁竞争。

Elasticsearch 日志写入链路调优实战：ingest pipeline 补时间戳、时区偏移修复与按值类型路由（附 translog 实测）前面几篇把日志平台的检索侧讲得差不多了：查询 DSL、聚合大屏、查询延迟实测。这一篇回到写入侧——日志从解析引擎进入 Elasticsearch 的那一段路。这是最容易踩坑、也最容易被忽视的一段：检索慢还能加机器，写入链路的坑会让数据本身就是错的。

内网环境 OCR 服务搭建：私有化部署的技术实现与性能优化在企业数据安全与信创改造的大背景下，越来越多的企业开始将 OCR 能力从公有云迁移到内网私有化部署。但私有化 OCR 的技术复杂度远高于公有云调用，涉及算力适配、环境部署、服务集成、性能优化、信创适配等多个技术环节。很多团队在部署过程中都会遇到架构选型难、性能不达标、集成复杂、信创适配差等问题。本文将从技术角度解析私有化 OCR 的架构设计，对比 GPU 与 CPU 模式的技术差异，结合实际项目经验，分享企业级部署的最佳实践，并给出本地服务调用的代码示例。

万字详解 | Go 进阶（二）GC 三色标记：STW 从 10ms 压到 40μs，1 次 Full GC 让线上 P99 抖了 3 秒你好，我是利威尔xu。这是「GO保姆级万字详解」专栏的第二篇进阶向长文。上一篇《万字详解 | Go 进阶（一）GMP 调度器：10 万个 goroutine 凭什么不慌？》把"谁在执行 goroutine"讲完了，这篇解决下一个问题：goroutine 执行完产生的垃圾，Go 是怎么在不停服的前提下干掉的。两篇合起来，才是完整的运行时图景。

模块解耦实战：用 C 语言实现面向对象编程的三个层次摘要：嵌入式项目中，代码越写越乱、模块间互相纠缠、改一个驱动影响一大片——这些问题的根源往往是"用面向过程的方式写面向对象的系统"。C 语言没有 class 关键字，但完全能实现 OOP 的三大特性：封装、继承、多态。本文用一套工业项目的驱动框架，完整演示如何在 C 语言里实现面向对象编程的三个层次，以及如何用它设计可扩展、可替换、可测试的模块化系统。包含约 800 行实战代码、设计权衡分析和常见坑点。建议收藏。

GaussDB 内存相关参数及故障诊断GaussDB 的内存管理采用动态内存与静态内存相结合的方式，由参数 max_process_memory 控制数据库可用的最大内存。

金蝶云星空 BOS 插件性能优化：把 N+1 查询、事件重算和长事务干掉一、现象：单据保存从 1 秒变 15 秒一个典型的现场：销售订单标准保存 1 秒内完成，加了二开插件（自动带出物料规格、校验库存、推送 WMS）之后，保存要 15 秒，明细超过 100 行直接超时回滚。开发环境复现不了——因为测试单据只有 3 行。这类问题基本集中在四个点：循环里查库、事件挂太宽、事务里做远程调用、查询走全表。下面按"错误写法 → 改法 → 代码"讲。二、为什么开发环境测不出来做二开的人几乎都遇到过：开发库跑得飞快，上线就慢。原因有三个，且在开发环境里天然被掩盖。一是数据量。

程序员清风

大文件处理与性能优化：分块读取、类型优化与向量化当 CSV、日志或订单明细从几十 MB 增长到数 GB 时，一次性读入 DataFrame 往往会导致内存不足、运行缓慢或机器长时间无响应。本文从性能诊断开始，介绍 pandas 的分块读取、数据类型优化、向量化计算、增量聚合和结果校验，并给出一个可运行的订单 CSV 处理案例，帮助将“小数据能跑”的分析脚本升级为可控、可验证的大文件处理流程。

流式回复结尾的那一下闪：逐帧定位 Compose 聊天列表的三处布局跳动给 chatbase-kmp（一个 KMP 聊天 UI 库）接入 LaTeX 公式渲染后，跑基准测试时发现：AI 回复流式输出到快结束的时候，整条消息会上下闪一下。原速下只看得到「抖了一下」，左边是修复前，右边是修复后：

模板下载性能优化记录场景：GET /xxxx/downloadTemplate接口下载模版文件耗时长结论速览：端到端 ~6.5s → 目标 ~1.5-2s（模板渲染优化 7s 稳态 → 2.3-2.8s 离线实测 + DB优化 1s → ~0.15s）；

你的日志可能吃掉了 40% 的一个 CPU 核一个 10 万 QPS 的服务，每个请求打 5 条日志。实测这 50 万条/秒的日志要花多少 CPU：

AI原生前端开发（018）：端侧AI性能优化：模型加载、推理加速端侧AI性能很重要！这一篇学习如何让端侧AI更快！这一篇我们学习了：下一篇，我们学习端侧AI安全与隐私！

打工仔折腾 AI

Linux 网络编程：从零掌握 TCP Socket 编程与 C++ 实战落地现在很多业务服务都跑在 Redis、gRPC 或者各种高级 SDK 之上，日常开发确实很少直接调 socket()。但一旦遇到连接泄漏、内核参数调优、自定义二进制协议或者排查跨语言互连时的异常断开，高级抽象反而会遮住底层细节。TCP 作为最基础的传输层协议，其行为并不总是如文档所写的“可靠”那样直观。理解原生 Socket 的调用链、返回值语义以及操作系统的调度逻辑，能把很多“玄学”问题变成可定位的状态机。

打工仔折腾 AI

深入验证 DeepSeek 新模型开源声明：KV 缓存指标与按次计费的后端落地评估看到这类带具体版本号和技术指标的开源公告，工程师的第一反应不应该是兴奋，而是拆解。技术指标写得再漂亮，落到 GPU 内存、网络延迟、调用链路的损耗上，往往会有完全不同的体感。这篇文章不重复宣传语，只讲三件事：这个“KV 缓存 890B/Token”在推理引擎里到底意味着什么；“检索 API 按次计费”会怎样改变我们写后端路由和重试逻辑的方式；以及拿到模型后，如何用最小可行代码完成真实性能摸底。