同样一件事，可以写成三种颗粒度：
A：熟悉 Redis B：使用 Redis 做缓存，缓解数据库压力 C：用 Redis 做热点商品缓存，采用 Cache Aside + 逻辑过期解决缓存击穿， 大促期间命中率 97%，DB QPS 从 8000 降至 300多数人写在 A 和 B 之间，真正有效的是 C。但也不是所有内容都值得写到 C。
三档颗粒度分别用在哪
A 档（只列名词）：放在技能栏里，用于关键词匹配。别的地方不要用。
B 档（做了什么用途）：用于次要经历、或者你只是使用者而没有深入的技术点。
C 档（方案 + 参数 + 结果）：用于你最想被问到的两三个点。
一份简历上 C 档内容有两到三条就够。全篇都是 C 档，篇幅撑不住，也会让重点消失。
怎么决定哪几条写成 C 档
选那些你能连续讲十分钟、并且和目标岗位相关的。
面试官的注意力会被 C 档吸走，这正是你想要的，把面试引导到你准备最充分的地方去。
颗粒度不够的三个典型
第一，只写中间件名字不写用法。「熟悉 Kafka、RabbitMQ、RocketMQ」，三个都写等于三个都没写。挑一个写清楚用它解决了什么问题、怎么保证不丢消息、遇到过什么坑。
第二，写了用法不写规模。「使用 Elasticsearch 做搜索」，索引多大？数据量多少？QPS 多少？规模决定了这件事的难度，不写规模，对方只能按最小规模理解。
第三，写了云服务厂商不写具体形态。「熟悉云原生」「使用过云服务」这类表述没有信息量。写具体：用的是托管的 K8s 还是自建、对象存储怎么用的、有没有做过成本优化。
同一份简历里颗粒度要有节奏
全篇 A 档，像技能清单；全篇 C 档，读起来累，而且篇幅撑不住。
一个可用的节奏是：最近一段经历里放两条 C 档、三到四条 B 档；上一段经历全部 B 档；更早的经历 A 档带过，甚至只留公司职位和时间。
这个节奏本身也在传递信息：对方能看出你最近在做的事和早期的差别，也能看出你自己知道什么重要。
C 档内容要留追问空间
写 C 档时不要把所有细节都塞进简历。留一到两处「钩子」，比如写了「采用 Cache Aside + 逻辑过期解决缓存击穿」，但不写为什么不用互斥锁。
面试官大概率会问这一句，而你已经准备好了。把面试引到你准备最充分的地方，这是简历能做到的最有价值的事之一。
颗粒度过细也是问题
把配置参数、版本号、类名全写上，会让简历变成技术文档。
判断标准：这个细节能不能说明你的判断力。「JVM 参数调整为 -Xmx4g」说明不了什么，「通过 GC 日志发现老年代增长异常，定位到一处静态集合未清理」就能。
一个自检方法
把你简历上的技术名词全部圈出来，逐个问：
这个词在这里出现，是在证明什么？如果答案是「证明我用过」，而岗位描述里又没有这个词，那它就可以删掉。
删掉的空间留给那两三条 C 档内容。
云服务相关的写法补充
云上的经历很容易写成「使用了某某云的某某产品」，这是 A 档。往上提一档的写法是写清楚你的决策和收益：
将日志方案从自建 ELK 迁移到云托管服务： 自建集群每月运维投入约 2 人日，且扩容需要停机； 迁移后运维投入降为 0.3 人日，成本上升约 15%， 团队一致认为这个交换是划算的。这段里最值钱的是最后一句，你算过账，并且做了权衡。成本意识在中高级岗位上是明确的加分项，而绝大多数简历里完全看不到这一项。
最后
颗粒度的本质是取舍：你决定让对方看清哪几件事。全都想说清楚，等于什么都没说清楚。
