联合索引下 ORDER BY 与 WHERE 列顺序冲突时的排序失效判定
面试里经常出现这样一道题：表上建了联合索引 (a, b, c)，SQL 写成 WHERE b = 1 ORDER BY a，问能不能用上索引排序。很多人背过结论——「最左前缀原则」——但一旦列顺序和 WHERE 条件顺序不一致、或者 WHERE 里出现范围查询、或者 ORDER BY 的列顺序与索引顺序颠倒，就开始含糊。这篇文章把「排序失效」这件事拆到可判定
fwddbot
dataclass 中 init=False 与 default_factory 组合构造派生字段
在 Python 的日常开发里，@dataclass 几乎是定义数据载体的默认选择。但很多人只用到「声明字段、自动生成 __init__」这一步，一旦遇到「字段需要由其他字段计算得来」的场景，就退回去手写 __init__，把 dataclass 带来的简洁性丢掉了。更常见的情况是：给派生字段写了一个 field(init=False)，然后直接赋值 fie
用 singleflight 合并并发重复查询以削峰的下游保护写法
缓存击穿是后端服务里最常见的一类雪崩源头：某个热点 key 刚过期，或者某个冷门 ID 突然被大量请求命中，缓存层没有数据，于是几百上千个 goroutine 同时打到 MySQL、Redis 从库或者某个内部 RPC 接口上。数据库连接池瞬间被占满，接口 P99 从 20ms 飙到 3s，上游开始超时重试，流量进一步放大，最终把下游彻底压垮。本文要解决的正
用 getopts 解析带短选项与位置参数混排的备份脚本参数模板
写运维备份脚本的人大多踩过同一个坑：参数一多，$1、$2、$# 手工 case 判断就开始失控。./backup.sh -s /data -d /backup -k 7 /etc/nginx 里既有选项又有位置参数，一旦用户把 -k 7 写到源目录后面，脚本要么把 -k 当成目录名，要么把 7 当成了第二个源路径，备份跑完才发现备错了东西。更糟的是它在 -k
幂等 Promise.all 与 allSettled 在批量请求失败聚合上的判定差异
批量发起接口请求几乎是每个前端都会遇到的场景：页面初始化时要同时拉用户信息、权限列表、字典数据和消息未读数，导出报表时要按分片并发下载。多数人第一反应是 Promise.all，因为它写得最短。但真正上线后才会发现，Promise.all 的语义是「全有或全无」——任意一个请求 reject，整个结果就变成 reject，那些已经成功返回的数据被直接丢弃，页
impl Trait 返回位置与 dyn Trait 装箱在 trait 对象分发上的取舍
写 Rust 的人几乎都会卡在同一个岔路口：trait 有了，实现也有好几个，接下来是把函数签名写成 -> impl Trait，还是写成 -> Box<dyn Trait>？两者在调用方看起来差不多，都能"返回一个实现了该 trait 的东西"，但它们在类型系统层面走的是两条完全不同的路：前者是编译期单体化（monomorphiza
TypeScript 5.0 中用 satisfies 校验配置对象并保留字面量推断
项目里几乎都有一个 config.ts，里面导出各种配置对象：路由表、主题变量、构建参数、feature flag。这类对象的诉求很特别——既要求结构被编译器严格校验，又要求字段值保留字面量类型。用类型注解写，校验有了，字面量类型却被拓宽成 string / number；用 as const 写，字面量保住了，却完全没有结构约束。TypeScript 5.
Spring @Async 代理失效与方法内部自调用的判定方法
使用 @Async 把耗时任务丢到线程池执行，是 Spring 项目里最常见的异步改造手段。但很多人第一次接入时会遇到一个诡异现象：方法明明加了 @Async，日志里的线程名却还是 http-nio-8080-exec-1，接口照样被阻塞，异步等于没加。更麻烦的是，这个问题在单元测试里往往测不出来，上线压测时才暴露。 根本原因几乎都指向同一件事：@Async
用 psutil 采集进程 RSS 并生成趋势 CSV 的脚本
线上排障时最常被问的一句话是「这个服务的内存是什么时候涨上去的」。监控平台往往只保留 7～15 天的高精度曲线，而内存泄漏的斜率可能一个月才看得出来；容器重启后历史数据又断了一截。psutil 是 Python 里直接读 /proc 的轻量库，几十行代码就能在自己的机器上落一份「按分钟采样、按天归档」的 RSS 趋势文件，不受监控系统保留策略限制。下面这份脚