一个后端服务上线前的检查清单
把容易遗漏的可靠性问题变成发布前的明确检查项，降低新服务上线的不确定性。
阅读全文 →BACKEND ENGINEERING · NOTES
在系统的复杂处，
寻找简单答案。
记录后端开发、分布式系统与工程实践。写下真正解决过的问题，也整理那些值得反复理解的基础知识。
最新文章
20 篇记录后端测试如何分配投入
测试数量不是目标，应根据失败成本和反馈速度，把覆盖放在最有价值的边界上。
阅读全文 →配置管理的边界与原则
配置用于表达环境差异，但不应成为绕过代码评审、版本控制和安全管理的后门。
阅读全文 →零停机发布依赖哪些前提
滚动发布只是最后一步，真正难点是应用版本、接口和数据库结构在过渡期内兼容。
阅读全文 →使用分布式锁前先回答五个问题
分布式锁隐藏着租约、暂停和所有权问题，使用前必须明确失败时的业务后果。
阅读全文 →排查慢查询的完整路径
从真实慢查询样本出发，结合执行计划、数据分布和系统资源定位瓶颈。
阅读全文 →代码评审应该优先看什么
评审的核心是发现行为风险和知识缺口，而不是把个人风格包装成统一标准。
阅读全文 →设计稳定的 API 错误响应
一个好错误响应应同时服务于程序判断、用户理解和工程排障，并保持长期兼容。
阅读全文 →构建更小更可靠的容器镜像
小镜像的价值不仅是下载更快，也包括更少依赖、更清晰的构建过程和更小攻击面。
阅读全文 →Linux 内存指标应该怎样看
free 很少不等于内存不足，判断压力要结合 available、缓存回收和换页行为。
阅读全文 →限流不是一个固定的 QPS 数字
有效限流需要选对维度、算法和降级响应，并随系统实际容量持续校准。
阅读全文 →数据库事务边界应该放在哪里
好的事务边界围绕一个业务不变量展开，既避免部分成功，也避免把慢网络调用包进事务。
阅读全文 →服务优雅停机的正确顺序
优雅停机的目标是在发布和缩容时停止接收新流量，并给在途请求明确的完成机会。
阅读全文 →可观测性从一次请求的故事开始
日志、指标和链路追踪不是三套孤立工具，它们共同解释一次请求发生了什么。
阅读全文 →消息队列的至少一次投递意味着什么
至少一次投递把消息丢失风险降下来，同时要求消费者能正确处理重复消息。
阅读全文 →用 Go Context 管好请求生命周期
Context 的核心价值是传递取消和截止时间，让请求结束后不再留下无意义的工作。
阅读全文 →Java 线程池参数不应凭经验填写
线程池容量取决于任务等待比例、下游容量和过载策略，而不是一个固定公式。
阅读全文 →Redis 缓存一致性的工程取舍
缓存更新没有万能公式，关键是明确一致性窗口、失败路径和热点数据的代价。
阅读全文 →MySQL 联合索引的设计与验证
从查询模式出发安排联合索引字段，并通过执行计划和真实数据分布验证效果。
阅读全文 →接口幂等：从重复请求到业务语义
幂等不是简单地拦住重复请求，而是保证相同业务意图只产生一次可观察结果。
阅读全文 →