一杯咖啡的时间，聊聊技术与成长
单体还没撑不住？先搞清楚为什么拆微服务
一次普普通通的发版，四个团队陪跑到凌晨——改一行购物车文案，全站回归八小时。微服务解决的是组织与部署的耦合，不是性能问题；拆早了的账单叫分布式单体。什么时候真的该拆，这篇把决定时刻讲清楚。
关于技术选型：不要被"流行"绑架
最近团队在纠结用 GraphQL 还是 REST。聊了一圈发现，很多人对 GraphQL 的理解停留在"前端可以按需取字段"，而忽略了它带来的 N+1 和缓存难题。
收官复盘：一张 Elasticsearch 作战地图
20 篇走完，从 LIKE 搜不到「燕麦拿铁」到一套能扛量的搜索系统。最后一篇不添新知识：症状索引、按生命周期的阅读路径、三条心法、十条上线检查清单——出事时能直接翻的作战地图。
陷阱集：十个真实事故现场
每一条都是老王真踩过或差点踩过的坑：text 上用 term、类型自动猜测、深分页、refresh 误会、小分片风暴、fielddata 自残、双写漂移……十个现场，十个教训，一条比一条眼熟。
场景集：电商搜索、日志平台与数据看板
零件会装了，换台机器还会吗？三套可上线的配方：电商搜索重在相关性与反馈闭环，日志平台重在滚动索引与聚合，数据看板重在正排统计与定时同步——同一套 ES，三种组装思路。
查询调优：profile 与慢查询的手术台
P99 从 200ms 飙到 3 秒，凶手藏在查询里。慢查询日志先抓案发现场，profile 拆开每一步耗时，通配符查询是 ES 版的 LIKE 全表扫，rescore 先粗排后精排——五类凶手指认加改写手法一次配齐。
搜索产品化：从搜索框到搜索系统
零件全齐：分词、mapping、查询、评分、聚合、同步。组装成产品要一条流水线：预处理、召回、过滤、排序、展示五段式，加上搜索日志的反馈闭环与运营干预位——搜索系统不是查询语句，是产品。
数据同步：MySQL 到 ES 的四条路
同步双写怕失败、定时扫表嫌延迟、binlog 订阅要运维——MySQL 到 ES 的四条路各有各的价。按延迟容忍度和团队能力选型，用业务主键 upsert 保证幂等，全量加增量的组合拳才是常态。
分片规划：建索引时定死的那道数学题
随手 5 个分片，一年后被一堆小分片吃光内存；随手 1 个分片，数据涨了想拆拆不动。单分片 10 到 50GB 黄金区间、未来一年的扩容预留、rollover 滚动索引——分片数在建索引那一刻定生死。