背景 中秋前的周五晚上，订单服务开始出现间歇性超时，监控上 RT 从 80ms 涨到 1.2s，同时观察到 Full GC 频率从每天两次变成每十分钟一次。这篇文章记录完整的排查过程。 第一步：先看 GC 日志 jstat -gcutil $(pgrep -f order-service) 1000
索引失效是慢查询里最常见的原因之一。下面几个场景是我在真实项目里反复遇到的。 1. 隐式类型转换 -- phone 是 varchar，这里会全表扫描 SELECT * FROM users WHERE phone = 13800138000; -- 正确写法 SELECT * FROM users
一台 2C4G 的小机器，我跑着博客、图床和几个小工具。用了一年 Compose，总结几条经验。 目录约定 /opt/services/ blog/ docker-compose.yml data/ minio/ docker-compose.yml data
第一次启动 Vite 项目时，控制台里那行 Pre-bundling dependencies 到底在做什么？这篇是我读完源码后的整理。 为什么需要预构建 浏览器原生 ESM 不支持 CommonJS，而 node_modules 里大量包还是 CJS。另外像 lodash-es 这样的包有几百个模
工作第八年，参与过十几次技术选型。踩过 "为了新而新" 的坑，也见过保守到错过窗口期的团队。分享一下现在自己用的判断框架。 一、先问为什么 如果现有方案能解决问题，只是"不够优雅"，那多半不该换。选型的动机应该是能力缺口，不是审美。 二、把成本算全 学习成本：团队多久能上手并排障 运维成本：多一个组
《Designing Data-Intensive Applications》读了第二遍，这次记录第五章和第六章的要点。 复制：单主、多主、无主 单主复制最简单，写全部走主节点，问题在于主节点故障后的切换。多主适合多区域写入，代价是冲突处理。无主复制（Dynamo 风格）用 quorum 读写，听起
Nginx 配置写得越久越容易变成一锅粥。这几年我形成了几个固定习惯，分享给同样维护多站点的人。 一个站点一个文件 conf.d/ blog.conf api.conf static.conf 不要全塞进 nginx.conf。改一个站点的配置不应该牵扯到其他站点。 公共部分抽 ups
