三次握手人人会背，但能说清一条连接怎么"死"、死前为什么赖着不走，才是你和"真懂 TCP"之间的距离。
先写DB再删缓存不是规范约定，而是两种并发顺序的窗口博弈结果：先删后写留下TTL级长窗口，先写后删只留毫秒级短窗口。本文顺着时序推一遍，并给极端竞态兜底方案。
at-least-once 在消息队列里常被当 bug，到了 IM 却是唯一靠谱的默认。靠发送端 msgID 补传、服务端 store-and-forward、接收端多端去重三道防线，把'可能收到多次'变成用户无感。
用一组自造 Go benchmark 把反直觉结论坐实：Channel 做单例慢 19–280 倍、atomic 碾压 Mutex、WaitGroup 万级退化。每个结论配标准库源码根因，末尾附场景化选型清单。
goroutine 初始栈只有 2KB，但这恰恰是最大的误解。当 10 万个 goroutine 同时存在时，堆内存逼近 62MB。本文用 GMP 调度模型解释协程池为什么必要，自造 benchmark 量化'不用池的代价'，给出生产级实现和三问决策框架。
三种持久化机制的优缺点，主要根因都指向同一个底层机制 fork()+COW。理解它，就能解释 RDB 的数据丢失窗口、AOF 的重写阻塞、混合持久化的折中逻辑，也能解释为什么生产环境会炸（OOM），以及为什么你对'AOF 不丢数据'的理解是错的。
hedging 降 P99 是症状治疗不是病因治疗。基于 Go 实测：hedging 让 P99 降 51% 但服务端 mutex 等待暴增 12 倍。尾延迟治理三层框架——先治病因，再消放大，最后才用 hedging 兜底。
Redis 赢在三层：技术层被追平、组织层被挤压、元认知层被锁死。Caffeine 不是没机会，而是机会被结构性挤压到配角位置。
一行 SETBIT 吃掉 12 MB，10 个用户 300 MB。从字节级原理拆解 Bitmap 签到，讲透 hash offset 反模式、BITCOUNT 字节偏移坑、大 key 性能边界，附 Go 完整实现和 7 组实测数据。
从"怎么检测 data race"升级到"怎么设计没有 data race 的代码"——数据所有权心智模型，4 组自造代码 demo 验证。
