git reset --hard 后,丢的提交怎么捞回来
reset --hard 敲错分支、stash 手滑 drop、rebase 结果不对——这些场景下数据大多还在 .git/objects 里。本文用可复现的实验讲清 reflog 的用法和失效条件、fsck 捞 dangling commit 和 blob 的具体命令,以及哪些丢失其实救不回来。
Blog
格达软件工程师的实战经验、技术选型与行业观察
reset --hard 敲错分支、stash 手滑 drop、rebase 结果不对——这些场景下数据大多还在 .git/objects 里。本文用可复现的实验讲清 reflog 的用法和失效条件、fsck 捞 dangling commit 和 blob 的具体命令,以及哪些丢失其实救不回来。
从一段 N+1 的导出脚本讲起,用 200 行实现一个能跑的迷你 ORM,把描述符映射、identity map、flush 时机这几个 SQLAlchemy 核心机制拆开看,再给出它的失效边界:批量插入、懒加载、长 session 的坑。
把聚合 200 笔下游状态的页面从串行 40 秒改到 0.9 秒:讲清协程与事件循环的调度机制,以及三个不报错、只变慢的坑——协程里混入阻塞调用、并发不设上限、任务引用丢失与取消被吞。
5000 行订单列表,搜索框每敲一个字符卡 250ms。这篇文章拆解卡顿的真实来源(不是 computed 没缓存,是 patch 了 4 万个 DOM 节点),给出虚拟滚动、shallowRef、v-memo、key 选择的可用代码,以及每种优化不该用的场景。
一个 Go 服务用最朴素的 Dockerfile 构建出来 1.11GB,改一行代码要等 47 秒。这篇拆开每一层看体积从哪来,用多阶段加 BuildKit 缓存把它降到 12.4MB、热构建 3 秒,并列出走到 distroless 和 scratch 之后必然会踩的坑:动态链接、CA 证书、时区、没有 shell。
一个 3000 行不分页的订单表格,切路由白屏 1.8 秒、改筛选卡 400 毫秒。按测量结果逐项排查:内联箭头函数、模板内计算、reactive 深代理、v-memo 的漏依赖坑,最后用虚拟滚动把首屏压到 190ms。
两个事务在 RR 隔离级别下先查后插,计数没超却多发了券;更怪的是 UPDATE 影响行数为 1,同一事务里 SELECT 却查不到这行。这篇文章用可复现的 SQL 会话讲清快照读与当前读的差异、间隙锁的边界,以及唯一索引和原子更新怎么兜底。
订单表到了八千万行就必须拆?先看一条慢 SQL 再决定。这篇讲清分片键怎么选、基因法让订单号自带路由、跨分片分页与 count 的正确写法,以及事务、扩容、运维要付的真实代价。
200 万行的订单表上,同一句按商户查订单的 SQL,只因为联合索引里列的顺序不同,扫描的数据页差了 40 倍。这篇用可复现的建表脚本和 EXPLAIN 输出,讲清楚等值、范围、排序列在 B-tree 里各自能做什么,以及哪些写法会让索引直接白建。