先让 curl 自己招供#

不要只看 time_total。用下面这个格式串，把一次请求拆成五个阶段：

curl -o /dev/null -sS \
  -w 'dns=%{time_namelookup}s tcp=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
  https://example.com/health

各字段的含义和常见嫌疑：

如果 dns 就花了 5 秒，后面的 TCP 和 TLS 再快也没意义。反过来，dns 只有 2ms、tcp 却要 3 秒，问题基本就在网络可达性上。

分层验证，不要一上来就抓包#

1. DNS：先区分缓存与递归#

dig +stats example.com A
dig @223.5.5.5 example.com A
getent hosts example.com

• dig 默认直接问配置里的 DNS，绕过部分系统缓存；
• getent hosts 走的是 glibc 的 NSS 链路，更接近程序真实行为；
• 如果 dig 很快、getent 很慢，检查 /etc/nsswitch.conf 里是否有 mdns、resolve 之类的顺序问题。

2. TCP：看握手有没有完成#

curl -v --connect-timeout 5 https://example.com/ 2>&1 | sed -n '1,20p'
ss -tanp | grep -E 'SYN-SENT|ESTAB'

一直停在 Trying 1.2.3.4...，说明 SYN 没有回包。常见原因：安全组没放行、目标端口没监听、运营商丢包、MTU 黑洞。用 mtr -rwzbc 20 example.com 能看到丢包发生在哪一跳。

3. TLS：握手卡住还是证书报错#

openssl s_client -connect example.com:443 -servername example.com -brief </dev/null

如果 TCP 很快、TLS 很慢，重点看证书链是否过大、是否在拉取 OCSP、服务端是否强制了老旧套件。把 time_appconnect 与 time_connect 相减，就是 TLS 的真实开销。

一个容易被忽略的元凶：连接没有复用#

单次请求很快，并不代表批量请求也快。每次新建 TCP + TLS，在跨地域链路上可能要付出 3 到 5 个 RTT。用 curl 连续请求同一个域名时，可以显式复用连接：

curl -sS -o /dev/null \
  -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
  https://example.com/a \
  https://example.com/b \
  https://example.com/c

后两次的 time_connect 和 time_appconnect 应该接近 0。如果仍然很大，检查客户端是否每次都在重建连接池，或者中间代理是否强制关闭了 keep-alive。

把排查固化成脚本#

临时命令用完就忘，不如把常用指标写进一个脚本，出问题时直接跑：

#!/usr/bin/env bash
set -euo pipefail
host="${1:?usage: probe.sh <url>}"
curl -o /dev/null -sS --max-time 20 \
  -w "url=%{url_effective}\ndns=%{time_namelookup}\ntcp=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\nhttp=%{http_code}\n" \
  "$host"

再配一条 date -Is，把时间点一起记下来。很多“偶发”问题，只有把时间、目标、各阶段耗时放在一起看，才会露出规律。

两个高频变体#

AAAA 记录存在，但 IPv6 不通#

很多「时快时慢」来自 Happy Eyeballs：客户端先尝试 IPv6，等待一小段时间没有结果，再回退到 IPv4。如果 IPv6 是黑洞——包发得出去、回不来——每次新建连接都要先吃一次等待。验证方法很直接：

curl -4 -o /dev/null -sS -w 'v4=%{time_connect}\n' https://example.com/
curl -6 -o /dev/null -sS -w 'v6=%{time_connect}\n' https://example.com/

IPv4 很快、IPv6 卡住，就基本确定了。处理方式不是删掉 AAAA 记录（那会误伤真正有 IPv6 的用户），而是修路由、防火墙或上游通告；临时绕行可以在客户端显式 --ipv4，但要把它当成止血，不是长期方案。

代理只处理了部分流量#

http_proxy、https_proxy、all_proxy 可能来自 shell、systemd、容器编排或桌面系统，各管一段；curl 会读环境变量，而你的应用未必读。用 --noproxy '*' 做一次直连对照：

curl --noproxy '*' -o /dev/null -sS -w 'direct=%{time_total}\n' https://example.com/
curl -o /dev/null -sS -w 'proxy=%{time_total}\n' https://example.com/

直连快、代理慢，问题在代理链路或它的出口；反过来，检查 NO_PROXY 是否把内网域名也送进了代理。容器场景还要确认 sidecar 的拦截规则，别只查宿主机的环境变量。

抓包放在最后，不是第一步#

tcpdump 信息量大，但读起来慢。先有时计和分层结论，再抓一次有针对性的包：

sudo tcpdump -ni any -vv 'host example.com and (port 53 or port 443)' -c 40 -w /tmp/curl.pcap

只看三件事：SYN 有没有重传、TLS ClientHello 之后有没有 ServerHello、连接有没有被 RST。抓包回答的是「到底有没有回包」，不负责解释业务逻辑。把 pcap 和 curl -w 的时间点放在一起，才能判断是链路丢包还是服务端处理慢。

五分钟排查清单#

1. 跑一遍分阶段计时，把耗时归到 DNS、TCP、TLS、TTFB 中的某一段。
2. DNS 慢：分别用 dig 和 getent hosts 对比，检查搜索域与 NSS 顺序。
3. TCP 慢：用 curl -4 / -6 对比，mtr 看丢包跳数，确认安全组与监听地址。
4. TLS 慢：openssl s_client -brief 看握手与证书链，排除代理和 OCSP。
5. TTFB 慢：问题已经不在网络，去看服务端日志、数据库和上游依赖。
6. 仍然偶发：记录时间点，抓 40 个包，别靠重启碰运气。

结论#

排网络问题，顺序比工具重要：DNS → TCP → TLS → 首字节 → 传输。每一层都有对应的计时字段和验证命令，先把耗时归到某一层，再决定抓包还是改配置。绝大多数所谓的“网络慢”，最后都能收敛成一句很具体的话，比如“AAAA 记录指向了一台不通的机器”或者“安全组只放行了 IPv4”。

下一次再遇到超时，先别重启服务，跑一遍上面的计时模板；如果再花五分钟做一次 IPv4/IPv6 与代理的对照，大多数“偶发”就会变成可解释的规律。

反过来的事故更常见：CPU 只有 20%，load 到了 40，整台机器都在超时。两个数字指向完全不同的内核行为，先把它们分开。

100% 的分母是「一个核」#

top 里进程的 %CPU 以单核为分母。16 核机器上一个死循环线程显示 100%，整机理论上限是 1600%。所以看到一个进程 100%，先问：它是单线程打满，还是多线程均摊。

单线程打满通常是代码问题：忙等、正则回溯、序列化大对象。多线程均摊才更像容量问题。用 top -H -p <pid> 展开线程，如果只有一个线程接近 100%，其它线程在睡觉，方向就明确了。

首行的 %Cpu(s) 才是整机视角，按 1 可以展开成每核。nproc 给出可用核数，但容器里它返回的往往是宿主机核数，算容量时要看 cpu.max 而不是 nproc。

另外两个工具的数字经常对不上：top 给的是采样区间内的瞬时占比，ps -o pcpu 给的是进程启动至今的平均值。长跑进程在 ps 里看着温和，实际可能刚刚飙起来，判断当前状态以 top 或 pidstat 1 为准。

load average 里混着 D 状态#

cat /proc/loadavg 输出五个字段：1、5、15 分钟的平均值，当前运行实体数/总进程数，以及最近分配的 PID。前三个数不是 CPU 使用率，而是处于 R（可运行）和 D（不可中断睡眠）状态的任务数的指数衰减平均。

关键在 D。进程卡在磁盘 IO、NFS、某些内核锁上时，一点 CPU 都不消耗，但照样计入 load。所以 load 高、CPU 低，第一件事是找 D 状态进程：

ps -eo stat,pid,comm | awk '$1 ~ /^D/'
vmstat 1 5

vmstat 的 r 列是可运行队列长度（不含 D），b 列是阻塞任务数。r 持续大于核数，说明 CPU 真的排满了；r 很小而 b 不小，问题在 IO。

按核数折算的经验值：load 等于核数时队列刚好排满，到两倍开始明显排队。但这只是经验，IO 密集的机器 load 常年偏高，不能直接当 CPU 指标用。

us、sy、wa、si 各说明什么#

vmstat 1 的 CPU 列里，us 是用户态时间，sy 是内核态，wa 是等 IO 的空闲（新内核里统计口径有变化），st 是被虚拟化层偷走的时间。

sy 高通常有三种来源：系统调用太频繁（大量小 read/write）、上下文切换过多、软中断集中。si 那一列高，说明 CPU 在收包，检查 /proc/interrupts 是否集中在 0 号核，网卡多队列或 RPS 没配好是常见原因。

写监控时别直接读 /proc/loadavg 的瞬时值。/proc/stat 第一行的 cpu 字段是 jiffies 累计值，除以 getconf CLK_TCK（多数系统是 100）换算成秒，两次采样做差才是准确的利用率。

想按进程拆开看，用 pidstat 1 的 %usr、%system、%iowait 三列；想看到调用栈级别，用 perf top。如果榜首出现 native_queued_spin_lock_slowpath 这类符号，基本就是锁竞争让 CPU 空转了，加核并不能提高吞吐。

整机平均还会掩盖单核瓶颈。mpstat -P ALL 1 能列出每个逻辑核的占用，如果只有一两个核接近 100%、其余大量 idle，先查中断亲和性和线程绑核，而不是扩容。

上下文切换：在等，还是被抢#

pidstat -w -p <pid> 1 输出两列：cswch/s 是自愿切换，进程主动让出 CPU，多半在等锁、等 IO、sleep；nvcswch/s 是非自愿切换，时间片用完被内核抢占。

前者高说明在等资源，后者高说明 CPU 不够分。grep ctxt /proc/<pid>/status 能看到累计值，两次相减除以间隔就是速率。cat /proc/<pid>/schedstat 的第三个字段是任务在可运行队列里等待 CPU 的累计纳秒数，它持续增长而进程自身的 CPU 时间不涨，说明线程在排队，而不是在干活。

有个容易被忽略的组合：线程数远大于核数，每个线程都抢同一把锁。nvcswch 飙升，sy 上升，吞吐下降，但 CPU 看着只有 60%。此时加机器没用，要减线程或缩短临界区。

容器里还有一层：throttling#

cgroup v2 下 cat /sys/fs/cgroup/cpu.stat，nr_throttled 和 throttled_usec 持续增长，说明进程在配额周期内被限流过。cpu.max 写成 200000 100000，意思是每 100ms 周期最多使用 200ms CPU，等价 2 核。

被限流的线程会停顿几十毫秒，表现为 P99 抖动，而平均 CPU 只有 50%——top 完全看不出来。这也是「容器里 CPU 没用满但就是慢」最常见的原因。

docker run --cpus=2 最终写进 cpu.max 的也是同样的 200000 100000。注意容器内的 top 仍按宿主机核数算百分比，2 核配额跑满时整机只显示 6%，拿它判断容器压力会严重低估。

想确认热点，用采样而不是猜：perf record -F 99 -g -p <pid> -- sleep 30，再生成火焰图看 on-CPU 的栈。机器上进程很多时把 -p 换成 -a，先看全局热点，再缩小到具体 PID。strace -c 能统计系统调用耗时，但会给目标进程带来明显开销，生产环境只在短时间窗口内用。

perf top 的三个列分别是被采样到的比例、所属共享对象和符号名。看到比例集中在 libc 的 memcpy，问题通常不在 memcpy 本身，而在于调用它的地方在做大块复制；加上 -g 打开调用图，才能顺着栈找到真正的业务函数。

云端还要看 steal time#

虚拟机里 %Cpu(s) 有一列 st，表示物理核被别的租户占走、本该给你却没给的时间。st 长期大于 0，说明宿主机超卖，这时候容器内怎么调优都没用，该换规格或者换宿主机。top 的 st 只在整机视角显示，单进程看不到。

结论#

• 先分清整机 %Cpu(s) 和单进程 %CPU 的分母，再看是单线程打满还是多核均摊。
• load average 包含 D 状态，load 高不等于 CPU 忙；用 vmstat 的 r 和 b 列区分排队与阻塞。
• sy 高查系统调用与上下文切换，si 高查中断分布，别一律归因于「代码慢」。
• 容器场景必须看 cgroup 的 cpu.stat，限流造成的抖动在宿主机监控里是隐形的。
• 定位热点靠采样（perf），不靠重启和猜测；重启只能清空现场。

另一个方向：容器被 OOM Killer 杀掉，监控上的内存曲线却一直很平。因为监控采的是 RSS，而杀进程的是 cgroup 的内存上限，两者根本不是同一个数。

free 的四个数不是一回事#

free -m 的输出里，total 是物理内存总量，free 是完全没有被使用的页，buff/cache 是块设备缓存和可回收的 slab，available 是内核估算的「不触发 swap 就能分配给新进程」的量。

available 才是判断内存够不够的依据。它由 free 加大部分可回收的 page cache，再减去不可回收部分和低水位保留得来。所以 free 很小、available 很大是健康状态：内存被拿去缓存文件了，需要时立刻能回收。

free -m
grep -E 'MemTotal|MemAvailable|Cached|Dirty|Writeback|Committed_AS|CommitLimit' /proc/meminfo

Dirty 是等着回写的页，Writeback 是正在回写的页。Dirty 长期很高说明写入速度超过了磁盘，该查的是 dirty_ratio（默认 20%）和 dirty_background_ratio（默认 10%），而不是加内存。

虚拟内存和常驻内存差在哪#

进程的 VSZ 可以到几十 G，实际驻留的 RSS 可能只有几百 M。VSZ 包含已映射但从未触碰的匿名页、共享库、以及 mmap 的文件区间。malloc 拿到地址不等于拿到物理页，第一次写才触发缺页中断去分配。

RSS 也有水分：多个进程映射同一个共享库，每个进程的 RSS 都把这段算一遍。要看真实占用，用 PSS（按共享比例分摊）或 USS（独占）：

smem -t -k -P 'java|nginx'
# 内核 4.14+ 可以直接读汇总，比逐个解析 smaps 快
awk '/^Rss/{print $2/1024 " MB"}' /proc/<pid>/smaps_rollup

采集脚本里用 smaps_rollup，一次系统调用拿到整个进程的汇总。逐个 smaps 里的每个 VMA 去读，进程映射一多就会明显拖慢采集端本身。

还有一个差异来自运行时是否愿意把内存还给内核。glibc 释放大块内存时会用 madvise(MADV_DONTNEED) 还回去，RES 会掉；JVM 的堆即使在 Full GC 之后通常也不缩，RES 只涨不跌。这解释了为什么同样是「内存泄漏」的曲线，有的服务能自己降下来，有的只能靠重启。

页缓存：free 少不是浪费#

Linux 会把空闲内存尽量用于 page cache。读文件时数据从磁盘进缓存，第二次读直接命中；读还有预读（readahead），顺序读时内核会提前把后面的页拉进来。写文件默认也先进缓存并标记 dirty，由回写线程在后台刷盘。

想知道某个文件有多少页真的在缓存里，用 fincore <file>（util-linux 自带），它按 mincore 的结果统计驻留页。排查「为什么这个读请求还是慢」时，它比看整机 free 有用得多。

这意味着两件事。第一，free 少是设计目标，不是故障。第二，OOM 发生前内核会先回收 page cache，回收不动才动手杀进程——所以「缓存把内存吃光了」这个说法在绝大多数情况下不成立。

真正不可回收的是匿名页：堆、栈、匿名 mmap。它们只能换出到 swap，swap 关闭时就只能被杀。判断方向很简单：/proc/meminfo 里 AnonPages 在涨还是 Cached 在涨，两者的处置方式完全相反。

有人习惯用 echo 3 > /proc/sys/vm/drop_caches 来「释放内存」。它只是把缓存丢掉，下一次读还得从磁盘重新拉，除了做基准测试，生产上找不到用它的理由。

OOM Killer 是怎么挑人的#

内核在分配内存失败、且回收后仍无法满足时触发 OOM。日志长这样：

Out of memory: Killed process 28471 (java) total-vm:8388608kB, anon-rss:7518204kB, file-rss:1024kB
oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/app,task=java,pid=28471,uid=1000

第一行是被杀进程的内存构成，第二行是判定上下文。task_memcg=/app 说明这是 cgroup 级别的 OOM，不是整机 OOM，处理方式完全不同：整机 OOM 要找出真正的大户，cgroup OOM 要调 memory.max 或者修内存泄漏。

/proc/<pid>/oom_score 是当前得分，oom_score_adj 可调（-1000 到 1000）。把关键进程设成 -1000 能显著降低被杀概率，但代价是别的进程替它死，不是护身符。

得分是按进程占用内存的比例算的，这带来一个反直觉的结果：一个刚启动、RSS 还很小但马上要吃满内存的进程，得分很低，它会一直膨胀到把别人挤死才被盯上。所以「OOM 杀错了人」这件事，多数时候不是内核判断错，而是被杀时它确实最大。

cgroup v2 下看计数：

cat /sys/fs/cgroup/app/memory.max
cat /sys/fs/cgroup/app/memory.current
cat /sys/fs/cgroup/app/memory.events   # oom / oom_kill 计数

memory.events 里 oom 是触发次数，oom_kill 是真正杀掉的次数。前者大于后者，说明出现过「差点被杀、但回收成功」的情况，这是扩容的早期信号，比等进程真死要早得多。

几个容易踩的边界#

vm.overcommit_memory=0 是启发式，允许适度超额；=1 永远答应 malloc，风险自担；=2 严格按 CommitLimit，容易让正常进程申请失败。Redis 这类会 fork 的进程在 =2 下经常起不来。

vm.swappiness 不是「用不用 swap」的开关，而是回收匿名页相对 page cache 的倾向。设 0 也只是降低倾向，不等于禁用。

还有透明大页（THP）。开启 always 时，进程的 RSS 会按 2M 对齐膨胀，top 里的 RES 看着比实际用量大不少。要准确统计就关掉它，或者用 AnonHugePages 单独核对。

cgroup v2 还有一层 memory.high。超过它不会立刻触发 OOM，而是把进程放进强制回收状态，速度变慢但能继续跑。用它做缓冲，比直接把 memory.max 卡死在峰值上更稳。

用 PSI 看真实压力#

/proc/pressure/memory 给出 some 和 full 两行，avg10 是过去 10 秒的阻塞时间占比。some 表示有任务因内存不足停住，full 表示所有可运行任务都被卡住——后者非零，说明内存已经不是紧张而是告急了。

cgroup v2 的每个组也有自己的 memory.pressure。容器内存快不够时，先看这个值再决定扩不扩，比盯 RSS 曲线直观。它只统计本组任务的阻塞，所以能区分「是容器自己撑爆」还是「宿主整体紧张」。

结论#

• 判断内存够不够看 available，不看 free；free 小、cache 大是正常状态。
• VSZ 是承诺，RSS 是现状，PSS 才接近真实占用；采集脚本优先用 smaps_rollup。
• 先区分整机 OOM 和 cgroup OOM，前者查大户，后者改 memory.max 或修泄漏。
• memory.events 的 oom 计数是扩容前的预警，比等进程被杀更早。
• 加内存之前先确认占用是匿名页还是可回收缓存，否则扩完还是同一条曲线。

数据库里的 created_at 也偏了 8 小时。更麻烦的是它不影响功能测试，只在跨天统计、定时任务、账单日切时冒出来，属于典型的「上线一周后才被发现」的问题。

先确认是不是时区问题#

容器和宿主机共享内核，CLOCK_REALTIME 是同一个值，容器不可能自己走慢。能不一样的只有用户态对时间的解释：/etc/localtime、TZ 环境变量，以及语言运行时启动时缓存下来的那份副本。

在容器里跑这几条命令，基本能定性：

date -u; date; ls -l /etc/localtime; echo "TZ=$TZ"
TZ=Asia/Shanghai date

如果 date -u 和宿主机一致、date 差 8 小时，就是时区配置问题，不用碰 NTP。TZ=Asia/Shanghai date 如果仍然输出 UTC，说明镜像里根本没有 zoneinfo 数据，设变量也没用。

三种修法，各有边界#

最稳的是第三种：镜像自带 tzdata，再用 TZ 指定。挂载宿主文件适合临时排查，不适合长期方案，因为镜像从此依赖宿主配置，换台机器就可能不一样。

FROM alpine:3.20
RUN apk add --no-cache tzdata \
 && cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime \
 && echo "Asia/Shanghai" > /etc/timezone
ENV TZ=Asia/Shanghai

注意 apk add 之后要清 /var/cache/apk，否则镜像白白大几 MB。

还有一处语法陷阱：TZ=UTC+8 不是「东八区」。POSIX 的 TZ 字符串里符号是反的，CST-8 才表示 UTC+8。写错方向会得到差 16 小时的结果，而且程序不报错。

验证时别用 docker exec 进去临时 export TZ。exec 启动的 shell 继承镜像的 ENV，你在会话里 export 只影响这个 shell，服务进程仍然用旧值。要验证就重新 docker run 一个容器，或者直接看进程的环境：tr '\0' '\n' < /proc/<pid>/environ | grep TZ。

挂载单文件为什么有时不生效#

-v /etc/localtime:/etc/localtime:ro 在 Linux 宿主上通常有效，但有两个前提容易忽略。

第一，Docker Desktop（macOS、Windows）跑在一台 Linux 虚拟机里，/etc/localtime 是虚拟机的文件，不是宿主系统的时区，挂进去可能还是 UTC。

第二，镜像里的 /etc/localtime 常常是指向 /usr/share/zoneinfo/Etc/UTC 的软链接。只挂这一个文件不会同步整套 zoneinfo，依赖 /etc/timezone 或按名字查时区的程序仍然拿到旧值，两套配置互相矛盾。

要挂就挂整个目录：-v /usr/share/zoneinfo:/usr/share/zoneinfo:ro，再配合 TZ。这样既不改镜像，也不会破坏软链接结构。

语言运行时各有各的缓存#

改完系统时区，跑着的进程不一定立刻生效，因为很多运行时在启动时就把时区读走了：

• Java：JVM 启动时确定默认时区，之后改 /etc/localtime 无效。用 -Duser.timezone=Asia/Shanghai，或保证容器启动前 TZ 已设置。验证命令：java -XshowSettings:properties -version 2>&1 | grep user.timezone。
• Python：time.tzset() 会重新读 TZ；zoneinfo.ZoneInfo("Asia/Shanghai") 依赖系统 tzdata，缺失时抛 ZoneInfoNotFoundError，可以装 tzdata 包兜底。
• Go：time.Local 启动时读 TZ，静态编译的二进制在 scratch 镜像里没有 zoneinfo，需要 -tags timetzdata 把数据编进去，或把 /usr/share/zoneinfo 拷进镜像。
• Node.js：启动时读 TZ，运行中改 process.env.TZ 的行为在不同版本上并不一致，别依赖它。

这些都是「进程启动那一刻」的快照，不是实时查询。所以配置时区的正确时机是容器启动之前，而不是出事之后。

Java 连 MySQL 还有一层：JDBC 的 connectionTimeZone（旧版本叫 serverTimezone）决定驱动怎么解释 TIMESTAMP，和 JVM 时区是两套独立配置。只改了 -Duser.timezone 却没动 JDBC 参数，写进库里的值照样会偏。

时区对了，时间还差几秒#

这类问题的偏差不是 8 小时，而是几百毫秒到几秒，而且只在长时间运行后显现。原因通常是宿主或虚拟机的时钟漂移。

容器共享宿主内核时钟，容器内无权设置时间（需要 CAP_SYS_TIME），只能由宿主同步。在宿主上 chronyc tracking 看当前偏移和漂移率，chronyc sources -v 看时间源是否可达。chrony 多数时候是渐进校正，偏差超过 makestep 阈值时才会跳变，所以你会看到偏移慢慢收敛，而不是「一 synced 就准」。

注意 NTP 校正的是墙钟，CLOCK_MONOTONIC 不受影响。这也是为什么同一个进程里，测耗时用单调时钟更可靠。

时间命名空间管不了时区#

Linux 有 time namespace，可以偏移 CLOCK_MONOTONIC 和 CLOCK_BOOTTIME，但 CLOCK_REALTIME 是全局的，Docker 默认也不给容器独立的 time namespace。换句话说，容器时间不可能靠命名空间和宿主错开，能错的只有解释方式。

顺带一个容易被忽略的点：CLOCK_MONOTONIC 不受 NTP 调整影响，测耗时应该用它，而不是 time.time() 这类墙钟。墙钟会因为闰秒、NTP 回拨跳变，定时器算出负的间隔就是这么来的。

定时任务为什么在凌晨跑#

服务里有个每天 00:10 执行的清理任务，上线后总在北京时间 08:10 才跑。日志上看任务确实执行了，只是晚了 8 小时——因为容器是 UTC，cron 按容器的时区解释那行 10 0 * * *。

修复要同时确认三件事：容器 TZ、cron 守护进程自己的时区、调度系统的解析口径。cronie（RHEL 系）支持在 crontab 顶部写 CRON_TZ=Asia/Shanghai，Debian 自带的 cron 不认这个变量，只能依赖容器 TZ。Kubernetes 的 CronJob 默认按 UTC 解析 schedule，新版本可以用 timeZone 字段显式指定，升级集群时记得复查这个字段。

存储用 UTC，展示再转换#

时区配好只是第一步。数据库里存什么，决定了以后换时区会不会出事。

MySQL 的 TIMESTAMP 会按会话时区转换，DATETIME 不会。用 SELECT @@global.time_zone, @@session.time_zone, NOW(), UTC_TIMESTAMP(); 看清当前会话的偏移。PostgreSQL 的 timestamptz 存 UTC、显示时按 TimeZone 参数转换，SHOW timezone; 可查。

我倾向的约定是：存储层统一 UTC，接口和日志用带偏移的 ISO 8601（2026-11-11T14:00:00+08:00），只在最终展示时转本地时间。这样跨时区部署、跨年查询都不会出现「少了一天」。

日志时间戳也建议固定格式，别用本地化字符串。Java 的 logback 用 %d{yyyy-MM-dd'T'HH:mm:ss.SSSXXX}，Go 用 time.RFC3339Nano，Python 用 datetime.now(timezone.utc).isoformat()。带偏移的字符串在任何时区的机器上都能还原成同一时刻，排查时不用再问「这条是哪个时区打的」。

结论#

• 容器时间不对，先比 date -u 和 date，确认是时区解释问题而不是时钟漂移。
• 生产镜像自带 tzdata 并设 TZ，挂载 /etc/localtime 只适合临时排查。
• 运行时在启动时缓存时区，配置必须在容器启动前完成。
• 存储统一 UTC，展示层再转换；TIMESTAMP 和 DATETIME 的语义别混用。
• POSIX 的 TZ 字符串符号与直觉相反，不确定就用 IANA 名称。

另一台机器报 No space left on device，df -h 显示还有 30% 空闲，df -i 的 IUse% 却是 100%。空间够、inode 不够，一样写不进新文件。两种「磁盘满」，处置方式完全不同。

还有第三种：Kubernetes 节点上 ephemeral-storage 报警，节点 df 看着正常，实际是被某个容器的可写层吃掉了。这属于 kubelet 的本地存储记账，df 只统计挂载点，看不到这一层。

unlink 删的是名字，不是数据#

Linux 里文件名只是目录项到 inode 的映射。rm 调用 unlink，把目录项去掉，inode 的链接计数减一。只有当链接计数为 0、且没有任何进程持有打开的文件描述符时，内核才释放数据块。

所以进程还开着这个文件时，空间不会回来。lsof +L1 专门找链接数小于 1 的已打开文件：

lsof +L1
lsof | grep -i deleted
# 不装 lsof 时，直接扫 procfs
ls -l /proc/*/fd 2>/dev/null | grep deleted

输出里的 DEL 或 (deleted) 标记就是证据。lsof +L1 比 lsof | grep deleted 快，因为它按链接数过滤，不用遍历所有条目再匹配字符串。

释放空间的两个动作#

确认了 PID 和 fd，有两条路：

1. 重启进程。最稳，代价是服务中断。
2. 原地截断。truncate -s 0 /proc/<pid>/fd/<fd>，或者 shell 里 : > /proc/<pid>/fd/<fd>。

第二条有前提：这个 fd 必须以可写方式打开，进程有权限，截断的是同一个 inode。另外 fd 的文件偏移不会重置。如果进程不是以 O_APPEND 打开，下一次写会落在旧偏移处，文件变成稀疏文件，du 看着小、ls -l 看着大。日志框架多用 append，一般没事，自己写的 writer 要留意。

为什么日志轮转后空间还是没回来#

这是线上最常见的一幕：logrotate 配了 create 模式，把 app.log 改名成 app.log.1，再建一个新的空文件。nginx 之类持有旧 fd 的进程继续往 app.log.1 里写，新文件永远是空的。

copytruncate 模式看起来能解决，因为它复制完直接截断原文件，但代价是复制和截断之间写入的日志会丢。要在「可能丢日志」和「空间不释放」之间选，我选后者：把轮转配置改成 create，并在轮转后给进程发信号（nginx 用 USR1 重开文件），日志和空间都能保住。

空间被谁吃了：按目录下钻#

确认不是已删除文件之后，才轮到找大目录。我习惯按这个顺序：

du -x --max-depth=1 /var | sort -h | tail -10
find / -xdev -type f -size +1G -printf '%s %p\n' | sort -n | tail -10
stat -f /var

-x 保证不跨文件系统，sort -h 按人类可读单位排序。find 的 -size +1G 只匹配大文件，比全量 du 快得多，适合在几百万文件的机器上快速定位。ncdu 交互式浏览更直观，但遍历开销一样，大目录上要等。

stat -f 给出块大小、总块数和可用块数。当 df 和 du 死活对不上时，先确认两条命令看的是不是同一个挂载点——路径上多一层 bind mount，结论就会完全不同。

inode 也会被用光#

df -i 看 inode 使用率。ext4 在 mkfs 时按 -i 参数固定（默认每 16KB 一个 inode），之后只能靠扩容按比例增加，不能凭空变多。XFS 动态分配，相对不容易撞上。

inode 耗尽的典型场景：海量小文件、session 文件、邮件队列、容器层里成千上万的碎文件。表现和磁盘满一模一样，但 df -h 正常，只有 df -i 能看出来。

这个方法主要对 ext4 这类预分配 inode 的文件系统有意义。btrfs 和 xfs 的 inode 是动态分配的，df -i 的数字会一直涨，拿它做告警阈值会误报。

df 和 du 对不上，还有这几种原因#

du -x 的 -x 很重要：不加它，du 会跨文件系统统计，把挂载进来的网络盘也算进去，结果自然对不上。

硬链接是另一种「删不干净」。文件有两个名字时，删掉一个只是链接计数从 2 变 1，数据还在。用 find / -xdev -inum <inode号> 能把剩下的名字找出来。

另一个上限：文件描述符#

inode 是文件系统的配额，fd 是进程的配额，两者都会以「资源不够」的形式报错。报 Too many open files 时按顺序看三个值：

ulimit -n                      # 当前 shell 的软限，常见 1024
cat /proc/sys/fs/file-nr       # 已分配 / 未用 / 内核上限
cat /proc/<pid>/limits | grep 'open files'

systemd 服务要改 LimitNOFILE，注意写成 infinity 时实际会被内核截到 fs.nr_open（默认约 100 万），不是真的无限。调大之前先确认不是 fd 泄漏：ls /proc/<pid>/fd | wc -l 隔一段时间看两次，只涨不跌就是泄漏。

删掉的文件还能找回吗#

有进程开着的时候最简单：cp /proc/<pid>/fd/<n> /tmp/recover.log 直接把数据拷出来。所以发现误删的第一件事是别重启进程。

没进程持有就麻烦了。ext4 上可以试 debugfs -R 'lsdel' /dev/sdX，但延迟分配、discard 和 inode 复用会让成功率很低。这也是为什么备份比恢复工具靠谱——文件系统不承诺删除可恢复。

进程的根目录也会骗人#

容器里的问题经常漏看：在宿主上跑 lsof，看到的只是宿主的 mount namespace。容器内已删除但仍被持有的文件，要么不出现，要么路径指向一个宿主上不存在的位置，du 遍历自然也走不到。

对这类进程，nsenter -t <pid> -m lsof +L1 才能看到容器视角的文件表；ls -l /proc/<pid>/root/ 能看到它的根目录挂的是什么。这也是「节点磁盘满了，du / 却找不到大户」的常见解释。

被遮住的挂载点#

如果往一个非空目录上 mount 了别的文件系统，原目录里的文件并没有删，只是被遮住了。df 统计的是挂载后的文件系统，du 也看不到被遮住的内容，但空间确实被占着。卸载挂载点，或者 mount --bind 到别处就能看到。这类问题通常出现在手工运维过的机器上。

ext4 默认给 root 保留 5% 的空间，df 对普通用户显示的 available 会比 root 少。数据盘上这个比例纯属浪费，tune2fs -m 1 /dev/sdX 可以调到 1%，但系统盘不建议动。

结论#

• rm 只删目录项，进程还开着文件时空间不释放；用 lsof +L1 定位，别急着重启。
• 原地截断可行，但要确认 fd 可写和偏移量行为，否则会得到稀疏文件。
• No space left on device 先看 df -i，inode 和容量是两套配额。
• df 与 du 不一致时按表逐项排除，du 记得加 -x。
• 长期方案是日志轮转配合正确的重开信号，而不是出事之后手工找文件。

浏览器也不是单进程。地址栏属于 browser 进程，网络请求交给 network service，页面解析和渲染在 renderer 进程。一次导航要在这三个进程之间走一圈，任何一环都能成为瓶颈。

从按键到发出请求#

browser 进程先判断输入是 URL 还是搜索词。是 URL 就做规范化：补 scheme、处理 IDNA（中文域名转 punycode）、查 HSTS 列表决定是否强制 https。

如果域名在 HSTS 预加载列表里，即使用户输入 http://，浏览器也会直接走 https，不会发出明文请求。这一步在 DevTools 的 Network 面板里看不到，但在 chrome://net-export 的日志里能看到 HSTS 决策记录。

然后是找连接：先看 socket 池里有没有到同源的可复用连接，没有才走 DNS。DNS 缓存有好几层——浏览器自身、操作系统 resolver，可能还有 DoH。任何一层命中，domainLookupEnd - domainLookupStart 都会接近 0，此时纠结 DNS 优化没有意义。

握手成本取决于物理距离#

TCP 三次握手一个 RTT，TLS 1.3 一次往返完成，TLS 1.2 要两次。同城机房 RTT 1ms 时这点开销可以忽略；跨洋 RTT 150ms 时，新建连接光握手就 300ms 以上，还没算 HTTP 请求本身。

这就是连接复用的价值。HTTP/2 在一条连接上多路复用，多个资源共享同一次握手；HTTP/3 基于 QUIC，把传输握手和 TLS 合并，还支持 0-RTT 恢复。performance.getEntriesByType('navigation')[0].nextHopProtocol 会告诉你实际用的是 h2、h3 还是 http/1.1。

重定向是另一个隐形开销。一次 302 意味着新的请求，若跨域还要重新 DNS 加握手。登陆后跳转、http 到 https、带不带尾斜杠的规范化，都可能在关键路径上叠两三个 RTT。nav.redirectCount 大于 0 时就该查。

第三方域名可以用 preconnect 提前完成 DNS、TCP 和 TLS，用 dns-prefetch 只做解析。但 preconnect 会占用连接槽，给七八个域都加上，收益可能变成负数。

首字节之后才是大头#

HTML 到达后，renderer 开始解析。这里有个常被忽略的机制：preload scanner 会在主解析器被阻塞时，提前扫描后面的 HTML，发现 <script src> 和 <link rel=stylesheet> 就去预加载。它不执行脚本，只负责尽早发起请求。

所以关键路径通常是：CSS 阻塞渲染，同步脚本阻塞解析。给脚本加 defer 会延后到解析完成、按顺序执行；async 是下载完就执行，顺序不保证。两者都不阻塞 HTML 解析，但 defer 脚本会在 DOMContentLoaded 之前跑完。

DOMContentLoaded 和 load 是两回事：前者是 DOM 就绪（defer 脚本执行完），后者要等图片、iframe 等所有资源。用 load 衡量白屏是错的，白屏对应的是首次绘制，也就是 FCP。

字体是常见的隐性阻塞点。自定义字体没加载完时，浏览器可能先不显示文字（FOIT），font-display: swap 能让它先用后备字体渲染，代价是可能闪一下。

还有一个顺序问题：CSS 里的 @import 是串行加载的，A 里的 @import B 意味着解析到 A 之后才发现 B。首屏关键样式直接内联，能省掉一次往返；首屏用不到的样式用 media 属性拆出去，别一股脑塞进主样式表。

服务端那段时间在做什么#

TTFB 是 requestStart 到 responseStart，中间包含服务端从内核 accept 到写回第一个字节的全过程。常见的排队点有四个：accept 队列、线程或进程池、数据库连接池、上游依赖。

判断方法是对比服务端自己的埋点。如果应用日志显示处理只花了 20ms，而 TTFB 是 800ms，那时间不在业务代码里，八成卡在入口排队或回程网络。ss -lnt 的 Recv-Q 持续非 0，说明 accept 队列有堆积，这时候调大 backlog 只是缓解，真正的问题在消费速度。

预加载不是银弹#

<link rel=preload> 只是告诉浏览器「这个资源马上要用，提前下载」，它不改变阻塞关系，也不会自动提升执行优先级。用错了反而抢走关键资源的带宽。

现代浏览器支持 fetchpriority="high"，给 LCP 图片或首屏字体标上，比堆一堆 preload 更直接。判断标准很简单：被 preload 的资源必须在首屏渲染的关键路径上，否则只是提前占带宽。

二次访问为什么快#

回访时看 nav.type：正常导航是 navigate，从历史记录返回可能是 back_forward。bfcache 会把整页状态冻结在内存里，返回时几乎瞬间恢复；资源命中强缓存时 transferSize 为 0。

「用户说快、测试说慢」的争论，很多时候就出在这里：测试用的是无缓存的新会话，用户走的是 bfcache。

用 Navigation Timing 量化每一段#

在页面控制台跑这段，直接得到各阶段耗时：

const nav = performance.getEntriesByType('navigation')[0];
const ms = (a, b) => Math.round(nav[b] - nav[a]);
console.table({
  DNS: ms('domainLookupStart', 'domainLookupEnd'),
  TCP: ms('connectStart', 'connectEnd'),
  // 复用连接时 secureConnectionStart 为 0，必须单独判断
  TLS: nav.secureConnectionStart ? Math.round(nav.connectEnd - nav.secureConnectionStart) : 0,
  TTFB: ms('requestStart', 'responseStart'),
  'HTML 下载': ms('responseStart', 'responseEnd'),
  'DOM 就绪': ms('responseEnd', 'domContentLoadedEventEnd'),
  '总耗时': Math.round(nav.duration),
});
console.log('协议:', nav.nextHopProtocol, '重定向:', nav.redirectCount);

new PerformanceObserver((list) => {
  for (const e of list.getEntries()) console.log('LCP', Math.round(e.startTime), e.element);
}).observe({ type: 'largest-contentful-paint', buffered: true });

如果 TTFB 就有 2.5 秒，问题在服务端或网络，前端优化没意义。如果 TTFB 200ms 而 LCP 在 3 秒，就是资源加载或渲染阻塞。跨域资源的详细 timing 需要对方返回 Timing-Allow-Origin，否则很多字段是 0。

一次白屏的排查顺序#

线上反馈「打开很慢」时，我不会先开 Performance 面板，而是按固定顺序走：

1. Network 面板按时间排序，看第一个请求的 TTFB。超过 800ms 就先查后端，前端先不动。
2. 看 Waterfall 里有没有被阻塞的 CSS 或同步脚本，Content Download 段很长说明包太大。
3. Console 里跑上面的脚本，确认 nextHopProtocol 和 LCP 对应的元素。
4. 最后才看火焰图和长任务，此时已经知道该看哪一段。

这套顺序的价值是排除：每一步都可能直接结束排查，不用在面板里翻十分钟。顺手记一下 document.readyState，它只有 loading、interactive、complete 三个值，和 DOMContentLoaded、load 大致对应；写自动化脚本判断页面可用，用它比等固定秒数可靠。

按阶段对照优化手段#

结论#

• 白屏先量 TTFB：它慢就是后端和网络，别在前端打转。
• 复用连接能省一整个 RTT 以上，跨地域时尤其明显；确认 nextHopProtocol 是不是 h2。
• DOMContentLoaded 不等于用户看到内容，用 FCP 和 LCP 衡量首屏。
• 同步脚本和 CSS 是渲染阻塞的主要来源，defer 只解决前者。
• 采集脚本要处理 secureConnectionStart 为 0 的情况，否则 TLS 耗时是错的。

更麻烦的是它只在特定数值上暴露。测试用例里的 0.1 和 0.2 看着正常，换成 19.99 加 0.01 就少一分。误差是否显现，取决于二进制表示和后续运算，所以「本地测过没问题」完全不能作为依据。

0.1 在二进制里是无限循环#

双精度（binary64）用 1 位符号、11 位指数、52 位尾数表示，加上隐含的前导 1，有效精度 53 位。它能精确表示 1/2、1/4 这类分母是 2 的幂的数，表示不了 1/10——就像十进制写不出 1/3。

判断一个小数能否精确表示有个简单办法：不断乘 2 取小数部分，能归零就能精确表示。0.5 → 1.0，一步到零；0.1 → 0.2 → 0.4 → 0.8 → 1.6 取 0.6 → 1.2 取 0.2，进入 0.2 → 0.4 → 0.8 → 0.6 的循环，永远到不了 0。0.1 的二进制是 0.0001100110011...，存进去的是最接近的可表示值：

>>> 0.1
0.1
>>> from decimal import Decimal
>>> Decimal(0.1)
Decimal('0.1000000000000000055511151231257827021181583404541015625')
>>> 0.1 + 0.2
0.30000000000000004

解释器打印的是「能唯一还原这个浮点数的最短表示」，误差就被藏起来了。Decimal(0.1) 接收的是浮点数，于是展开出那个精确的二进制值；想从十进制字面量构造，得写 Decimal('0.1')。

0.1 + 0.2 的结果本身没有「算错」：两个近似值相加，再舍入到最近的可表示值，得到 0.30000000000000004。这是表示误差，不是运算误差。IEEE 754 规定了加法的正确舍入，所以同样的输入在任何平台上结果一致。

比较和累加都会踩坑#

直接用 == 比较浮点几乎总是错的。常见写法是设一个容差：

def almost_equal(a, b, rel=1e-9):
    return abs(a - b) <= rel * max(abs(a), abs(b), 1.0)

Number.EPSILON（约 2.22e-16）是 1 和下一个可表示数之间的间隔，不是通用容差。数值大时绝对误差也会变大，所以上面用相对误差。标准库其实已经提供了 math.isclose，语义就是相对误差比较，没必要自己写；numpy.allclose 默认容差是 1e-5，对金额来说太松，要显式传 rtol。

累加更隐蔽：一百万次加 0.0001，结果可能偏出好几分钱。大数吃小数更典型——1e16 + 1 == 1e16，因为 1 小于该量级的间隔。整数的安全范围是 Number.MAX_SAFE_INTEGER，即 9007199254740991，超过就只能近似。需要高精度累加时，Kahan 求和能把误差从 O(n) 降到 O(1)，但金额场景直接上定点数更省事。

金额用整数分或十进制#

两条路都可行，选一条并贯彻到底：

• 整数分：内部全部用 long / BigInt 存「分」，展示时除以 100。适合交易、账单、库存计价。
• 十进制定点：数据库 DECIMAL(18,2)，语言里用 Decimal / BigDecimal，从字符串构造。

from decimal import Decimal, ROUND_HALF_UP

total = Decimal('100.00')
ratios = [Decimal('0.3333'), Decimal('0.3333')]
head = [(total * r).quantize(Decimal('0.01'), rounding=ROUND_HALF_UP) for r in ratios]
parts = head + [total - sum(head)]     # 最后一份兜底，保证求和等于总额
print(parts, sum(parts))               # 和一定等于 100.00

分摊、拆单、优惠券这类场景，最后一项用「总额减前几项」兜底，是唯一能保证求和相等的做法。每项独立四舍五入，累计误差迟早暴露。

用整数分还有两个细节。单位换算要先乘后除：算百分比分成时写成 amount * rate / 100，别先 amount / 100 再乘，整数除法会提前截断。负数舍入方向也要固定，Math.round(-0.5) 得到的是 -0，不是 -1，退款金额会差一分。

Decimal 的默认上下文是 28 位精度，除法要显式 quantize，否则可能抛 InvalidOperation 或者留下超出预期的位数。

定点数其实很简单#

整数分本质就是定点数：把 1 元当成 100，小数位固定两位。加减直接算；乘法之后要除一次 scale，除法之前要先乘 scale，顺序反了精度就先丢了。每次运算后检查溢出——64 位有符号整数上限约 9.2e18，按分算能表示九亿亿元，金额够用，但中间乘法很容易越界。

Go 的 decimal 库、Java 的 BigDecimal、Python 的 Decimal 都是这个思路的通用实现，区别只在 scale 是否随运算自动调整。自己封装定点类型时把 scale 固定成常量，比让每次运算自己推导简单，也更容易和数据库列对齐。格式化输出时再除，别在中间结果里引入小数。

什么时候必须用精确算术#

判断标准不是「涉不涉及小数」，而是「结果要不要和账目逐分对上」。进度条、图表坐标、压测的百分比，double 完全够用；计费、发票、税额、退款、分摊、汇率换算，必须精确。

最糟糕的是混用：一部分金额用 double，一部分用 BigDecimal，在转换处又引入一次误差，最后连错在哪都定位不到。选一条路，在接口边界上就完成转换。

还有一类常被忽略：跨币种结算的汇率。汇率本身是小数，相乘后再截断，方向错一位就是几十块。汇率保留几位、按什么规则舍入，要在业务规则里写死，不能留给代码里的默认行为。

常见框架的坑#

Java 里字段声明成 double、数据库列是 DECIMAL，MyBatis 会做隐式转换，读出来就可能少一分。实体类统一用 BigDecimal，JDBC 的 getBigDecimal 才不会经过浮点。

JSON 序列化更隐蔽：BigDecimal 默认输出成数字，浏览器 JSON.parse 又把它变成 double。要么序列化成字符串，要么前端引入 decimal 库，别指望「后端精确就够了」。

舍入规则要说清楚#

Python 的 round() 是银行家舍入：round(2.5) 得 2，round(3.5) 得 4。财务场景通常要四舍五入，用 ROUND_HALF_UP 显式指定。

浮点还会让 round 更不可靠：round(2.675, 2) 得 2.67，因为 2.675 实际存的是 2.67499999...。JavaScript 的 toFixed 同理，(1.005).toFixed(2) 是 "1.00"。凡是和钱有关的舍入，都不要依赖默认行为。

有些团队还会在数据库层再做一次舍入，这可能和业务层的规则冲突。舍入规则只能有一个定义处，通常放在领域层，数据库只负责存。

存储和传输也要对齐#

JSON 没有整数类型，9007199254740993 在 JavaScript 里解析出来会变成 ...992。金额一般到不了这个量级，但 19 位雪花 ID 会，必须用字符串传。

结论#

• 0.1 + 0.2 的误差来自二进制表示，不是语言 bug；换语言不解决问题。
• 浮点比较用相对误差，别用 ==，也别把 EPSILON 当万能容差。
• 金额统一用整数分或十进制定点，从字符串构造，全链路贯彻。
• 分摊场景最后一项用总额兜底，别让每项独立舍入。
• 舍入规则显式指定，数据库用 DECIMAL，接口用字符串。

理解这一层，很多现象就不用背了：为什么 amend 会改变哈希、为什么 rebase 后所有 commit id 都变了、为什么 .git/objects 里是两位目录加 38 位文件名。

四种对象，一种存法#

Git 仓库里只有四类对象：blob 存文件内容，tree 存目录结构，commit 存一次提交，tag 存附注标签。它们的存储方式完全一致：<type> <content-length>\0<content>。

这段字节做 SHA-1（新仓库可选 SHA-256），得到 40 位十六进制，前两位当目录名，后 38 位当文件名，落在 .git/objects/ab/cdef...。内容用 zlib 压缩，所以直接 cat 是乱码，必须走 git cat-file。

一个能自己验证的例子：空树的哈希是 4b825dc642cb6eb9a060e54bf8d69288fbee4904，全世界所有仓库都一样。用 git hash-object -t tree /dev/null 算一遍，得到同样的值——哈希只由内容决定，没有随机成分。

注意 blob 只存内容，不存文件名和权限——这些在 tree 里。所以同一份内容出现在十个路径下，仓库里仍然只有一个 blob。

手搓一个 commit#

在临时仓库里跑，能看到每一步的中间产物：

mkdir /tmp/git-lab && cd /tmp/git-lab && git init -q
blob=$(printf 'hello\n' | git hash-object -w --stdin)
git cat-file -t "$blob"            # blob
git cat-file -p "$blob"            # hello

tree=$(printf '100644 blob %s\thello.txt\n' "$blob" | git mktree)
commit=$(git commit-tree "$tree" -m 'manual commit')
git cat-file -p "$commit"

git hash-object -w 写入对象并返回哈希；git mktree 从 ls-tree 格式的文本造出 tree 对象；git commit-tree 用当前 user.name、user.email 和当前时间生成 commit。所以同样的内容在不同时间跑，哈希不同。

commit 对象的正文由五个部分组成：

tree 7a8b9c...（指向包含 hello.txt 的那棵 tree）
parent 8f3a1c...（首个 commit 没有这一行）
author 张三 <zhangsan@example.com> 1731200000 +0800
committer 张三 <zhangsan@example.com> 1731200000 +0800

manual commit

时间是 Unix 秒加时区偏移。同一个提交在不同时区生成，字节不同，哈希也不同——这就是为什么 GIT_AUTHOR_DATE 能用来复现历史提交。

另外注意 author 和 committer 是两个字段。前者是原始作者和写作时间，后者是最后一次应用这个改动的人和时间。rebase、cherry-pick、amend 都会保留 author，只更新 committer。用 git log --format='%an %ad / %cn %cd' 能看出哪些提交被人动过。

tree 里存了什么#

git ls-tree HEAD 的输出格式和 mktree 的输入一致：

100644 blob a1b2c3...    README.md
100755 blob d4e5f6...    deploy.sh
040000 tree 7a8b9c...    src

第一列是 mode：100644 普通文件，100755 可执行，040000 子目录，120000 符号链接，160000 是 submodule 的 commit 引用。子目录是一个嵌套的 tree，所以一个 commit 的 tree 是一棵完整的目录树。

文件名不参与 blob 的哈希，这带来一个副作用：重命名在 Git 看来是「删一个 blob 引用、加一个 blob 引用」，git log --follow 只能靠内容相似度猜，猜错很正常。

tag 也是一个对象#

附注标签（git tag -a v1.0 -m 'release'）会真正写出一个 tag 对象。git cat-file -p v1.0 输出 object、type、tag、tagger 和说明文字，object 指向被标记的 commit。

轻量标签（git tag v1.0）不生成对象，只是往 refs/tags/ 写一个指向 commit 的文件。两者在 git describe、GPG 签名和发布记录上有区别，正式发版应该用附注标签。

index 是第三棵树#

工作区、暂存区（index）、HEAD 常被叫做 Git 的三棵树。index 本身不是对象，而是一个二进制文件 .git/index，记录每个路径的 mode、对象哈希和 stage。

git ls-files -s 的输出格式和 ls-tree 完全一致，形如 100644 a1b2c3... 0 README.md。第三列是 stage，冲突时同一路径会出现 1、2、3 三个条目。git add 做的事就是写 blob、更新 index；git commit 再把 index 序列化成 tree 并写 commit。所谓提交，本质是 index 的一次快照。

冲突时 index 里有什么#

合并冲突时，git ls-files -u 会列出同一路径的三个 stage：1 是共同祖先，2 是当前分支（ours），3 是对方（theirs）。三份 blob 哈希同时存在 index 里，工作区文件则被写入冲突标记。

解决冲突就是选一份或者手改，然后 git add。它会把三个条目合并回一个 stage 0，冲突才算结束。git checkout --ours <file> 只是把工作区文件换成自己那份，不会自动 add，很多人以为执行完就完事了。

理解 stage，就不会被 git status 里那句 both modified 绕晕：它只是在说这个路径有三个索引条目，还没归一。

哈希链和引用#

commit 之间靠 parent 字段串成链。每个 commit 的哈希包含父提交的哈希，所以改动历史中任何一个字节，它之后所有 commit id 都会变。这就是 rebase 后必须 force push 的原因——不是 Git 想为难你，是哈希真的全变了。

HEAD^ 是父提交，HEAD~3 是往上三代，HEAD^{tree} 直接取出 commit 指向的 tree。这些语法本质都是在对象图上走边。

引用只是文件：.git/refs/heads/main 里存着 40 位哈希，HEAD 里通常写 ref: refs/heads/main。detached HEAD 时，HEAD 直接存哈希。

删除分支只是删掉这个文件，commit 对象还在，靠 reflog 能找回来。先用 git reflog 找到位置，再用 git cat-file -p HEAD@{3} 看内容；实在找不到，用 git fsck --lost-found 扫一遍不可达对象。

reflog 默认保留 90 天，过期后 git gc 才会真正清理不可达对象。

packfile：从松散对象到压缩包#

git gc 之后，松散对象会被打包进 .git/objects/pack/*.pack，并在其中用 delta 存储——相似的文件只存差异。这时候单个对象不再有独立文件，git cat-file 会去 pack 里查。

git count-objects -vH 能看松散对象的数量和体积；git verify-pack -v .git/objects/pack/*.idx | sort -k3 -n | tail -5 按大小列出 pack 里的对象。第三列是字节数，按它排序就是最大的几个对象，仓库体积异常时这是最快的入口。后面的 depth 列是 delta 链深度，链太长会拖慢读取，git repack -adf 可以重建打包。

需要批量查对象时用 git cat-file --batch，一次进程处理多个哈希。脚本里循环调用 git cat-file -p 的写法，在几万个对象上会慢一个数量级，瓶颈全在反复 fork。

不知道对象大小时，git cat-file -s <hash> 直接给出解压后的字节数，比 -p 打出来再数省事。

除了松散对象和 packfile，还会看到一个 commit-graph 文件。它是提交图的索引，git commit-graph write 生成，能让 git log、git rev-list 在大仓库上快很多。它不存内容，只是一份派生索引，删掉也能重建。

想统计对象构成，用 git cat-file --batch-all-objects --batch-check='%(objecttype)' | sort | uniq -c，一眼就能看出这个仓库是 blob 多还是 tree 多。

排查大仓库#

git rev-list --objects --all \
  | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' \
  | sort -k3 -n | tail -10

这条会把每个对象的类型、哈希、大小和路径打出来，通常是某个历史版本里的大二进制文件。注意它只报告，不删除。清理历史要用 git filter-repo，而且必须先在副本上验证、通知所有协作者重新克隆——历史改写后，旧克隆推上来会把垃圾带回来。

结论#

• Git 对象就是「类型 + 长度 + 内容」做哈希，内容寻址决定了去重和不可变性。
• blob 不带文件名，目录结构全在 tree 里，权限也记在 tree 的 mode 上。
• commit 的哈希包含父提交，改历史必然改掉后续所有 id。
• 分支和 HEAD 只是文本引用，删分支不等于删数据，reflog 还能救。
• 排查仓库体积先用 rev-list --objects 排序，别直接 git gc 了事。

下面这套流程按上游连接、上游进程、worker 容量、文件描述符四层展开。顺序不能颠倒：先证伪最外层，再往里收。每一层都有对应的命令和日志关键字，跑完基本能收敛到一个具体参数，而不是靠猜。

现象：502 至少有四种写法#

同样返回 502，错误日志完全不同。先把它们归类，后面每一步才有方向。

第四类最容易被误判。它看起来像纯容量问题，实际常常是文件描述符先被打满：Nginx 既无法 accept 新连接，也无法向上游发起连接，于是两类错误交替出现，越重启越频繁。

顺带区分 502、504 与 499。502 是拿不到合法响应，504 是等太久超过 proxy_read_timeout，499 是客户端自己先断开、Nginx 记下的状态码。三者经常同时出现：上游变慢导致 504 增多，客户端等不及断开产生 499，连接被占满后新请求直接 502。看到这种组合，容量和超时才是主线，不必从 fd 查起。

定位：三条命令把问题归层#

先确认上游到底有没有在监听，再看 Nginx 自己的账本。在 Nginx 所在机器上执行：

# 上游是否在监听，本机能否直连
ss -lntp | grep ':8080'
curl -sv --max-time 3 http://127.0.0.1:8080/health 2>&1 | tail -20

# Nginx 的连接与 fd 账本
nginx -T | grep -E 'worker_connections|worker_rlimit_nofile|keepalive'
ss -s
cat /proc/$(cat /run/nginx.pid)/limits | grep -i 'open files'
ls /proc/$(cat /run/nginx.pid)/fd | wc -l

本机 curl 通、经 Nginx 不通，问题在 Nginx 到上游这一段；本机 curl 也不通，先修上游，别在 Nginx 上折腾。如果是容器环境，注意 127.0.0.1 指的是 Nginx 自己所在的网络命名空间，不是宿主机。

ss -s 第一行的 TCP: ... estab ..., timewait ... 很有信息量。timewait 数量持续上万，说明短连接太多，keepalive 大概率没生效；estab 接近 worker_connections × worker 数，说明连接槽快满了。这两个数字比 5xx 比例更早预警。

worker_connections 乘 worker 进程数只是理论上限，真正卡死你的往往是 worker_rlimit_nofile 和系统 ulimit -n。fd 使用率超过 80% 时，accept 与 connect 会同时失败，日志里两种错误交替出现。

还有一点常被漏算：proxy_next_upstream 默认在 error、timeout 时换节点重试。一次客户端请求可能占用两到三个上游连接，容量估算要按倍数放大。并发高时，把 proxy_next_upstream_tries 设成 2 比默认的无限重试安全得多。

要在测试环境复现「连上就断」，可以用一个收完连接立刻关闭的假上游：

# 终端 A：监听但不回任何数据，收到就断
while true; do nc -l -p 8080 -q 0 < /dev/null; done
# 终端 B：反复请求，观察 error.log 的签名
for i in $(seq 20); do curl -s -o /dev/null -w '%{http_code} ' http://127.0.0.1/; done

日志里出现 upstream prematurely closed connection，就说明问题在这一层，与 fd、容量无关。

根因：三个高频组合#

上游只监听回环地址。 容器化之后 upstream 写成 127.0.0.1:8080，应用却只监听容器 IP，或者反过来。特征是稳定复现的 502，换台机器就正常，和并发无关。ss -lntp 的输出能直接看到监听地址，0.0.0.0:8080 与 127.0.0.1:8080 是两回事。

keepalive 写了但没生效。 upstream 块里加了 keepalive 32，却漏了 proxy_http_version 1.1 和清空 Connection 头。每个请求仍然新建连接，TIME_WAIT 堆积，本地端口耗尽后 connect 直接失败。验证方法是在 Nginx 上 curl -v 请求两次，看第二次是否出现 Re-using existing connection；没有这行，就说明连接没复用。

fd 只增不减。 发版、日志切割、热加载后老 worker 没退出，或某模块打开文件不关闭。ls -l /proc/<pid>/fd | grep deleted 出现大量已删除仍被持有的文件，就是典型信号。

还有一种情况是「时好时坏」：上游的 accept 队列（backlog）太小，突发连接被内核直接丢弃，表现像随机丢包。ss -lnt 的 Send-Q 列就是 backlog，配合 netstat -s | grep -i listen 的溢出计数可以验证。

另有一种误判：所有节点因为连续失败被 max_fails 打满，健康检查窗口内 Nginx 直接返回 no live upstreams，而上游其实早已恢复。这时先看 fail_timeout，再决定要不要临时摘除标记。max_fails=0 会关闭被动健康检查，适合上游只有单点、否则容易误伤。

修复：按顺序改，别一次动五个参数#

配置改动建议自上而下：先抬 fd 上限，再抬连接数，最后才动超时和重试。一次改五个参数，出了问题说不清是哪一个起的作用。

# nginx.conf 全局段
worker_rlimit_nofile 65535;

events {
    worker_connections 16384;
    multi_accept on;
}

http {
    upstream app {
        server 10.0.0.11:8080 max_fails=3 fail_timeout=10s;
        server 10.0.0.12:8080 max_fails=3 fail_timeout=10s;
        keepalive 64;            # 空闲长连接池大小
        keepalive_timeout 60s;
    }

    server {
        location / {
            proxy_http_version 1.1;          # keepalive 的前提
            proxy_set_header Connection "";   # 清掉 close
            proxy_connect_timeout 2s;         # 快速失败，别让请求排队
            proxy_read_timeout 30s;
            proxy_next_upstream error timeout http_502;
            proxy_next_upstream_tries 2;      # 限制重试放大
        }
    }
}

一个常被忽略的关系：每个上游连接也要占一个 fd，Nginx 文档建议 worker_rlimit_nofile 至少设成 worker_connections 的两倍，否则配置里的连接数只是纸面数字。

proxy_connect_timeout 从默认 60 秒降到 2 秒是关键一步。上游半死不活时，长超时会把 worker 连接长期占住，健康节点也会被拖成 502。

系统层同步放开，否则 Nginx 配置再大也会被内核挡住：

# systemd unit 里加 LimitNOFILE=65535，或改 /etc/security/limits.conf
sysctl -w net.ipv4.ip_local_port_range="10240 65000"

改完 nginx -t && nginx -s reload，并确认旧 worker 在 worker_shutdown_timeout 内退出，而不是挂着继续占 fd。

防复发：让 502 可归因#

• 对 no live upstreams 和 worker_connections are not enough 单独告警，它们比 5xx 比例更早暴露容量问题。
• 采集 worker 的 fd 使用率，超过 70% 预警，而不是等 502 发生。
• 监控 ss -s 里的 TIME_WAIT 数量，持续偏高就回头查 keepalive。
• 健康检查探真实业务路径，别只探 /，否则上游依赖挂了仍然算健康。
• 发版后检查 ps -ef | grep 'nginx: worker'，确认旧进程全部回收。
• 把 $upstream_addr、$upstream_status、$upstream_response_time 写进访问日志，事后能直接定位到节点。

结论#

排查顺序应该是：读日志归类，验证上游监听，核对 worker 与 fd 容量，最后检查 keepalive 与重试放大。四步之内基本能收敛到一个具体参数，而不是靠重启碰运气。

可以直接落地的动作有四条：把 proxy_connect_timeout 降到秒级；配 keepalive 时同时配好 HTTP/1.1 与 Connection 头；把 fd 使用率纳入监控；把 upstream 三元组写进访问日志。

还要记住 502、504、499 是一组信号：同时上涨说明堵在容量或超时上，盯单一指标容易被误导。

一句话收尾：重启能缓解的 502，通常是容量或泄漏问题，重启只是把计时器归零。

这两个 bug 表面无关，根因是同一件事：Python 在什么时候对表达式求值，以及捕获的是值还是变量。两者的共同点是——代码看起来完全正常，review 时也很难靠肉眼发现。

现象：两个最小复现#

先看默认参数，再看闭包：

# 1) 默认参数：默认值在 def 执行时创建，只创建一次
def collect(item, bucket=[]):
    bucket.append(item)
    return bucket

print(collect("a"))   # ['a']
print(collect("b"))   # ['a', 'b']  ← 期望是 ['b']

# 2) 闭包：捕获变量，不是值
funcs = [lambda: i for i in range(3)]
print([f() for f in funcs])   # [2, 2, 2]，不是 [0, 1, 2]

bucket 没有在每次调用时新建，而是复用了函数对象上挂着的那个列表。进程活得越久，这个列表越大，还会持有元素引用，形成慢性内存增长。

三个 lambda 捕获的是同一个变量 i，循环结束后它已经是 2。函数定义得早，取值取得晚。

在 Web 框架里，默认参数问题会变成跨请求污染：视图函数签名写成 def index(filters={})，第一个请求写入的过滤条件会一直留在进程里，下一个请求直接带着它跑。单进程单请求测试很难复现，多 worker 也只是降低撞上的概率。

这两类 bug 还有个共同特征：单元测试如果每次只调用一次、或者只验证「不抛异常」，就永远测不出来。测试通过，线上照样串数据。

定位：把「隐藏的共享」打印出来#

默认参数挂在函数对象的 __defaults__ 上，闭包的自由变量则存在 cell 里，两处都能直接打印：

def collect(item, bucket=[]):
    bucket.append(item)
    return bucket

collect("a"); collect("b")
print(collect.__defaults__)          # (['a', 'b'],) 已经脏了
print(id(collect.__defaults__[0]))   # 多次调用 id 不变

funcs = [lambda: i for i in range(3)]
print(funcs[0].__closure__[0] is funcs[1].__closure__[0])   # True
print(funcs[0].__closure__[0].cell_contents)                # 2（循环结束后）

默认值对象被复用，所以 id 不变、内容在长；两个闭包指向同一个 cell，就证明它们共享变量而不是各自持有快照。

线上不方便打断点时，在可疑函数入口加一行 print(id(bucket), len(bucket))，连续两次调用 id 相同、长度递增，基本可以定性。要追内存增长，用 tracemalloc 对默认值对象前后各拍一次快照，看增长落在哪个分配点。

如果只是想先缩小范围，静态搜索比重读代码快：grep -rn "def .*= *\[\]"、= *{}、= *set() 三条命令，能把可疑函数列个七七八八。

根因：求值时机与捕获对象#

默认参数在 def 执行时求值一次。 函数是对象，默认值是它的属性，所有调用共享。写 def f(x, acc=[]) 相当于在模块加载时执行了一次 acc = []，然后每次调用都传同一个引用。注意这和「调用时传参」完全不同：传参是每次调用重新求值，默认值不是。

闭包捕获变量，不捕获值。 Python 的闭包按名字查找自由变量，最终落到一个 cell 上。循环里的 i 在函数作用域只有一个 cell，每轮只是给它赋新值，所以所有闭包看到的是最后一次赋值。

边界要说清。 默认值是不可变对象（int、str、tuple、None）时没有这个问题。可变对象只要从不修改也安全，但这是隐式约定，下一个人加一行 append 就会炸。用默认参数做 memo 缓存是合法模式，代价是要自己考虑线程安全和容量上限。

同类问题还有三个。 类属性 class A: cache = {} 被所有实例共享；dataclass 字段写 items: list = [] 会直接报错；except E as e 里的 e 在 Python 3 中出块即删除，闭包引用它会得到 NameError。

理解这层机制之后，判断标准很简单：这个对象在多次调用之间应不应该保持状态。不应该，就别让它出现在默认值里。

修复：哨兵、绑定、工厂#

默认参数用 None 哨兵，在函数体内创建：

from typing import Optional, List

def collect(item: str, bucket: Optional[List[str]] = None) -> List[str]:
    if bucket is None:          # 必须用 is None
        bucket = []
    bucket.append(item)
    return bucket

判断条件不能写 if not bucket。调用方传一个空列表进来时，not [] 为真，函数会新建列表，调用方拿到的仍是空列表，这个 bug 比原来更隐蔽。

闭包用「定义时绑定」：

# 方式一：默认参数把当前值绑进去
funcs = [lambda i=i: i for i in range(3)]

# 方式二：functools.partial，意图更清楚
from functools import partial

def tag(i: int) -> int:
    return i

funcs = [partial(tag, i) for i in range(3)]
print([f() for f in funcs])   # [0, 1, 2]

如果是做缓存，functools.lru_cache 比自己拿默认参数当字典更稳：它带淘汰策略、有 cache_info() 可观测，线程安全也是明确的。自己用 {} 当缓存，既没有上限也没有统计，出问题时连命中率都拿不到。

防复发#

• CI 里打开静态检查：flake8-bugbear 的 B006、pylint 的 W0102、ruff 的 B006，都能直接抓出可变默认值。
• 单测里连续调用两次，断言第二次结果不包含第一次的数据。这一条能拦住绝大多数跨请求污染。
• 类型标注统一写 Optional[X] = None，review 时一眼能看出是哨兵。
• 循环里创建函数、线程、协程并延后执行时，先问一句「它捕获的是哪个变量」。
• 需要绑定时优先用 functools.partial，比手写 i=i 更难被误读。
• 存量代码全仓扫一遍：grep -rn "def .*= *\[\]\|def .*= *{}"，把可疑签名列出来逐个确认。

结论#

默认参数的问题出在「定义时求值一次，所有调用共享」；闭包的问题出在「捕获变量而非值」。两者都不是语言缺陷，是求值模型的必然结果。

落地四条：可变默认值一律换成 None 哨兵并用 is None 判断；循环里创建闭包要么用默认参数绑定，要么用 partial；把 B006 和 W0102 加进 CI；单测至少调用两次。

再补一句判断标准：默认值适合放不可变常量，需要可变状态就交给显式参数或工厂函数。把这条写进团队规范，比事后排查便宜得多。

下次再遇到「数据串了」或者「回调全用了最后一个值」，先打印 __defaults__ 和 __closure__，比读十遍代码快。

这两个报错经常被混为一谈，处理方式却完全不同。前者是 InnoDB 主动挑了一个事务回滚，后者是某个事务一直等不到锁。先把它们分开，再谈修复。

现象：两个错误码，两套逻辑#

1213 通常能靠重试消化，但如果频率上升，说明并发路径的加锁顺序已经乱了。1205 更危险，它会把连接和线程一起占住，拖垮整个连接池。

被回滚的那个事务叫牺牲者（victim），InnoDB 一般选择修改行数较少、代价较小的一个。这意味着：重试必须安全。如果业务在事务里已经做了不可回滚的副作用（发消息、调第三方），死锁回滚之后数据就可能不一致。看到 1213，先确认这段逻辑是否幂等，再谈重试次数。

定位：把死锁现场读出来#

InnoDB 会把最近一次死锁留在内存里，直接翻出来；想把历史死锁都留下，再打开全局开关（会增加错误日志量，排障期临时开）：

SHOW ENGINE INNODB STATUS\G   -- 看 LATEST DETECTED DEADLOCK 段
SET GLOBAL innodb_print_all_deadlocks = ON;

-- 实时看谁在等谁（MySQL 8.0，需开启 performance_schema）
SELECT * FROM performance_schema.data_lock_waits\G
SELECT trx_id, trx_state, trx_started, trx_rows_locked, trx_query
FROM information_schema.innodb_trx ORDER BY trx_started;

这一段里有两个事务块，各自列出 HOLDS THE LOCK(S) 和 WAITING FOR THIS LOCK TO BE GRANTED，以及最后执行的 SQL。关键是看两边的 index 和 lock_mode：如果都在等同一张表的不同行，但加锁顺序相反，那就是典型的顺序死锁。

lock_mode 值得单独认一下：

• X locks rec but not gap：只锁记录本身，没有间隙锁，通常是唯一索引等值命中。
• X：记录锁加间隙锁，REPEATABLE READ 下范围条件常见。
• X locks gap before rec：只锁间隙，多出现在插入或范围扫描时。

两边都是 X 且 index 不同，说明同一批数据走了两条不同的索引路径，加锁顺序自然不一致。

trx_rows_locked 是个好指标：一个只更新几行的语句却锁了几万行，说明索引没走对，锁的范围被放大了。trx_started 很早而 trx_query 为空，通常是应用开了事务却没提交。

根因：死锁的四个必要条件加上三个常见触发#

死锁需要互斥、持有并等待、不可剥夺、循环等待同时成立。数据库能做的只是检测并回滚，真正的解法是打断循环等待。生产上常见三种触发方式。

加锁顺序不一致。 两个事务分别先锁 A 再锁 B、先锁 B 再锁 A。批量更新时尤其隐蔽：WHERE id IN (1,2) 看起来顺序固定，但优化器可能走不同索引，实际加锁顺序并不保证。

锁范围被放大。 更新条件没有索引，或者索引选择性太差，InnoDB 只能扫大量行并逐行加锁。在 REPEATABLE READ 下，范围扫描还会加 next-key lock 和间隙锁，连「不存在的行」都被锁住，插入操作也跟着排队。

唯一键与二级索引的顺序差异。 INSERT ... ON DUPLICATE KEY UPDATE 先加唯一索引的锁，再改聚簇索引；普通 UPDATE 若修改了二级索引列，加锁顺序又不一样。两条路径交叉时就会成环。

还有一种不算死锁但症状相似的：长事务不提交，锁一直不释放，别人等满 innodb_lock_wait_timeout 后报 1205。它和死锁的区别是没有人成环，只是持锁方太慢。

最小复现，两个会话交叉更新两行：

-- 会话 A
BEGIN; UPDATE account SET balance = balance - 10 WHERE id = 1;
-- 会话 B
BEGIN; UPDATE account SET balance = balance + 10 WHERE id = 2;
-- 会话 A（此时等待 B 持有的 id=2）
UPDATE account SET balance = balance + 10 WHERE id = 2;
-- 会话 B（触发死锁，一方被回滚）
UPDATE account SET balance = balance - 10 WHERE id = 1;

修复：先统一顺序，再缩短事务#

顺序问题用顺序解决。批量操作先按主键排序，把锁一次性按固定次序拿全：

BEGIN;
-- 先按主键升序锁定目标行，所有事务走同一顺序
SELECT id, balance FROM account
WHERE id IN (1, 2) ORDER BY id FOR UPDATE;

UPDATE account SET balance = balance - 10 WHERE id = 1;
UPDATE account SET balance = balance + 10 WHERE id = 2;
COMMIT;

配套动作：

1. 用 EXPLAIN 确认更新条件走了索引，rows 估算不应远超实际更新行数。
2. 事务里禁止 HTTP、RPC、消息发送，把外部调用挪到事务外。
3. 大事务拆小，单事务控制在百行级别，提交越早锁持有越短。
4. 死锁回滚是安全的，业务层对 1213 做有限重试；1205 不要盲目重试，先查持锁者。

重试要带退避和上限，避免雪崩：

import random, time

def run_with_retry(fn, attempts=3):
    for i in range(attempts):
        try:
            return fn()
        except DeadlockError:                 # 仅重试 1213
            if i == attempts - 1:
                raise
            time.sleep(0.05 * 2 ** i + random.random() * 0.01)

重试上限要和接口超时放在一起算：50ms、100ms、200ms 三次退避加起来不到 400ms，才不会把一次请求拖成几秒。退避时间写死成大常数，等于把死锁放大成超时。

防复发#

• 常开或按需开启 innodb_print_all_deadlocks，把死锁写进日志采集，别等用户投诉。
• 监控 SHOW GLOBAL STATUS LIKE 'Innodb_deadlocks' 的增速，突增就是加锁顺序变了的信号。
• 所有批量更新收敛到一个 DAO 方法，顺序由这一处保证，而不是每个调用方各自拼 SQL。
• 代码规范里写明「事务内不做外部调用」，用中间件或静态检查兜底。
• 压测时构造并发更新同一批行的场景，比读代码更容易复现死锁。
• 给死锁日志配一条检索规则，按表名和 SQL 指纹聚合，重复出现的模式优先治理。

结论#

1213 是检测到循环等待后的主动回滚，1205 是等待超时，两者要分开处理。定位的核心是 SHOW ENGINE INNODB STATUS 里的两个事务块，看谁持有什么锁、又在等什么锁。

修复优先级：统一加锁顺序，缩小锁范围（补索引、避免无索引更新），缩短事务，最后才是重试和降隔离级别。重试只对 1213 有意义，且必须限次数、带退避。

还有一条容易被忽略的前提：重试安全依赖幂等。事务里如果已经产生外部副作用，先把它挪出去，再加循环。

死锁不会消失，只会变少。目标不是零死锁，而是让每一次死锁都能在日志里被解释清楚。

控制台只有一行 Uncaught ChunkLoadError: Loading chunk 37 failed。更麻烦的是，错误监控里还原出来的源码位置在一段毫不相干的代码上——因为 Source Map 和线上 JS 不是同一次构建。三件事叠在一起，排查绕了远路。

现象：白屏的四种报错长相#

Unexpected token '<' 这条特别有指示性：说明请求的路径返回了 index.html，通常是路由回退把所有 404 都兜成了首页。

白屏的表现也不止一种：整页空白、只剩导航壳、某个区块一直转圈。整页空白多半是入口 chunk 失败，连框架都没起来；只剩壳说明主包加载成功，失败的是路由对应的异步 chunk。先分清是哪一种，能直接把范围缩到一个文件。

定位：先把 HTML 与静态资源的缓存策略分开看#

# 首页 HTML 的缓存头
curl -sI https://example.com/ | grep -iE 'cache-control|etag|age|last-modified'
# 带 hash 的静态资源
curl -sI https://example.com/assets/index.a1b2c3.js | grep -iE 'cache-control|etag'
# 旧版本 chunk 还在不在
curl -so /dev/null -w '%{http_code}\n' https://example.com/assets/old-hash.js

如果 HTML 带 max-age=600 且中间有 CDN，那么发版后十分钟内，一部分浏览器仍在用旧 HTML，里面引用的 chunk 名字已经被新版本删掉了。这就是「刷新就好、过一会儿又坏」的来源——不同边缘节点的缓存状态不一致。

判断响应到底是 JS 还是 HTML，看头比看内容快：URL 以 .js 结尾、响应却是 content-type: text/html，基本可以确认路由回退把 404 兜成了首页。再对照状态码，200 的 HTML 比 404 更麻烦，因为浏览器和 CDN 都会把它当正常资源缓存下来。

再确认 Source Map 是否与线上产物同源：

# 线上 JS 末尾一般有 sourceMappingURL 注释，指到哪个 hash 就是哪次构建
curl -s https://example.com/assets/index.a1b2c3.js | tail -c 200
# 本地构建产物的 map 文件名必须与线上 hash 完全一致
ls dist/assets/*.map | head

两者对不上，说明你手里的 map 是另一次构建的。用它还原堆栈，行列号会指向错误的源码位置，越查越偏。

一个低成本验证：直接让浏览器打开旧 HTML 里引用的 chunk URL。打不开就是 404，打得开但内容是一段 HTML，就是回退规则写错了。这两种情况的修法完全不同。

根因：三个版本同时在线上#

第一层：HTML 被缓存。 浏览器或 CDN 存了旧 index.html，它引用的 chunk 名属于上一版。新版本部署后旧 chunk 被删除，浏览器请求 404，动态导入失败，ChunkLoadError 抛出，页面停在白屏。

第二层：发布没有保留历史产物。 每次构建清空 dist 再上传，CDN 又做了目录同步删除。任何一个还持有旧 HTML 的客户端都会踩空。灰度期间两个版本并存时，这个问题会被放大。

第三层：Source Map 与 release 没有绑定。 构建产物的 hash 每次变，但 map 是按「最新一次构建」上传的。错误上报里只带了 release 字符串，没有带构建号；还原时用的是最新 map，位置自然对不上。

再加一个常见放大器：Service Worker 缓存了旧 index.html，且没有 skipWaiting。用户不关掉所有标签页，就永远拿不到新版本。

发布顺序也会制造这个窗口：先传静态资源、再刷 CDN、最后更新 HTML。顺序反了，就会出现新 HTML 指向尚未上传的 chunk，症状与缓存问题一模一样。

还有一种隐蔽情况：响应头里根本没写 Cache-Control。这时浏览器会做启发式缓存，用 Last-Modified 推算一个缓存时长，看起来「什么都没配」，实际 HTML 被缓存了几分钟到几小时不等。不配置不等于不缓存。

修复：让 HTML 不缓存，让产物可追溯#

缓存策略按资源类型分开设置，这是最有效的一刀：

# 入口 HTML：每次都回源校验
location = /index.html {
    add_header Cache-Control "no-cache, must-revalidate";
}

# 带 contenthash 的静态资源：永久缓存
location /assets/ {
    add_header Cache-Control "public, max-age=31536000, immutable";
    try_files $uri =404;   # 找不到就 404，别回退到 index.html
}

try_files ... =404 这一行值得单独说：SPA 的路由回退只应该作用于页面导航，不应该作用于 /assets/ 下的 JS。否则 chunk 缺失时浏览器会拿到 HTML，报出更难懂的 Unexpected token '<'。

发布侧保留最近两到三个版本的 chunk，或者让文件名带构建号、旧目录延迟清理。同时给动态导入加一次兜底刷新：

// chunk 加载失败时自动刷新一次，用时间戳防死循环
window.addEventListener('error', (e) => {
  const msg = String(e.message || '');
  if (!/ChunkLoadError|Loading chunk/.test(msg)) return;

  const key = 'chunk-reload-at';
  const last = Number(sessionStorage.getItem(key) || 0);
  if (Date.now() - last < 60_000) return;   // 一分钟内不重复刷新
  sessionStorage.setItem(key, String(Date.now()));
  location.reload();
}, true);

Source Map 侧用 hidden-source-map，构建后上传到错误监控平台并带上构建号，不放进公开目录。每次发布同时归档一份「构建号 — 产物 hash — map」的清单，出问题时按 release 精确匹配。

Service Worker 的更新要显式做三步：新版本 install 后 skipWaiting，activate 时清掉旧缓存，再 clients.claim。少做一步，用户可能几天都停在旧版本，而服务端已经找不到对应的 chunk。

防复发#

• 发布后用无头浏览器打开首页，断言关键 DOM 存在、控制台无 error，持续观察几分钟。
• 把构建号写进页面（如 <meta name="build">），错误上报时一起带上，避免「release 对、构建不对」。
• 监控按构建号分组，同一个构建号的 ChunkLoadError 突增就告警。
• 固定发布顺序：静态资源 → CDN 刷新 → HTML，并写进发布脚本，而不是靠人记。
• 灰度环境演练一次「删掉一个线上 chunk」，确认兜底刷新和降级页真的生效。
• Service Worker 更新策略写进 checklist：skipWaiting、clients.claim、旧缓存清理。
• 回滚时同样保留新版本产物，否则回滚会制造一次反向的「旧 HTML 找新 chunk」。
• 把 .map 的访问权限纳入安全扫描，别让构建产物把源码带到公网。

结论#

白屏先看报错类型：ChunkLoadError 是产物缺失，Unexpected token '<' 是路由把 404 兜成了 HTML，无报错则往 CSP 和入口脚本查。

根因往往是版本错配：旧 HTML 遇到新产物。修复的关键是三条——HTML 不缓存、/assets/ 不回退到首页、旧 chunk 保留若干版本。

Source Map 必须和构建号绑定，否则它会把排查带偏。最后加一层 ChunkLoadError 的有限次自动刷新兜底，让用户不必手动按 F5。

衡量是否做对了，看一个指标就够：发版后 ChunkLoadError 在错误监控里是否还按构建号聚集。如果还聚集，说明旧 HTML 仍在流通。

还有一种更迷惑的表现：容器跑了几个小时，突然停掉，退出码 143，日志里没有任何错误。这两种现象指向同一条链路——谁是 PID 1，以及它有没有正确处理信号。

现象：先读退出码#

docker stop 的流程是：向容器内 PID 1 发 SIGTERM，等 --time（默认 10 秒），还没退出就 SIGKILL。所以 143 和 137 的差别，往往就是「优雅退出有没有生效」。

还有一种退出码 0 但服务没起来的情况：容器显示 Running，健康检查却一直失败，编排层反复重启。这不是启动问题，是就绪判断缺失。日志里可能只有一句启动成功，实际业务端口并没有监听。

重启策略会把问题藏起来：restart: always 让容器反复退出又拉起，docker ps 里一直显示 Up，只有 docker inspect -f '{{.RestartCount}}' 的数字在涨。排查前先看这个计数。

定位：四条命令分清楚#

docker ps -a --format 'table {{.Names}}\t{{.Status}}\t{{.Command}}'
docker inspect -f 'exit={{.State.ExitCode}} oom={{.State.OOMKilled}} err={{.State.Error}}' <容器>
docker inspect -f '{{json .Config.Entrypoint}} {{json .Config.Cmd}}' <容器>
docker logs --tail 100 <容器>

OOMKilled=true 就把方向转到内存限制；err 非空通常是运行时层面的错误，比如挂载失败、权限问题；Config.Entrypoint 与 Config.Cmd 是数组还是字符串，直接暴露了 shell form 还是 exec form。

启动即退的，绕过 ENTRYPOINT 进容器手动跑一遍，能直接看到第一行报错：docker run --rm -it --entrypoint sh <镜像>。进不去说明镜像里没有 shell（比如 distroless），那就得靠日志和本地复现。

想看时间线，用 docker events --filter container=<容器名> 盯着，退出、重启、OOM 都会打点，比翻日志更直观。

要区分「启动即退」和「运行中退出」：前者几乎总是命令写错或依赖缺失；后者要看信号与 PID 1。判断方法是看日志有没有走到「服务已就绪」那一行。

日志停在 Starting 之后再无输出，说明主进程已经退到后台；日志完全为空但退出码是 0，说明 CMD 本身就是个前台跑完即结束的脚本，容器自然跟着退出。

根因：四种写法，一个信号问题#

命令后台化了。 CMD service nginx start 这类写法，启动脚本把服务 fork 到后台后自己退出，容器的主进程结束，容器随之停止。Docker 只关心 PID 1，不关心后台子进程。

shell form 让 sh 变成 PID 1。 CMD python app.py 实际执行的是 /bin/sh -c "python app.py"。多一层 shell，信号先到 sh，sh 未必转发给 python。应用收不到 SIGTERM，stop 只能等超时后强杀。

脚本末尾没有 exec。 常见于 entrypoint 脚本：先做迁移、改权限，最后 python app.py。此时 PID 1 仍是 bash，SIGTERM 打到 bash 上，bash 不转发，应用被 137 强杀。加一个 exec 就能让应用替换掉 shell，直接接管 PID 1。

PID 1 不回收僵尸进程。 内核不会给 PID 1 的孤儿进程自动找父进程回收。shell 脚本作为 PID 1 时，子进程退出后会留下僵尸，长跑容器里进程表会被慢慢占满。

再多说一句信号语义：Linux 内核对 PID 1 有特殊处理——没有注册处理函数的信号，默认动作会被忽略。所以在容器里，SIGTERM 发给 PID 1 时，如果 PID 1 没装处理器，它不会像普通进程那样直接死掉，而是被忽略，直到 SIGKILL。

下面是最小对照：

# 错误一：shell form + 后台启动，主进程立刻退出
CMD service nginx start

# 错误二：shell form，sh 是 PID 1，信号到不了应用
CMD python app.py

# 正确：exec form，应用直接成为 PID 1
CMD ["nginx", "-g", "daemon off;"]

entrypoint 脚本则统一这样收尾：

#!/bin/sh
set -euo pipefail

# 初始化：等依赖、跑迁移、修权限
/app/wait-for-db.sh

# 关键一行：用 exec 让应用替换当前 shell，成为 PID 1
exec "$@"

exec "$@" 依赖 CMD 传入参数，所以 ENTRYPOINT 用 exec form 时，CMD 也要用数组形式，两者配合才能把参数原样传下去。

修复：前台运行，信号可达#

1. 应用一律前台运行。nginx 加 daemon off;，gunicorn 不要加 -D，supervisor 类工具要么不用，要么只托管一个前台进程。
2. CMD / ENTRYPOINT 用 exec form（JSON 数组），避免 sh 包一层。
3. entrypoint 脚本最后一行必须是 exec "$@"。
4. 需要优雅退出时显式声明 STOPSIGNAL，例如 nginx 用 SIGQUIT。
5. 加 HEALTHCHECK，让编排层区分「进程还在」和「服务可用」。

FROM nginx:stable
COPY nginx.conf /etc/nginx/nginx.conf
STOPSIGNAL SIGQUIT
HEALTHCHECK --interval=10s --timeout=2s --retries=3 \
  CMD curl -fsS http://127.0.0.1/health || exit 1
CMD ["nginx", "-g", "daemon off;"]

不想改镜像的话，运行时加 --init 也能解决大半问题：Docker 会注入一个小型 init 作为 PID 1，由它转发信号并回收僵尸进程。代价是多一个进程，好处是脚本类入口不用逐个改造。

改完后验证一次信号链路：docker stop 应该让应用走完优雅退出，退出码是 143 而不是 137。如果容器里有长连接或正在处理的请求，观察日志里有没有「等待连接排空」这类记录。

如果 docker inspect 显示 OOMKilled=true，处理方向完全不同：先调内存限制，再排查泄漏，反复重启只会把问题变成周期性抖动。

防复发#

• CI 里加一步冒烟：docker run -d 后等 5 秒，用 docker inspect 断言容器仍在运行。
• 再断言 docker stop 后退出码为 143，说明 SIGTERM 被应用处理了，而不是超时强杀。
• Dockerfile review 检查清单：CMD 是否 exec form、是否前台、是否有 exec "$@"。
• 日志全部输出到 stdout/stderr，不写文件，否则容器退出后什么都看不到。
• 编排层设置合理的 terminationGracePeriodSeconds，与应用自身的优雅退出时限对齐。
• 用 ps -ef | grep defunct 抽查长跑容器，僵尸进程数量应该稳定在 0。

结论#

容器「启动即退」先看退出码：127 是命令找不到，0 是主进程结束得太早，1 是应用自己报错。运行中停掉则看 143 与 137 的差别。

九成的信号问题来自三件事：命令后台化、CMD 用了 shell form、entrypoint 脚本结尾忘了 exec。修法固定：前台运行、exec form、exec "$@"。

还需要理解一条内核语义：PID 1 没有默认信号动作。信号发了但没反应，不是 Docker 的问题，是容器里那个人没装处理器。

最后补一层验证——CI 里断言「起来后 5 秒还在跑」和「stop 后退出码 143」，比任何文档都可靠。

很多人背过「this 指向调用它的对象」，但这句话只对了一半。this 在函数被调用时确定，取决于调用点的形式，和函数写在哪里基本无关——箭头函数是唯一的例外。理解这一点，大部分「this 是 undefined」的报错都能当场解释。

现象：同一个函数，三种结果#

const user = {
  name: 'ada',
  greet() {
    return `hi ${this.name}`;
  },
};

console.log(user.greet());        // 'hi ada'
const g = user.greet;
console.log(g());                 // 非严格：'hi undefined'；严格/模块：TypeError

setTimeout(user.greet, 0);        // 回调里的 this 已不是 user

把方法取出来单独调用，就丢掉了「谁在调用」这条信息。事件监听、数组遍历、Promise 回调都是同一个道理。

事件监听是第二个高发场景：el.addEventListener('click', this.handleClick) 里，普通函数的 this 是那个 DOM 元素；数组遍历也一样，items.map(obj.format) 的 this 是 undefined。只要方法离开了「被哪个对象调用」的位置，this 就断了线索。

第三个场景是 class。把 counter.inc 解构出来赋值给变量、再作为回调传出去，this 就没了；报错信息通常是 Cannot read properties of undefined (reading 'count')，看起来像字段没初始化，实际是 this 不对。

Promise 链也常中招：promise.then(obj.handle)，then 只负责传值，不负责绑定接收者。需要 this 时写成 promise.then((v) => obj.handle(v))，行为才确定。

定位：先判断三件事#

第一，看调用形式：是 fn() 还是 obj.fn()？有没有经过 call、bind、new？

第二，看函数是不是箭头函数。箭头函数没有自己的 this，bind 也改不了它。

第三，看运行在严格模式还是模块里。ES Module 和 class 内部默认严格，此时默认绑定的 this 是 undefined，不是全局对象。

运行时可用的几个探针：

function probe() {
  console.log(this);                          // 先看实际值
  console.log(typeof this, this?.constructor?.name);
}
probe();                    // undefined（模块中）或 globalThis（脚本中）
probe.call({ a: 1 });       // { a: 1 }

如果 this 是 undefined，报错通常是 Cannot read properties of undefined；如果是全局对象，症状是不报错但读到 undefined 字段——后者更难查，因为代码不崩，只是数据不对。

在浏览器里更快的方式是断点：在可疑函数第一行下断点，看右侧 call stack 里的调用形式，obj.fn() 和 fn() 长得完全不一样。再配合 console.trace()，能直接看到是谁调用的。

顺带记一下顶层 this：模块顶层的 this 在 ESM 里是 undefined，在 CommonJS 里是 module.exports，在普通 script 里是 window。同一段代码换个加载方式，结果就变了。

根因：六种绑定与一条优先级#

优先级从高到低：new > bind > call/apply > 隐式 > 默认。一个直观的验证：

function Person(name) { this.name = name; }

const Bound = Person.bind({ name: 'bound' });
console.log(new Bound('ada').name);   // 'ada'，new 忽略了 bind 的 this

const arrow = () => this;
console.log(arrow.call({ a: 1 }) === this);   // true，箭头函数不认 call

new (() => {})();                     // TypeError: not a constructor

机制上可以这么理解：obj.fn() 在规范里叫「引用」，调用时会把 obj 作为 this 传入。一旦把这个引用赋给变量、作为参数传出去，引用就退化成普通值，this 的线索随之丢失。(obj.fn)() 因为括号不改变引用，仍然是隐式绑定；而 (0, obj.fn)() 经过逗号运算符，引用就没了。

严格模式是另一个变量。非严格模式下，默认绑定的 this 会被替换成全局对象，于是 this.name 读到 undefined 而不报错；严格模式下保持 undefined，调用 this.xxx 立即抛错。同一份代码在不同打包配置下表现不同，多半就是这个原因。

修复：四种写法，各有取舍#

const user = { name: 'ada', greet() { return `hi ${this.name}`; } };

// 1) bind：生成一个 this 固定的新函数
const bound = user.greet.bind(user);

// 2) 箭头包装：延迟到调用时再取 user.greet
setTimeout(() => user.greet(), 0);

// 3) 显式传入：适合工具函数
function greetWith(ctx) { return `hi ${ctx.name}`; }
greetWith(user);

// 4) class 字段箭头：实例方法自带 this，适合事件处理器
class Counter {
  count = 0;
  inc = () => { this.count += 1; return this.count; };
}
const c = new Counter();
const inc = c.inc;
inc();                       // 1，不再依赖调用点

取舍很清楚：bind 在构造函数里绑一次，开销小，但容易被忘记；class 字段箭头每个实例都创建一份函数，实例多时内存占用更高；箭头包装每次调用都新建闭包，适合回调但别放进热循环。

事件处理器用箭头函数最省事：el.addEventListener('click', () => this.handleClick())，this 来自定义处，与谁触发无关。反过来，如果确实需要触发元素，用普通函数配合 event.currentTarget，别依赖 this。

框架之间的差异也要记住：Vue 的 methods 会自动绑定到组件实例，React class 组件不会，必须自己 bind 或用箭头字段。跨框架迁移时，这类问题会成片出现。

还有一条现代替代：不再用 const self = this 这种写法，直接用箭头函数捕获外层 this，语义更清楚，也少一个变量。

call 与 apply 的区别只在传参：前者逐个传，后者传数组；bind 不执行函数，只返回一个新函数。临时借用一次用 call，需要长期固定 this 才用 bind。

防复发#

• ESLint 打开 no-invalid-this，能拦住把 this 用在普通函数里的写法。
• TypeScript 项目打开 @typescript-eslint/unbound-method，它会直接报「方法被解构后丢失 this」。这条规则依赖类型信息，配置成本略高，但收益最大。
• 单测里专门构造一次「把方法当回调传出去」的调用，断言不抛错。这一步比读代码有效。
• 事件监听、定时器、Promise 链是三个高发位置，review 时重点看这里是否直接传了 this.xxx。
• 公共方法如果需要被外部当回调使用，就在类里同时提供绑定好的箭头版本，别让调用方猜。
• 回调密集的模块（事件总线、定时任务、Promise 链）集中做一次 review，比逐处猜更有效。

结论#

this 由调用点决定：fn() 走默认绑定，obj.fn() 走隐式绑定，call/apply/bind 走显式绑定，new 走构造绑定，箭头函数则完全看外层作用域。

优先级记成一句话：new 最高，bind 次之，call/apply 再次，然后是隐式，最后是默认。

最常见的 bug 不是「this 指错了」，而是「方法被取出来当回调，隐式绑定丢了」。修法优先用箭头包装或 class 字段箭头，配合 unbound-method 这条 lint 规则，基本可以把它挡在上线之前。

最后提醒一句：this 是运行时概念，类型系统只能帮你到「这个方法可能被解构」这一层。真正兜底的，还是那句「谁在调用」——写回调时多问一遍，比事后调试省事。

箭头函数也不能当构造函数，没有 arguments，选它之前先确认这两点不影响使用场景。

问题不在 cron 有没有触发，而在它以什么环境触发。cron 启动的是一个非交互、非登录的 shell，你 ~/.bashrc 里那些 export PATH、conda activate、别名，它一概看不到。

现象：三种失败，三种原因#

第二种最坑：脚本里写 gzip > backup.gz，cron 的工作目录是家目录，文件其实生成了，只是不在你以为的地方。

容器里跑 cron 还有两个额外问题：多数基础镜像没有 syslog，日志必须自己重定向；镜像默认时区往往不是 UTC+8，0 3 * * * 实际会在本地时间上午十一点执行，而日志看起来完全正常。

还有一种「假成功」：任务跑了，退出码 0，但业务数据没变。常见于脚本里某条命令失败但没有 set -e，后面继续执行，最后正常退出。cron 只记「跑过了」，不记「跑对了」。

权限问题也常被忽略：用 root 的 crontab 跑本应属于业务用户的脚本，产物属主变成 root，后续普通用户读不到；反过来，普通用户的 crontab 访问不了 /root 下的密钥文件。

定位：把 cron 的真实环境导出来#

最直接的办法是让 cron 自己交代。临时加一行，一分钟内就能拿到：

# 每分钟把 cron 的环境落盘，观察完记得删掉
* * * * * env > /tmp/cron.env 2>&1; echo "PWD=$PWD" >> /tmp/cron.env
# 对比交互式登录 shell 的环境
diff <(sort /tmp/cron.env) <(env -i bash -lc 'env' | sort) | head -40

差异通常集中在 PATH、HOME、SHELL、LANG 这几项。看到 PATH=/usr/bin:/bin 就基本能确认：你的 node、python3、mysqldump 如果装在 /usr/local/bin 或用户目录下，cron 找不到。

再看 cron 自己的日志，确认有没有触发：

grep CRON /var/log/syslog | tail -20      # Debian / Ubuntu
journalctl -u cron --since '10 min ago'    # systemd 系统
tail -50 /var/log/cron                     # RHEL / CentOS
systemctl status cron                       # 或 crond
crontab -l

如果日志里根本没有这一行，先查服务状态和语法；如果行尾是 CMD (...)，说明命令已经交给 shell 了，问题在环境或脚本内部。

按这张清单逐项对照，一轮就能定位：

• PATH 是否包含脚本里用到的命令（which node、which mysqldump）
• 脚本是否显式 cd 到正确目录
• 输出是否重定向到了可写路径
• 容器时区是否与预期一致
• 上一次是否还没结束，导致本次被锁挡住

想要执行轨迹而不只是结果，把命令换成 /bin/bash -x /opt/scripts/x.sh，或者干脆在脚本里用 set -x 临时打开。cron 的日志只告诉你「执行了」，-x 才告诉你「执行到哪一步」。

根因：cron 用的是最小环境#

cron 执行任务时只注入很少的变量：SHELL 一般是 /bin/sh，PATH 通常是 /usr/bin:/bin，HOME 是用户家目录，LOGNAME 是用户名。它不会加载 .bashrc、.bash_profile、.profile。

由此引出四个连锁问题：

1. 版本管理工具装的可执行文件不在 PATH 里，node、npm、python 全部找不到。
2. 工作目录不是脚本所在目录，相对路径写到别处，或者直接因目录不存在而失败。
3. 时区取系统时区。容器里常是 UTC，你以为的凌晨三点其实是上午十一点。
4. 环境变量没有继承。数据库密码、代理设置、LANG 全部缺失，程序可能因编码问题报错。

还有三个纯配置坑。% 在 crontab 里有特殊含义，未转义时被当成换行符，命令从中间截断，而语法检查不会报错；文件用 Windows 编辑器保存、带 CRLF 换行时，每行末尾多一个 \r，命令变成 xxx.sh\r；/etc/cron.d 下的文件名带点通常会被忽略，配置放了却不生效。

命令没输出也别急着断定没跑。默认情况下 cron 会把输出通过邮件发给用户，机器上没配 MTA 时就直接丢弃。加一行 MAILTO="" 或者重定向到文件，才能留住现场。

修复：让脚本自带环境#

原则是：不依赖调用者的环境，脚本自己把 PATH、目录、日志、锁全部定死。

#!/usr/bin/env bash
set -euo pipefail

# 1) 显式 PATH，覆盖 cron 的最小环境
export PATH="/usr/local/bin:/usr/bin:/bin:/opt/app/bin"
export LANG="C.UTF-8"

# 2) 固定工作目录，相对路径才有意义
cd /opt/app

# 3) 所有输出进日志，不依赖邮件
exec >>/var/log/app-backup.log 2>&1
echo "[$(date -Is)] start"

# 4) 防重叠：上一次没跑完就跳过，并说明原因
flock -n /tmp/app-backup.lock -c '
  /usr/bin/mysqldump --defaults-file=/opt/app/my.cnf app \
    | gzip > /opt/app/backup/db-$(date +%F).sql.gz
' || echo "skip: previous run still active"

对应的 crontab 用绝对路径调用，并显式重定向。环境变量也可以写在文件顶部，Vixie cron 与 cronie 都支持：

# crontab 顶部声明环境
SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin
MAILTO=""

# 分 时 日 月 周  命令
30 2 * * *  /bin/bash /opt/scripts/app-backup.sh >> /var/log/app-backup.cron.log 2>&1

脚本里用 flock -n 而不是 flock -w，是为了让重叠的那一次直接跳过，而不是排队堆积。备份任务排队几次之后，往往就跑不完了。

调用时用绝对路径的解释器更稳：/bin/bash /opt/scripts/x.sh 不依赖 shebang 和执行位，挂载卷导致的权限丢失也不会让任务静默失败。

日志本身也要管：exec >> 追加写入的文件不会自动切割，跑一年就是几个 GB。用 logrotate 给它配一份规则，或者按月分文件，别等磁盘满了才发现。

密码不要直接写进脚本。mysqldump 用 --defaults-file 指向权限 600 的配置文件，比在命令行里写 -p密码 安全，也不会出现在 ps 的输出里。

防复发#

• 统一脚本模板：PATH、cd、日志重定向、flock、set -euo pipefail 五件套。
• 上线前用最小环境模拟一次：env -i /bin/sh -c '/opt/scripts/app-backup.sh'，能过再进 crontab。
• 加心跳：脚本成功结束前打一条日志或请求一个探针地址，监控没收到就说明没跑。
• 能换就换：systemd timer 支持 Environment=、WorkingDirectory=、OnCalendar=，日志进 journal，排查成本低得多。
• 容器场景显式设置 TZ，并在脚本里打印 date 用于核对时区。
• 把 crontab 纳入版本管理，别只在服务器上 crontab -e。

结论#

cron 不执行，先分清是「没触发」还是「触发了但失败」。看日志有没有记录，两分钟就能判断。

触发了但失败，九成是环境问题：PATH 只有 /usr/bin:/bin，工作目录是家目录，.bashrc 根本没被读取。让脚本自带 PATH 和 cd，把输出重定向到文件，问题就收敛了。

两个高频细节别忘：crontab 里的 % 必须转义成 \%；容器里先确认时区，否则任务会在错误的时间「成功」执行。

判断任务是否真的成功，别只看 exit code。加一条心跳上报，比翻日志可靠。

这种形态基本可以排除 Redis 本身：服务端很闲，是客户端借不到连接。要么池太小，要么借出去没还。

现象：三种表现指向同一处#

前两条最关键。connected_clients 是判断泄漏最直接的指标：正常应该跟着流量波动，泄漏则是一条只会往上爬的台阶。

还有一种没有报错的表现：延迟整体抬升、QPS 下降，日志干净。这往往是池已满、线程在排队，但等待超时设得足够长，所以还没抛异常。等到开始报错，说明排队已经严重到触及超时了。

池耗尽还常和线程池放大叠加：请求线程各自等连接，线程池被占满，健康检查、心跳这类本不需要 Redis 的请求也排不上队，服务看起来整体卡死。这时先看线程池活跃数，别只盯 Redis。

定位：先看服务端，再看应用侧#

# 客户端连接数与阻塞数
redis-cli info clients
# 拒绝连接统计：rejected_connections 增长说明服务端上限被打到
redis-cli info stats | grep -E 'rejected|total_connections'
# 每条连接的 addr / age / idle / cmd，重点找 idle 很大的
redis-cli client list | grep -oE 'addr=[^ ]+|age=[0-9]+|idle=[0-9]+|cmd=[^ ]+' \
  | paste -d' ' - - - - | head -20
# 应用侧粗看：ESTAB 数量应接近 实例数 × 池上限
ss -tn state established '( dport = :6379 )' | wc -l

client list 里重点看三列：age（连接存活秒数）、idle（空闲秒数）、cmd（最后一次命令）。大量 idle 数百秒、cmd 停在 client 或 ping 的连接，通常就是借出后没有归还的。如果这些连接的 addr 集中在同一小段端口范围，说明它们来自同一个池，而不是散落的客户端。

应用侧要看的还有连接池的 active、idle、等待线程数。没有这些指标时，用上面的 ESTAB 数量粗看：明显大于「实例数 × 池上限」，说明有代码绕过了池，直接建连。

线程卡在哪也要看：Java 用 jstack，Python 用 py-spy dump，找停在 borrowObject、get_connection、acquire 上的线程。数量等于池上限，基本就是池饥饿。

用最小代码复现泄漏，比读业务代码快：

import redis

pool = redis.ConnectionPool(host="127.0.0.1", port=6379,
                            max_connections=4, socket_timeout=1)

for i in range(10):
    conn = pool.get_connection("PING")     # 手动借出
    try:
        conn.send_command("SET", f"k{i}", "v")
        conn.read_response()
        if i == 2:
            raise RuntimeError("业务异常")   # 异常路径提前跳出
    finally:
        pass                                 # 忘了 pool.release(conn)

# 第 5 次开始抛 ConnectionError: Too many connections

把 pass 换成 pool.release(conn)，或者干脆用客户端封装，问题立刻消失。

根因：五条泄漏路径#

借还不成对。 手动 get_connection() 之后，正常路径归还了，异常路径、提前 return、continue 都漏掉了。这是最常见的一条。

每个请求新建客户端。 在函数里 redis.Redis(host=...)，每次调用都建一个连接池和一条连接，请求结束也不关。connected_clients 会跟 QPS 成正比，涨得飞快。

阻塞命令独占连接。 BLPOP、BRPOP、SUBSCRIBE 会一直占着连接不释放。如果它们从共享池里借连接，几个消费者就能把池吃光。

池上限小于真实并发。 池大小拍脑袋定成 10，实际并发 200，其余线程全在排队。加上等待超时设为无限，请求就堆在那里，表现为整体延迟上升而不是明确报错。

连接没有超时或健康检查。 网络设备静默断开空闲连接，池里留着死连接，借出来第一次用就失败，重试又去借同样的死连接。

还有一类隐蔽的：事务或管道开了没结束。MULTI 之后异常退出，连接上残留着未完成的事务状态，归还到池里继续被下一个请求借走，报错五花八门。这类问题在池里看不出来，只能靠统一封装避免。

池大小可以按这个公式估：并发 ≈ QPS × 平均持有时间(秒) × 1.5。算完再和 Redis 的 maxclients 对一遍，所有实例的池上限之和不要超过它的七成。

修复：统一入口，参数兜底#

先保证「借了一定还」，再谈池多大。

import redis

# 全进程一个池，参数按并发估算
pool = redis.ConnectionPool(
    host="10.0.0.5", port=6379,
    max_connections=64,          # 上限要小于 maxclients / 实例数
    socket_timeout=0.5,          # 单次命令超时，避免线程被拖死
    socket_connect_timeout=0.5,
    health_check_interval=30,    # 定期 PING，剔除死连接
    retry_on_timeout=False,      # 超时不要盲目重试，先确认幂等
)

client = redis.Redis(connection_pool=pool)

# 业务代码只用 client，由它负责归还
client.set("k", "v", ex=60)

确有需要手动借出时，用 try/finally 保证归还：

conn = pool.get_connection("PING")
try:
    conn.send_command("PING")
    conn.read_response()
finally:
    pool.release(conn)          # 异常路径同样会执行

再配三条约束：阻塞命令使用独立的小池，不占业务池；池的等待超时设成有限值（比如 200ms），借不到就快速失败并降级；服务端设置 timeout，主动踢掉长时间空闲的连接。

降级要提前设计。池满时返回缓存或默认值，比让请求挂两秒再失败体验更好，也能避免雪崩。关键是降级开关要有上限，别让所有请求都走降级。

Java 侧同理，Jedis 的 maxTotal、maxWaitMillis 与 testOnBorrow 要一起配；Lettuce 默认共享连接，模型不同，别把 Jedis 的经验直接套过去。

防复发#

• 埋点四项：池 active、idle、等待线程数、borrow 耗时。饱和率超过 80% 持续五分钟就告警。
• 对 connected_clients 做基线告警，偏离基线 30% 就查，不要等报错。
• 定期采样 CLIENT LIST 存档，出问题时能回溯是哪类连接在涨。
• 代码规范写死：业务代码只能通过统一封装的 client 访问 Redis，禁止裸调 get_connection。
• 压测时注入异常，专门验证 finally 分支和降级逻辑，而不是只跑正常路径。
• 把连接池上限写进部署配置的校验项：实例数 × 上限 < maxclients × 0.7，启动时检查一次。

结论#

连接池耗尽的表象是「借不到连接」，根因几乎都在「借了没还」或「根本没用池」。

定位顺序：先 INFO clients 看总量趋势，再 CLIENT LIST 看 idle 与 cmd，最后回到应用侧核对池指标和借还代码。

修复三件事：统一走客户端封装、异常路径用 try/finally 归还、池大小按 QPS × 持有时间 估算并设有限等待。最后加一条 connected_clients 的基线告警，泄漏就不会拖到用户感知才被发现。

还有一个反向教训：重启应用只是把泄漏的计时器归零。如果重启后曲线依旧阶梯上涨，问题没修，只是被延后了。

最后一条成本提醒：池上限不是越大越好。连接数远超 Redis 单线程的处理能力，只是把排队从客户端搬到服务端，延迟反而更高。

这类需求不需要引入 Celery 或 APScheduler。threading 加 heapq，八十行以内就能得到一个行为可预期的进程内调度器。前提是先想清楚它不负责什么。

先划清能力边界#

要解决的是四个具体问题：

• 触发间隔：30 秒、90 秒这类非整分钟周期，cron 表达不了。
• 重叠执行：上一轮跑了 3 分钟，下一轮又起来，两个线程写同一个临时文件。
• 失败处理：上游偶发 502，等到下个周期太久，立刻重试又会把对方打挂。
• 可观测：日志里要能看出是哪个任务、连续失败了几次。

如果只是「每天凌晨跑一次备份」，cron 配 flock 更省事。进程内调度器的价值在于秒级精度、能复用进程里的连接池和缓存，以及能直接读写内存状态。

顺带说一句为什么不用现成库。APScheduler 功能完整，代价是多一份依赖和一套配置心智；threading.Timer 每次触发都要重建对象，还会随任务数线性堆积线程。如果你的需求就是本文列的四条，自己写反而更容易读懂、更容易改。代码全部用标准库，粘贴到任何 Python 3.9 以上的环境都能跑。

用最小堆管理下一次触发时间#

堆顶永远是最早该执行的任务。每条记录带上 next_run（time.monotonic() 时间戳）和自增的 seq，后者用来打破同一时刻的平局。

这里有个必须知道的细节：dataclass(order=True) 会把所有字段拉进比较，而函数对象不能比大小。给 fn、name 加上 compare=False，否则注册第二个任务时就会抛 TypeError。

# scheduler.py —— 仅标准库，Python 3.9+
import heapq
import logging
import threading
import time
from dataclasses import dataclass, field

log = logging.getLogger("sched")

@dataclass(order=True)
class Job:
    next_run: float
    seq: int
    name: str = field(compare=False)
    interval: float = field(compare=False)
    fn: object = field(compare=False)
    running: bool = field(compare=False, default=False)
    failures: int = field(compare=False, default=0)

class Scheduler:
    def __init__(self, tick: float = 1.0):
        self._heap, self._seq = [], 0
        self._tick = tick
        self._stop = threading.Event()
        self._cv = threading.Condition()
        self._thread = threading.Thread(target=self._loop, name="sched", daemon=True)

    def every(self, seconds, name=None, catch_up=False):
        """注册固定间隔任务；catch_up=True 表示启动后先立刻跑一次。"""
        def register(fn):
            with self._cv:
                self._seq += 1
                first = time.monotonic() + (0.0 if catch_up else float(seconds))
                heapq.heappush(self._heap,
                               Job(first, self._seq, name or fn.__name__, float(seconds), fn))
                self._cv.notify()
            return fn
        return register

注册只做两件事：算出首次触发时间，塞进堆并唤醒正在等待的循环。用 Condition 而不是 time.sleep 轮询，新任务注册后能立刻被感知。

调度循环：三个判断缺一不可#

# 片段：以下方法接在 Scheduler 类内部
    def _loop(self):
        while True:
            with self._cv:
                if self._stop.is_set():
                    return
                if not self._heap:
                    self._cv.wait(self._tick)
                    continue
                job = self._heap[0]
                wait = job.next_run - time.monotonic()
                if wait > 0:
                    self._cv.wait(min(wait, self._tick))  # 有新任务注册会被提前唤醒
                    continue
                heapq.heappop(self._heap)
                if job.running:  # 上一轮没跑完：跳过本次，不排队
                    job.next_run = time.monotonic() + job.interval
                    heapq.heappush(self._heap, job)
                    continue
                job.running = True
            threading.Thread(target=self._run, args=(job,), daemon=True).start()

    def start(self):
        self._thread.start()

这三个判断分别对应三类故障：

1. 等待要有上限。wait(min(wait, tick)) 里的 tick 是兜底，防止堆顶任务在很远的将来时，注册新任务也无法及时生效；notify() 负责让新注册立刻打断等待。
2. 运行中直接跳过。不排队是刻意的：如果任务稳定慢于周期，排队只会把内存和时间差一起堆爆，日志里全是过期执行。
3. 执行必须离开锁。_loop 只负责派发，真正的函数体放到新线程里跑，否则一个慢任务会把整个调度循环按住。

派发之后的执行体是这样收尾的：

# 片段：以下方法同样接在 Scheduler 类内部
    def _run(self, job):
        started = time.monotonic()
        try:
            job.fn()
            job.failures = 0
        except Exception:
            job.failures += 1
            log.exception("job %s failed (attempt %d)", job.name, job.failures)
        finally:
            # 失败退避：间隔 × 2^n，封顶 8 倍；成功后退回原间隔
            delay = job.interval * min(2 ** job.failures, 8)
            job.running = False
            with self._cv:
                job.next_run = max(started + delay, time.monotonic())
                heapq.heappush(self._heap, job)
                self._cv.notify()

    def stop(self, timeout: float = 10.0):
        self._stop.set()
        with self._cv:
            self._cv.notify_all()
        self._thread.join(timeout)

三个判断之后是清理工作。无论成功还是异常，finally 都要把任务重新压回堆里，否则这个任务从此消失；running=False 也要在这里复位，不然下一轮会被永久跳过。

退避公式是 interval × 2^failures，最长 8 倍。它适合「上游短时间不可用」，不适合「必须准点」的场景——后者应该让任务失败并告警，而不是悄悄推迟。这套策略的代价是延迟不可控：连续失败三次后，一次重试可能排到 40 秒开外，用之前先确认业务能接受。

跑起来#

if __name__ == "__main__":
    logging.basicConfig(level=logging.INFO,
                        format="%(asctime)s %(levelname)s %(message)s")
    sched = Scheduler(tick=0.2)

    @sched.every(5, name="sync-ledger", catch_up=True)
    def sync_ledger():
        log.info("pull ledger ...")

    sched.start()
    try:
        time.sleep(30)
    finally:
        sched.stop()

启动后会立刻补跑一次，之后每 5 秒触发。catch_up=True 的语义仅仅是「进程起来先跑一次」，不是把停机期间漏掉的周期全部补上——这一点容易被误解。

调试时建议再加一行观测：记录 actual_start - job.next_run 的差值，也就是实际开始时间比计划晚了多少。这个值持续偏大，说明线程池已被占满或者锁竞争严重；偶尔尖刺则属于正常的 GC 和调度抖动。tick 决定了精度上限，默认 1 秒，要做到亚秒级就把它调小，代价是空转次数变多。

上线前还得补三件事#

进程内调度器最大的风险不在代码，在部署形态。

• 多副本：三台机器就是三份执行。用 Redis SET key val NX EX ttl 或数据库行锁，锁的 TTL 要大于单次执行时间，否则锁过期后仍会并发。
• 卡死：Python 线程杀不掉。给任务加「开始时间 + 心跳」，超时就告警；真正的硬超时只能把任务丢进子进程。

• 重启丢失：堆在内存里，重启即清空。要精确补偿，得把 last_run 落库，启动时按「漏了几个周期」决定补几次。

• 重活别放进线程：这里的并发模型是「一个任务一个线程」，适合 IO 等待。真要做视频转码、大批量计算，线程会被 GIL 串行化，应该把任务提交给进程池，调度器只负责按时投递。

还有个容易忽略的坑：不要用 time.time() 做调度。NTP 回拨几分钟，调度器就会静默停摆同样长的时间；monotonic() 单调递增，只适合测量间隔，不能直接当墙钟时间写日志。

结论#

• 用 heapq + Condition + 守护线程，80 行足够覆盖秒级周期的进程内调度。
• dataclass(order=True) 里的函数字段必须 compare=False，这是最先撞上的坑。
• 重叠执行选择「跳过」而不是「排队」，失败选择「指数退避」而不是「立即重试」。
• 调度器不解决多副本去重和持久化，这两件事要在部署层补。
• 用 monotonic() 计算间隔，用 time.time() 打日志，两者不要混用。

更糟的是日志：每个失败都打了三条 error，值班同学第一反应是「上游挂了」，实际上是我们自己把对方压垮的。后来我们把重试逻辑收进一个客户端，明确「等多久、试几次、什么时候放弃」，这类事故再没出现过。

重试本身不难，难的是「重试几次、等多久、哪些请求能重试、总时长怎么收口」。下面这版客户端只用标准库，四个问题都给出了默认答案。

先判断：这个请求值得重试吗#

三条规则，按优先级排：

1. 只重试幂等请求。GET、HEAD、PUT、DELETE、OPTIONS 重复发送不会产生额外副作用；POST 会，默认只发一次。如果上游支持幂等键，可以带上 Idempotency-Key 再放开。
2. 只重试可恢复的状态码。408（请求超时）、425（过早）、429（限流）、500、502、503、504 值得再试；400、401、403、404、422 是请求本身有问题，重试一百次结果一样。
3. 只重试传输层失败。连接被拒、连接重置、读超时、TLS 握手失败，这些都能重试。DNS 解析失败通常也可以，但要先确认不是域名打错了。

判断顺序建议从右往左：先看总预算还剩多少，再看状态码是否可恢复，最后才看方法是否幂等。反过来做，很容易在一个已经超时的请求上继续排队等待。

退避：为什么要加抖动#

固定间隔（比如每次等 1 秒）最糟：所有客户端会在同一时刻再次齐射，把刚缓过来的服务再打趴。指数退避把间隔拉长，全抖动（full jitter）再把时间打散到 [0, cap] 区间内。

公式是 random.uniform(0, min(cap, base × 2^attempt))。第 0 次失败最多等 0.5 秒，第 1 次 1 秒，第 2 次 2 秒，封顶 8 秒。看起来比「等满 2 秒」激进，但期望值更小，整体恢复更快，这是 AWS 架构博客里推荐的默认策略。

顺便算一下重试的收益。假设单次失败率是 1%，独立重试 3 次全部失败的概率约为 0.01³ = 10⁻⁶；但如果是持续性故障（实例整个挂了），单次失败率就是 100%，重试几次都是 100%。所以重试只对「偶发、独立」的失败有效，对容量问题无效，后者要靠限流和扩容。

# retry_client.py —— 仅标准库，Python 3.9+
import http.client
import random
import socket
import ssl
import time
import urllib.error
import urllib.request

RETRY_STATUS = {408, 425, 429, 500, 502, 503, 504}
IDEMPOTENT = {"GET", "HEAD", "PUT", "DELETE", "OPTIONS"}

class RetryExhausted(RuntimeError):
    def __init__(self, url, attempts, last):
        super().__init__(f"{url} 重试 {attempts} 次仍失败: {last!r}")
        self.last = last

def backoff(attempt, base=0.5, cap=8.0):
    """全抖动指数退避：第 n 次最多等 min(cap, base*2^n) 秒。"""
    return random.uniform(0, min(cap, base * 2 ** attempt))

def retry_after(value, fallback):
    """只解析秒数；HTTP-date 形式退回退避值，宁可保守也不乱等。"""
    if not value:
        return fallback
    try:
        return max(0.0, float(value.strip()))
    except ValueError:
        return fallback

主循环：用总预算收口#

def request(url, *, method="GET", data=None, headers=None, timeout=5.0,
            attempts=4, budget=20.0, retry_non_idempotent=False):
    method = method.upper()
    if method not in IDEMPOTENT and not retry_non_idempotent:
        attempts = 1                       # 非幂等请求默认只发一次
    headers = dict(headers or {})
    started, last = time.monotonic(), None

    for attempt in range(attempts):
        remain = budget - (time.monotonic() - started)
        if remain <= 0:
            raise RetryExhausted(url, attempt, last)
        req = urllib.request.Request(url, data=data, method=method, headers=headers)
        try:
            with urllib.request.urlopen(req, timeout=min(timeout, remain)) as resp:
                return resp.status, dict(resp.headers), resp.read()
        except urllib.error.HTTPError as e:
            body = e.read()                # 必须读完，连接才能回收
            last = e
            if e.code not in RETRY_STATUS or attempt == attempts - 1:
                return e.code, dict(e.headers), body
            wait = retry_after(e.headers.get("Retry-After"), backoff(attempt))
        except (urllib.error.URLError, socket.timeout, ConnectionError,
                ssl.SSLError, http.client.HTTPException) as e:
            last = e
            wait = backoff(attempt)
        remain = budget - (time.monotonic() - started)
        if remain <= 0:
            break
        time.sleep(max(0.05, min(wait, remain)))   # 至少让出 50ms，避免空转
    raise RetryExhausted(url, attempts, last)

几个刻意的选择：

• timeout=min(timeout, remain)。单次超时不能超过剩余预算，否则一次卡死会吃掉全部重试机会。
• Retry-After 优先。服务端说 30 秒就等 30 秒，仍然受预算约束；解析失败才退回退避值。
• 4xx 直接返回不抛异常。调用方需要读 401 的错误体和 429 的限流头，包成异常反而碍事。
• e.read() 不能省。HTTPError 的响应体不读完，底层连接不会释放。

验证：起一个坏两次的本地服务#

import threading
from http.server import BaseHTTPRequestHandler, HTTPServer

hits = {"n": 0}

class Flaky(BaseHTTPRequestHandler):
    def do_GET(self):
        hits["n"] += 1
        code = 503 if hits["n"] < 3 else 200       # 前两次失败，第三次成功
        self.send_response(code)
        self.send_header("Retry-After", "0.2")
        self.send_header("Content-Length", "2")
        self.end_headers()
        self.wfile.write(b"ok" if code == 200 else b"no")

    def log_message(self, *args):
        pass

srv = HTTPServer(("127.0.0.1", 0), Flaky)
threading.Thread(target=srv.serve_forever, daemon=True).start()
url = f"http://127.0.0.1:{srv.server_port}/health"
print(request(url, attempts=4, budget=10.0))
srv.shutdown()

跑出来是 (200, {...}, b'ok')，总耗时约 0.4 秒——两次 Retry-After: 0.2 的结果。把 Retry-After 改成 30，预算 10 秒会直接抛 RetryExhausted，这比干等 30 秒再失败更符合调用方的预期。

这个本地服务值得留在测试里。它能在不依赖外网的情况下覆盖三条关键路径：可恢复的 5xx、Retry-After 生效、预算耗尽。把失败次数改成 10，再断言 hits["n"] == attempts，就能确认重试次数没有失控。

生产环境还要考虑什么#

• 重试放大。客户端重试 3 次、网关重试 3 次、服务内部再重试 3 次，一次请求会变成 27 次。只在一层做重试，其他层快速失败。
• 熔断。连续失败超过阈值就停止请求一段时间，否则退避只是把雪崩拉长。重试解决「偶发」，熔断解决「持续故障」。
• 可观测。至少记录 url、attempt、status、wait、total。只统计最终成功率会掩盖重试风暴。
• 不要重试到超时上限。上游 SLA 是 2 秒，你的预算是 20 秒，重试成功也晚了。预算应该由调用方的 deadline 反推。
• 请求体要可重放。data 是 bytes 才能重发；如果传的是文件流，第二次发送时指针已在末尾，会发出空 body。
• 区分错误类型再决定告警。RetryExhausted 里的 last 保留了最后一次异常，据此区分「全是 5xx」「全是超时」「混合」，排障时能少走很多弯路。
• 别把重试写进业务代码。同一个项目里出现五套重试参数是常态，最后没人说清哪个请求被放大了几次。统一收口到客户端，参数按接口配置。

结论#

• 幂等性决定能不能重试，状态码决定值不值得重试，超时预算决定允许重试多久。
• 退避用全抖动指数，base=0.5s、cap=8s 是个稳妥起点。
• Retry-After 优先于自己的退避算法，但仍要受总预算约束。
• 4xx 不重试（429 除外），连接层错误才值得重连。
• 一次请求只能在一层重试，多层叠加会把故障放大成风暴。
• 重试是给偶发失败留的余量，不是给容量不足兜底；持续故障要靠限流、扩容和熔断。

临时 rm 掉它，df 却没有任何变化。原因是进程还持有这个文件的句柄，inode 没释放。这件事之后，我把清理做成了一个每分钟可以放心跑的脚本。

先定策略，再写命令#

按文件年龄分三段处理，不要用文件名里的日期——文件名是应用写的，不可信；mtime 才是文件系统的事实。三段的比例可以按业务调，但顺序不能反：先压缩再删除，能保证删掉的每一份都还有一份压缩副本可供回溯。

find -mtime +N 的边界要心里有数：它按 24 小时取整，+3 实际匹配 4 天以上的文件。合规场景别依赖这个精度，用 -newermt 或专门的归档任务。

压缩工具用 gzip，因为它几乎每台机器都有。如果发行版自带 zstd，同样的文本日志压缩率相当、速度能快好几倍，把脚本里的 gzip -9 换成 zstd -10 --rm 即可；代价是排查时要多记一个解压命令。压缩级别也别迷信 -9：对已经接近熵上限的日志，-9 相比 -6 只多省几个百分点，CPU 却要多花一倍。

脚本主体#

#!/usr/bin/env bash
set -euo pipefail

LOG_DIR="${LOG_DIR:-/var/log/app}"
KEEP_DAYS="${KEEP_DAYS:-3}"        # 超过几天开始压缩
DELETE_DAYS="${DELETE_DAYS:-30}"   # 超过几天直接删除
PATTERN="${PATTERN:-*.log}"
DRY_RUN="${DRY_RUN:-0}"
LOCK_FILE="${LOCK_FILE:-/tmp/log-cleanup.lock}"

[ -d "$LOG_DIR" ] || { echo "目录不存在: $LOG_DIR" >&2; exit 2; }
[[ "$KEEP_DAYS" =~ ^[0-9]+$ && "$DELETE_DAYS" =~ ^[0-9]+$ ]] \
  || { echo "KEEP_DAYS / DELETE_DAYS 必须是整数" >&2; exit 2; }
(( KEEP_DAYS < DELETE_DAYS )) \
  || { echo "KEEP_DAYS 必须小于 DELETE_DAYS" >&2; exit 2; }

# 同一时间只跑一个实例；没有 flock 的环境退化为目录锁
if command -v flock >/dev/null 2>&1; then
  exec 9>"$LOCK_FILE"
  flock -n 9 || { echo "已有实例在运行" >&2; exit 0; }
else
  LOCK_DIR="$LOCK_FILE.d"
  mkdir "$LOCK_DIR" 2>/dev/null || { echo "已有实例在运行" >&2; exit 0; }
  trap 'rmdir "$LOCK_DIR" 2>/dev/null || true' EXIT
fi

run() { if [ "$DRY_RUN" = "1" ]; then echo "[dry-run] $*"; else "$@"; fi; }

锁这一段不是装饰。清理任务被 cron 每分钟拉起一次，压缩一个 2GB 文件可能要几十秒，没有锁就会同时出现多个 gzip 抢同一个文件，轻则报错，重则留下 xxx.log.gz.gz。set -e 在这里也有副作用：gzip 失败会让整个脚本退出，后面的删除一个都不做——这是对的，宁可少清理，也不要带着未知状态继续删。

压缩与删除#

before=$(du -sm "$LOG_DIR" | cut -f1)

# 1) 压缩：够老但还没到删除线，且跳过已压缩文件
while IFS= read -r -d '' f; do
  run nice -n 10 gzip -9 -- "$f"
done < <(find "$LOG_DIR" -xdev -type f -name "$PATTERN" \
           -mtime +"$KEEP_DAYS" -mtime -"$DELETE_DAYS" \
           ! -name '*.gz' ! -name 'audit*' -print0)

# 2) 删除：超过删除线，含 .gz
while IFS= read -r -d '' f; do
  run rm -f -- "$f"
done < <(find "$LOG_DIR" -xdev -type f \
           \( -name "$PATTERN" -o -name "$PATTERN.gz" \) \
           ! -name 'audit*' -mtime +"$DELETE_DAYS" -print0)

after=$(du -sm "$LOG_DIR" | cut -f1)
echo "清理完成: ${before}MB -> ${after}MB"

三处细节值得单独说：

• -print0 + read -d ''。日志文件名里带空格、中文、甚至换行都不罕见。用 $(find ...) 接 for 会在空格处断词，直接删错文件。
• -xdev。不跨越挂载点。/var/log 上如果挂了独立分区或网络盘，少了这个参数可能一路走进别的文件系统。
• nice -n 10。压缩是 CPU 密集操作，降优先级避免和业务抢核。IO 压力大时还可以套 ionice -c2 -n7。

-- 也不能省。文件名以 - 开头时，gzip -9 -- -foo.log 才不会把文件名当成选项。

先在 dry-run 里看一遍#

脚本里所有写操作都走 run()，DRY_RUN=1 时只打印命令。上线前拿一个临时目录跑一遍：

mkdir -p /tmp/logtest && cd /tmp/logtest
echo keep > current.log
echo old > old.log
echo space > "with space.log"
echo gone > ancient.log
touch -d '5 days ago' old.log "with space.log"
touch -d '40 days ago' ancient.log

LOG_DIR=/tmp/logtest LOCK_FILE=/tmp/logtest.lock DRY_RUN=1 ./cleanup.sh

预期输出只有两条 gzip 和一条 rm：old.log、with space.log 被压缩，ancient.log 被删除，current.log 不动。确认无误后把 DRY_RUN 换成 0 再跑一次，检查目录里是不是多了 .gz、少了 .log。

这一步值得自动化。它同时验证了空值保护、空格文件名、年龄判断三条路径，比在生产上「小心一点」可靠得多。

rm 之后空间不释放，怎么办#

这是清理日志最常见的认知错误：删掉文件不等于释放磁盘。只要还有进程持有该文件的 fd，inode 和 block 就一直在。

三种处理方式：

1. 清空而不是删除：: > /var/log/app/current.log。文件还在，fd 继续有效，空间立即释放。适合正在写的单个大文件。
2. 让进程重开文件：kill -HUP（前提是应用实现了 reopen），配合 logrotate 的 create 模式。
3. 删完再检查：lsof +L1 能列出所有「已删除但仍被占用」的文件。发现大块空间挂在某个进程上，先重启它，或者按第 1 条清空。

具体排查时，lsof +L1 | sort -k7 -n | tail -20 按文件大小排序，能直接看到哪个进程占着几个 GB 的「幽灵文件」。df -h 和 du -sh 对不上账时，先跑这一条，基本都能定位到。

所以脚本只处理「够老」的文件：-mtime +3 天然排除了正在写的日志。真要清理当天的超大日志，应该用清空，而不是删除。

跑在什么节奏上#

• 频率：每 5–10 分钟一次足够，*/5 * * * *。不要 @daily 攒到凌晨一次干完，那会在业务低峰制造一个 IO 尖峰。
• 限速：单次处理文件数设上限（head -z -n 200），剩下的下一轮继续。
• 观测：脚本自身要输出处理了多少个文件、释放了多少 MB。没有输出的清理脚本，出问题时你无法判断它到底跑没跑。
• 权限：别用 root 跑。给专用用户对日志目录的写权限，set -u 兜住空变量，避免 rm -rf "$LOG_DIR" 变成 rm -rf /。

对应的 crontab 大致是这样，注意用绝对路径，cron 的 PATH 和你登录时不一样：

*/5 * * * * LOG_DIR=/var/log/app /opt/ops/log-cleanup.sh >> /var/log/app/.cleanup.log 2>&1

把脚本自己的输出也写进日志目录，等于给自己埋了一个自监控点：清理任务失败时，.cleanup.log 里会留下 set -e 触发的那条错误。

• 压缩后抽检：gzip -t 能验证压缩包完整性。对大文件做一次抽检，比事后发现 30 天前的日志解不开要强。

结论#

• 用 mtime 分段（压缩线 / 删除线），别信文件名里的日期。
• 文件名用 -print0 传递，-- 结束选项，-xdev 限制范围。
• 正在写的日志用清空（: > file），不要 rm，否则空间不释放。
• 加锁、加 dry-run、加数值校验，让脚本可以被安全地重复执行。
• 清理频率高于一次清空，避免制造 IO 尖峰，同时保留可观测的输出。
• 上线前先用 DRY_RUN=1 在临时目录走一遍，别在生产上做第一次试运行。

问题几乎不在监听器数量，而在「每帧都触发一次布局计算，再改一个会触发重排的属性」。把这两件事换掉，代码反而更短。

先说明适用范围：下面这套适合「整页滚动」的长文页。如果你的正文在某个 overflow: auto 的区域里，或者用的是虚拟滚动，逻辑要换——文末会提。

先算清楚进度#

公式只有一行：

ratio = scrollTop / (scrollHeight - clientHeight)

三个数都从滚动容器上取。文档滚动时容器是 document.scrollingElement，它比 document.documentElement 可靠——后者在 quirks 模式下是 <body>。

这个除法有四个边界，线上都会遇到：

• 内容比视口还短：分母为 0，得到 NaN 或 Infinity，scaleX(NaN) 会让进度条直接消失。
• iOS 橡皮筋回弹：scrollTop 会变成负数，进度条反向溢出。
• 移动端地址栏伸缩：clientHeight 变了，但没有 scroll 事件，进度停在旧值。
• 锚点跳转和浏览器前进后退：pageshow 恢复页面时不会触发 scroll。

对应的处理是 Math.min(1, Math.max(0, ...)) 夹紧，分母为 0 时返回 0，再监听 resize、pageshow 和 ResizeObserver。

还有一个容易被忽略的量：scrollHeight 包含内边距但不含边框和外边距，而 clientHeight 包含内边距、不含滚动条。所以分母是「可滚动的高度」，不是「内容总高度」。如果你在容器上加了 border: 1px，算出来的最大值会多出两像素，进度永远差一点点到 100%。这类误差肉眼看不出来，但会让「读完自动标记」之类的逻辑永远不触发。

20 行实现#

// scroll-progress.js —— 无依赖，现代浏览器
const bar = document.getElementById('progress-bar');
let queued = false;
let lastRatio = -1;

function update() {
  queued = false;
  const el = document.scrollingElement || document.documentElement;
  const max = el.scrollHeight - el.clientHeight;
  const ratio = max > 0 ? Math.min(1, Math.max(0, el.scrollTop / max)) : 0;
  if (ratio === lastRatio) return;          // 没变化就不碰 DOM
  lastRatio = ratio;
  bar.style.transform = `scaleX(${ratio})`;
  bar.setAttribute('aria-valuenow', String(Math.round(ratio * 100)));
}

function schedule() {
  if (queued) return;                       // 一帧只更新一次
  queued = true;
  requestAnimationFrame(update);
}

addEventListener('scroll', schedule, { passive: true });
addEventListener('resize', schedule, { passive: true });
addEventListener('pageshow', schedule);
new ResizeObserver(schedule).observe(document.body);

schedule();

三个细节撑起了「丝滑」：

1. requestAnimationFrame 合并。滚动事件在一帧内可以触发多次（触控板、高刷屏更明显）。用 queued 标记把这一帧的所有事件折叠成一次 DOM 写入，渲染前只算一次。
2. passive: true。告诉浏览器这个监听器不会调用 preventDefault()，滚动线程不必等 JS 执行完再合成画面。少这一行，移动端的滚动手感会明显变「粘」。
3. lastRatio 去重。滚到顶部或底部后，后续事件算出的比例不变，直接返回，省掉无意义的样式写入。

queued 这个布尔量看起来多余，其实关键：requestAnimationFrame 本身不合并，连续调用会在一帧后执行多次。用「已排队」标记保证一帧只有一次回调，剩下的滚动事件全部丢弃——反正这一帧的最终位置就是最后一个事件的位置。

最后一行 schedule() 不是可选项。页面从缓存或前进后退恢复时，可能已经处于滚动状态，但不会补发 scroll 事件，不主动算一次就会停在错误的比例上。

样式：用 transform，不要用 width#

#progress-bar {
  position: fixed;
  top: 0;
  left: 0;
  width: 100%;
  height: 3px;
  background: #2563eb;
  transform: scaleX(0);
  transform-origin: 0 50%;
  will-change: transform;
  pointer-events: none;
  z-index: 9999;
}