原 PDF 技术勘误

核对日期：2026-11-12。本文针对原题中明显错误、过时实现和容易误用的结论，给出原因、适用范围及复验方法。

来源：《golang云原生面试题》，共 107 页。下文 P 指原 PDF 从 1 起算的物理页码，便于对照题库。各条页码已按原件核对。

标记约定：规范指 Go 语言规范或内存模型保证；库契约指公开 API 行为；实现只指注明版本的编译器/runtime/产品行为。Go 实现以官方 gc 工具链 Go 1.24 的变更为主要对照，验证环境为 go1.26.2 darwin/arm64，不把该环境称作最新版。其他产品按条目注明版本。代码块中的片段需置入函数并补齐相应 import；只有带 package main 的块是独立程序。命令是复验方法，执行状态见文末。

Go：规范、库契约与旧实现

C01 · P1、P38–40：不能凭“并发”认定 Go GC 比 Java/Python 更高效

原题定位：P1“与其他语言相比，使用 Go 有什么好处”中的 GC 比较；P38“混合写屏障”称 GC 全程无 STW。

更正〔实现〕：并发 GC 仍消耗 CPU、内存带宽并有屏障成本；Java 的具体收集器、Python 的具体解释器也不能一概而论。Go gc runtime 的并发标记清扫仍有标记准备和标记终止的 STW；消除终止时的全量栈重扫不等于消除所有 STW。P40 的历史阶段图不能作为以后版本的精确执行图。

验证/现代做法：固定工具链、负载、堆存活量、吞吐和 P99 延迟，再用 GODEBUG=gctrace=1 ./app、go tool trace trace.out、pprof 比较。Go 1.19 起可配 GOMEMLIMIT；它是软限制，也不覆盖全部进程/C 内存，不能直接等同容器 RSS 上限。增大 GOGC 会用更多内存换取更低回收频率，应在内存预算内测量。

依据：Go GC 指南、Go 1.24 runtime/mgc.go。

C02 · P1、P31：Mutex 不绑定 goroutine；RWMutex 也不保证新读者总能进入

原题定位：P1 称只有获得 Mutex 的 goroutine 释放后别人才能继续；P31 称“读锁占用不会阻止读”。

更正〔库契约〕：一个 goroutine 可以 Lock，另一个可以 Unlock；锁没有 goroutine 所有者校验。零值可用，首次使用后不得复制。RWMutex 已有写者等待时，会阻塞后来的 RLock，以免写者饥饿，因此递归读锁可能死锁，也不能原地升级读锁为写锁。

验证：下面合法；等待结束使用 channel，不能靠 Sleep 推测解锁完成。

package main

import "sync"

func main() {
    var mu sync.Mutex
    done := make(chan struct{})
    mu.Lock()
    go func() { mu.Unlock(); close(done) }()
    <-done
    mu.Lock()
    mu.Unlock()
}

依据：sync.Mutex.Unlock、sync.RWMutex。

C03 · P2：interface nil 结论基本正确，但不能只检查其动态值

原题定位：“输入 non-empty interface”提到动态值、动态类型都为 nil；容易被背成“接口里装着 nil 就等于 nil”。

更正〔规范〕：接口零值没有动态类型。把 (*T)(nil) 赋给接口后，接口带有动态类型 *T，比较 == nil 为 false；error 同样如此。“两字段”只是理解工具，不是可依赖的 ABI 布局。返回无错误应显式 return nil，不要返回带类型的 nil 指针。

package main

import "fmt"

type E struct{}
func (*E) Error() string { return "error" }
func bad() error { var p *E; return p }
func good() error { return nil }
func main() {
    var p *int
    var x any = p // any 需 Go 1.18+；旧版写 interface{}
    fmt.Println(p == nil, x == nil, bad() == nil, good() == nil)
    // true false false true
}

依据：Go FAQ：nil error、接口值规范。

C04 · P2、P24–25：有缓冲 channel 也会阻塞，也提供同步关系

原题定位：P2“有缓冲的 channel 是非同步的”；P24–25 又称收发必成对、无论收发都必阻塞。

更正〔规范〕：缓冲未满时发送可完成，不要求接收者已就绪；缓冲空且未关闭时接收阻塞；满缓冲发送阻塞。无缓冲收发需配对才能完成。有缓冲不等于没有 happens-before；发送前的写，对对应接收完成后的读可见。队列容量不保证其中的消息最终有人消费。

ch := make(chan int, 1)
ch <- 1 // 不需要接收者
select {
case ch <- 2:
    panic("缓冲已满，不应发送成功")
default:
}
close(ch)
v, ok := <-ch // 1, true：先排空缓冲
z, open := <-ch // 0, false
_, _, _, _ = v, ok, z, open

依据：Channel types、内存模型：Channel communication。

C05 · P2、P24–28：并发通信必须按 Go memory model 建立发布关系

原题定位：通道“同步”和“共享内存”的讲解缺少可见性边界；P28 使用等待通道通知工作结束。

更正〔规范〕：goroutine 退出、Sleep、观察队列长度都不是发布共享数据的同步机制；即使 GOMAXPROCS=1，也不能据此跳过同步。无数据竞争程序具有顺序一致性保证。发送同步先于相应接收完成；close 同步先于因已关闭而读到零值的接收；容量 C 的通道，第 k 次接收同步先于第 k+C 次发送完成。不能把“发送已返回”理解成“接收者后续工作已完成”。

package main

import "fmt"

func main() {
    var result int
    done := make(chan struct{})
    go func() { result = 42; close(done) }()
    <-done
    fmt.Println(result) // 42；close/receive 发布 result
}

验证：把接收替换成 Sleep 后，不再有此保证；对这类反例运行 go run -race main.go。race detector 只能检查实际执行路径，未报告不是无竞争证明。

依据：Go memory model、Race detector。

C06 · P2、P9：Go select 不是 OS select，也不直接处理文件描述符

原题定位：P2“关于 select 机制”称用于异步 IO、每个 case 必须是 IO 操作。

更正〔规范/实现〕：Go select 的通信分支是 channel 发送或接收，另可有 default；不能直接放文件读写、HTTP 调用或 fd。OS select(2) 是描述符就绪检测，二者只同名。Go 网络库使用的 netpoll 与平台实现有关，并非 select 语句的规范。P9 多个分支可执行时会作均匀伪随机选择；GOMAXPROCS=1 不能强制选中第一个，也不保证有限时间内每个分支都执行。

select {
case value := <-results:
    _ = value
case <-ctx.Done():
    return
}
// case file.Read(buf): ... 不是合法的 Go select 通信分支

依据：Select statements、Go 1.24 netpoll 实现。

C07 · P7–8：关闭通道不代表每次必选中；break 也不会退出外层 for

原题定位：P7“for 循环 select”称关闭的 case 每次都会执行；P8 交替打印代码含 default: break。

更正〔规范〕：关闭通道的接收永远就绪，但还有其他就绪分支时会参与选择。无标签 break 只退出 select；放在外层 for 中且配 default 会忙轮询。处理完关闭通道应 return，或把本地 channel 变量置 nil，禁用该分支。单个 select 本身不会形成循环。

for ch != nil {
    select {
    case v, ok := <-ch:
        if !ok { ch = nil; continue }
        use(v)
    case <-ctx.Done():
        return
    }
}

P8 的打印程序还需让两个 worker 都能结束并等待它们，不能只等待字母 goroutine 后把数字 goroutine 遗留在发送上。

依据：Select statements、Break statements。

C08 · P3–5、P23：slice 参数按值传递；赋值副本和复制元素成本不同

原题定位：P3 称切片引用传递、初始化时 len=cap；P4 又正确称值传递；P5 称切片是只读对象；P23 再次混用引用传递。

更正〔规范/实现〕：所有参数均按值传递；slice 值描述共享的底层数组，但可重新赋值、切片、append，并非只读。make([]int, 2, 8) 的 len 不等于 cap。当前 gc 实现赋值复制 slice 描述符，成本不随元素数增长；copy 或克隆底层元素通常随复制元素数增长。函数内 append 后的新长度不会自动回写调用者，通常返回新 slice。

package main

func add(s []int) []int { return append(s, 3) }
func main() {
    s := make([]int, 1, 4)
    t := s
    t[0] = 9 // s[0] 也为 9
    s = add(s)
    clone := append([]int(nil), s...) // 独立底层数组，元素仍是浅复制
    clone[0] = 7
    if s[0] != 9 || len(t) != 1 || len(s) != 2 { panic("错误的别名或长度") }
}

依据：Passing arguments、Appending and copying slices。

C09 · P4–5：1024 阈值与 1.25 倍扩容只是旧 gc 实现

原题定位：“Go 语言是如何实现切片扩容”“Slice 的扩容机制”。

更正〔规范/实现〕：规范只保证 append 的结果长度、容量足够以及必要时分配新数组，不承诺固定增长序列。Go 1.24 gc 的 nextslicecap 使用 256 阈值，小容量通常翻倍，大容量用 newcap += (newcap + 3*256) >> 2 平滑过渡；一次追加很多元素可直接取所需长度。随后还会按元素大小、分配尺寸类对齐，结果未必是精确 1.25 倍。原文更接近 Go 1.17 等旧实现，也漏掉了对齐。

验证：记录工具链和架构，分别观察 []byte、[]int、[]struct{ X [33]byte } 的容量变化；业务只断言 len(result) 和内容。知道上限时用 make([]T, 0, n) 预分配；不要写断言某次 append 后 cap 必为 1280 的业务测试。

依据：Go 1.24 slice.go、Go 1.17 slice.go。

C10 · P6：Go 1.24 默认 map 已改用 Swiss Table

原题定位：“Map 底层实现/如何扩容/查找”全以 hmap、bmap、overflow 和渐进搬桶解释。

更正〔实现〕：这些主要对应 Go 1.23 及以前的 gc map。Go 1.24 默认改为 Swiss Table：以 group、控制字筛选、开放寻址探测，并通过表增长/拆分控制大 map 的扩容成本。不能继续把 overflow 链、等量扩容、每次搬两桶当作新版结构。Go 1.24 曾提供 GOEXPERIMENT=noswissmap 对照，不能假定以后版本仍有该开关。

旧实现的高位哈希也只是筛选候选槽，最终必须比较 key 相等，不是比较完整哈希就能确认同一 key。规范不保证布局、迭代顺序或并发读写安全；换 Swiss Table 没有改变这些边界。

验证：用同一基准比较 Go 1.23 与 1.24，记录版本/实验开关；共享可变 map 用 Mutex 或符合场景的 sync.Map。不要通过 unsafe 强转 hmap 来写跨版本业务。

依据：Go 官方 Swiss Table 说明、Go 1.24 发布说明、Go 1.23 旧 map 查找源码。

C11 · P15–16：StringHeader 强转 SliceHeader 会越界读取，也违反字符串约束

原题定位：“字符串转成 byte 切片，无内存拷贝的实现”将局部 reflect.StringHeader 的地址读成 []byte。

更正〔规范/库契约〕：StringHeader 只有两个机器字，slice 描述符需要三个，读取 Cap 已超出该局部对象；Data 的 uintptr 又不保持底层对象存活。即使凑出三个字段，也不能修改字符串底层字节。字面量可能指向只读存储，修改可能崩溃。

普通代码使用 b := []byte(s) 获得可写语义；编译器是否在特定只读用法中省去复制属于优化。必须建立只读零拷贝视图时，Go 1.20+ 有专门 API，但返回的 slice 仍须约定不写、不交给会修改的函数：

s := "abc"
view := unsafe.Slice(unsafe.StringData(s), len(s)) // Go 1.20+
fmt.Println(string(view))
runtime.KeepAlive(s)
// 禁止 view[0] = 'x'

验证：go vet、go run -gcflags=all=-d=checkptr=2 main.go 可辅助发现非法转换，检查未报错不等于满足生命周期与只读要求。

依据：unsafe.Pointer 的合法模式、Go 1.20 unsafe 新 API。

C12 · P19–21：uintptr 不保活；不能复制 runtime noescape 绕过逃逸分析

原题定位：“怎么避免内存逃逸”的 uintptr(p)、x ^ 0 和 NewATrick。

更正〔库契约/实现〕：uintptr 是整数，不是 GC 引用。把指针转成 uintptr 存起来再转回通常不属于合法模式；栈移动、对象回收会使地址失效。runtime 内部函数依赖内部调用约束，复制其源码不使应用自动具备这些约束。隐藏返回的局部指针可能制造悬空引用，内联恰好掩盖问题也不能证明安全。

现代写法：需要长期保留就保存正常类型的指针并接受必要逃逸；对象内偏移可用 Go 1.17+ 的 unsafe.Add，仍必须位于原分配对象内。runtime.KeepAlive 只延长可达性，不能把任意 uintptr 往返变合法，也不能固定移动中的栈地址。

type A struct { S *string }
func NewA(s string) A { return A{S: &s} } // 生命周期由 Go 保证

验证用 go build -gcflags=all=-m=2 看决策，优先减少真实分配，而不是欺骗编译器。

依据：unsafe.Pointer、runtime.KeepAlive。

C13 · P18–21：返回局部指针、fmt 输出不必然导致每次堆分配

原题定位：P19 称 fmt.Println 打印的变量都会逃逸，返回局部指针必逃逸；同页输出其实已有内联后 does not escape。

更正〔实现〕：逃逸是具体编译器根据数据流和调用上下文的分析结果，不是语法规约；返回局部地址在 Go 中安全，内联后分配可能留在调用者栈上或消除。编译诊断的“表达式逃逸”也不等于每次执行都新增一个堆对象。

验证：对完整程序执行 go build -gcflags=-m=2 main.go，再与 go build -gcflags='-l -m=2' main.go 对比；用 go test -bench=. -benchmem 或 testing.AllocsPerRun 测真实分配。比较时保持代码、工具链和编译选项一致。

依据：Go FAQ：堆还是栈、编译器选项。

C14 · P22：同一种 struct 也可能不能比较

原题定位：“相同 struct 类型的可以比较”。

更正〔规范〕：struct 只有所有字段类型都可比较时才可比较。含 slice、map 或 func 字段的 struct 不能用 ==；含接口字段虽然静态可比较，若动态值不可比较仍会 panic。不同命名类型一般不能直接比较，但可按规范允许的显式转换后比较，不能扩张成“任何不同 struct 都不能比较”。

type S struct { Items []int }
// _ = S{} == S{} // 编译错误
type T struct { X any }
// _ = T{[]int{1}} == T{[]int{1}} // 运行时 panic
// Items 的元素相等可用 slices.Equal(a.Items, b.Items)，Go 1.21+

依据：Comparison operators、slices.Equal。

C15 · P4–5：defer 不保证任何退出路径都释放资源

原题定位：“不论任何执行路径，资源都会释放”；“defer 直接跟在申请资源后”。

更正〔规范/库契约〕：正常 return 和当前 goroutine 的 panic 栈展开会执行 defer；os.Exit、进程被杀、runtime 致命错误不保证执行。调用参数在遇到 defer 时求值；闭包读取变量则在执行时发生。先检查申请错误，再登记释放；循环内大量 defer 会拖到整个函数退出，必要时抽成小函数。

f, err := os.Open(path)
if err != nil { return err }
defer f.Close() // 写文件时还应按需求处理 Close 的错误

验证可分别运行包含 defer fmt.Println("cleanup") 的 return、panic 和 os.Exit 子程序，观察最后一种不输出 cleanup。

依据：Defer statements、os.Exit。

C16 · P4、P24–27、P33–35：GOMAXPROCS 限制 P，不等于线程总数

原题定位：P4 称 GOMAXPROCS 控制 OS 线程数；P24/P33 称 M 数量对应真实 CPU 数；P35 把阻塞系统调用的处理一概解释为等 sysmon。

更正〔实现/库契约〕：P 是执行 Go 代码需要的调度资源，M 是 OS 线程；M 可因阻塞 syscall、cgo、线程绑定等多于 P。GOMAXPROCS=1 仍可有很多线程。网络等待通常通过 netpoll 挂起 G、让 M 执行其他 G，普通文件 IO 不保证走相同路径；channel 阻塞也不等于堵住整个 M。Go 1.14 已引入异步抢占，不能继续把仅在函数调用点协作让出作为通用描述。抢占与 syscall 交还 P 是不同机制。

验证：GODEBUG=schedtrace=1000 ./app 观察 gomaxprocs、threads 和 idleprocs；用 trace 区分网络等待、syscall 与 runnable。默认 P 数还需按所用 Go 版本、CPU affinity 和容器配置核实，不能把旧版“CPU 核数”当永久规则。

依据：runtime.GOMAXPROCS、Go 1.14 runtime、Go 1.24 runtime/proc.go。

C17 · P33–35：cgo 不能套用“所有 IO 都让出线程、并行量只由 P 限制”

原题定位：P33“所有系统调用操作都会出让 CPU”、P35“任何情况下并行 goroutine 数不超过 P”。本条是这些绝对断言在 cgo 边界的补充，原文并没有独立的 cgo 题。

更正〔实现/库契约〕：普通 cgo 调用在 OS 线程上执行 C，阻塞 C 调用会占用该线程；runtime 可让其他线程取得 P 执行 Go，但不会因此取消 C 调用。多个 C 调用可以并行，C 自己创建的线程也不受 GOMAXPROCS 限制。频繁跨边界有开销，CPU 密集 C 工作不会自动服从 Go worker 数限制。

现代写法/验证：为 C 任务设置应用级并发上限；Context 取消需桥接 C API 的取消能力。用 go env CGO_ENABLED、线程数及 trace 验证。C 不得随意长期保存 Go 指针；Go 1.21+ 如确需跨调用保存合规的 Go 对象，核对 runtime.Pinner，或用 runtime/cgo.Handle 传句柄。Pin 和句柄都有显式释放生命周期；C 分配的内存仍需相应 C free，不能指望 Go GC 全部回收。

依据：cgo：Passing pointers、runtime/cgo.Handle。

C18 · P30–31：Mutex “只剩一个等待者就进入饥饿模式”写反了

原题定位：P30 正常/饥饿模式称等待超过 1ms“或者当前队列只剩一个 goroutine”触发饥饿模式。

更正〔实现〕：Go 1.24 的约 1ms 阈值用于判断等待者是否饥饿，并结合锁状态竞争进入饥饿模式。饥饿模式下获得锁者若是最后一个等待者，或等待不足阈值，会尝试 退出 饥饿模式。1ms、自旋轮数和唤醒顺序都是实现策略，不是公平性/最长等待时间保证。

验证：对照 starvationThresholdNs、starving 和最后等待者的判断分支；用 mutex profile 测竞争。业务不得用 Sleep(1ms) 推导下一次必拿到锁，RWMutex 也没有公开的严格 FIFO 契约。

依据：Go 1.24 internal/sync/mutex.go、sync 库契约。

C19 · P29–30：Context 是接口；Deadline 查询时间，不设置时间

原题定位：P29 称核心是 struct Context；P30 称 Deadline 设置取消时刻，Done 中有取消信号。

更正〔库契约〕：Context 是接口；Deadline() 返回截止时刻和是否存在，设置要用 WithDeadline/WithTimeout。Done 是关闭来广播，不是逐个发送消息；Background 的 Done 可为 nil。cancel 只提出取消请求，不会杀死 goroutine，也不等待它退出；Value 不应用于携带一般可选参数或把可变对象自动变安全。

ctx, cancel := context.WithTimeout(parent, 2*time.Second)
defer cancel()
req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
if err != nil { return err }
resp, err := http.DefaultClient.Do(req)
if err != nil { return err }
defer resp.Body.Close()

依据：context。

C20 · P9–10：ASCII 不是 256 字符，strings.Count(s, "") 也不是字节数

原题定位：“判断字符串中字符是否全都不同”称 ASCII 一共有 256 个字符，示例使用空串 Count 检查长度。

更正〔规范/库契约〕：ASCII 是 7 位、128 个码位；所谓扩展 ASCII 不是唯一统一的编码。Go string 是字节序列；len(s) 是字节数，range 按 UTF-8 解码 rune，strings.Count(s, "") 为 rune 数加一，不能替代字节长度。严格 ASCII 输入超过 128 字节必重复，不必检查到 3000。

现代写法：若要求不使用额外存储，可双循环比较字节，先验证所有字节 <128，再做长度上限判断；若允许常量空间，可用两个 uint64 做 128 位集合。UTF-8 的“用户看到的一个字”还可能由多个 rune 组成，不能把反转 rune 一概等同字素反转。

依据：Go 字符串与 rune、strings.Count。

C21 · P15：nil slice 与非 nil 空 slice 不应按底层地址判断

原题定位：“nil 切片和空切片的区别”用 reflect.SliceHeader.Data 推断是否有真实对象。

更正〔规范/实现〕：var a []int 是 nil slice；b := make([]int, 0) 非 nil，但不保证分配独立的底层存储，空 slice 的地址可能共享实现中的零大小存储。二者 len/cap 都可为 0，都可 append、range、copy；不能用 Data 地址断言身份。

var a []int
b := make([]int, 0)
fmt.Println(a == nil, b == nil) // true false
ja, _ := json.Marshal(a)
jb, _ := json.Marshal(b)
fmt.Println(string(ja), string(jb)) // encoding/json：null []

这是接口序列化契约应明确区分的行为；不需要 unsafe。依据：Slice types、encoding/json.Marshal。

Docker 与 Kubernetes

C22 · P48：Dockerfile 不等于一条指令一个文件系统层

原题定位：“Image 和 Layer 有什么不同”将 FROM、COPY、RUN、CMD 计为四个新层；另称 FROM 必是第一条指令。

更正〔产品实现〕：COPY/RUN 等可以形成文件系统差分；CMD/ENTRYPOINT/ENV 等主要改变镜像配置，不是新增一个有内容的文件系统层。FROM 选用已有基础层；多阶段构建还涉及最终阶段的选择。FROM 前允许 ARG，也允许解析器指令和注释。

验证：对自己的镜像比较历史与 inspect 输出中的 RootFS.Layers；history 项数不能直接当 diff 层数。

docker history --no-trunc IMAGE
docker inspect --type=image IMAGE

依据：Dockerfile reference、Dockerfile overview。

C23 · P51：容器停止不会自动丢掉可写层

原题定位：“数据保存在容器中，当容器停止运行时，运行状态数据丢失”。

更正〔产品实现〕：stop 后同一个容器的可写层仍在，start 可继续访问；删除容器、--rm 自动删除或编排器替换容器时才不能依赖该层。tmpfs 是另一种生命周期。volume 脱离容器生命周期，但是否保留还取决于删除操作、存储故障与回收策略；网络卷也不等于自动备份。

验证：在隔离实验中向容器写文件，stop/start 后读取，再用同一镜像新建容器比较；持久数据应显式挂 volume/bind mount 并安排备份。不能用“有卷”证明可以跨节点无损迁移。

依据：Docker storage。

C24 · P52–53：现代 Compose 可以等待依赖健康

原题定位：“为什么 Compose 不等待依赖容器就绪”。

更正〔Compose 语义〕：简写 depends_on 主要约束启动顺序；现代 Docker Compose 的长写法支持 condition: service_healthy，也支持等待任务成功完成。健康等待不能代替应用运行期的重连、退避和超时。

services:
  db:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: local-example-only
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 2s
      timeout: 2s
      retries: 20
  app:
    image: example/app:1
    depends_on:
      db:
        condition: service_healthy

示例中 app 镜像需替换为实际镜像；在现代 docker compose 环境通过 docker compose config 检查，不能把这段直接当作 Swarm 的部署语义。

依据：Compose startup order。

C25 · P53–54、P57：K8s 1.24 移除的是内置 dockershim

原题定位：称 K8s 弃用 Docker、1.24 已使用 containerd，kubelet 通过控制 Docker 启动容器。

更正〔Kubernetes 版本〕：1.24 移除内置 dockershim，不是禁止 Docker 构建的 OCI 镜像，也不是规范强制只能用 containerd。kubelet 经 CRI 使用 containerd、CRI-O 等兼容运行时；Docker Engine 如需使用，要额外接入 cri-dockerd，而不是旧内置适配器。rkt 也不能继续作为现代默认选型列举。

验证：kubectl get nodes -o custom-columns=NAME:.metadata.name,RUNTIME:.status.nodeInfo.containerRuntimeVersion；节点上用 crictl 查看实际 CRI 配置。构建工具、镜像格式和节点运行时应分别回答。

依据：Container runtimes、Dockershim FAQ。

C26 · P54：Metrics Server 向 kubelet 取指标，原文方向写反

原题定位：“kubelet 通过 Metrics Server 获取所在节点及容器的数据”。

更正〔组件职责〕：kubelet 暴露资源指标，Metrics Server 从节点采集并通过聚合 API 提供 metrics.k8s.io，供 kubectl top、HPA 等使用。它通常作为集群组件部署，不是要求每个节点上部署一个 Metrics Server；完整历史监控也不由它承担。

验证：kubectl get apiservice v1beta1.metrics.k8s.io、kubectl top nodes；排查采集失败看 Metrics Server 到 kubelet 的网络、证书和访问权限，不能沿反方向排查。

依据：Resource metrics pipeline。

C27 · P56：Always 不代表每次重新下载所有镜像层

原题定位：“IfNotPresent 默认；Always 每次创建 Pod 都重新拉取一次镜像”。

更正〔API 语义〕：Always 在每次启动容器时要求解析/拉取镜像；已缓存的相同 digest 层可复用，不等于重下载全部数据。未显式配置时，:latest 或省略 tag 通常默认 Always，其他 tag、digest 通常为 IfNotPresent。默认策略创建对象时确定，后来改 tag 不会自动跟着改变该字段；准入策略也可能覆盖默认值。

验证：用 kubectl create --dry-run=server -f pod.yaml -o yaml 查看默认后的字段；用 kubectl describe pod NAME 及运行时事件核对重用缓存。发布时显式写策略，并用 digest 固定镜像内容。

依据：Images：pull policy。

C28 · P56–57：探针成功是 200 ≤ code < 400；startup 比盲增延时更合适

原题定位：HTTP“200–400 成功”、一定要 initialDelaySeconds、生产一定要 liveness、就绪保证客户端永远不知道问题。

更正〔API 语义〕：400 是失败；exec 执行指定命令，不会自动套 shell，需 shell 时显式 /bin/sh -c。liveness/startup 失败达阈值可触发容器重启，readiness 失败影响可服务性。启动慢可用 startupProbe，在其成功前不执行 liveness/readiness。liveness 应检测无法自行恢复的故障，不能因外部数据库暂不可达就把所有实例重启。EndpointSlice 和转发规则更新是异步的，探针不能保证零失败请求；启用 publishNotReadyAddresses 等配置还会改变发布行为。

# 容器字段片段；假定命名端口 http 和三个路径均已实现
startupProbe:
  httpGet: {path: /startup, port: http}
  periodSeconds: 2
  failureThreshold: 60
livenessProbe:
  httpGet: {path: /live, port: http}
readinessProbe:
  httpGet: {path: /ready, port: http}

验证返回 200、399、400 的路径并查看 Pod 事件、restartCount 和 EndpointSlice 的 conditions，而不是只看进程是否运行。

依据：配置三类探针、EndpointSlice 条件。

C29 · P51–55：namespace 不是完整安全边界；Pod 默认也不共享全部 namespace

原题定位：Linux namespace 中进程不能与其他 namespace 交互；K8s namespace 实现多租户隔离；pause 使所有业务容器共享 pid/net 等。

更正〔Linux/Kubernetes 实现〕：Linux namespace 隔离的是特定资源视图，不会自动禁止跨容器网络和共享挂载。K8s Namespace 是 API 作用域，不自动隔离网络，需要受 CNI 支持的 NetworkPolicy、RBAC、配额等配合。Pod 通常共享网络，PID namespace 默认不在业务容器间共享，需 shareProcessNamespace: true。卷要分别挂载；不是所有容器天然有相同挂载树。pause/sandbox 是常见运行时实现，不宜扩大成所有 RuntimeClass 的固定进程布局。

验证：对照 Pod 的 hostNetwork、hostPID、shareProcessNamespace、volumeMounts；在不同 namespace 测连通性，再检查 NetworkPolicy 是否被 CNI 实施。hostNetwork/hostPort 还会让不同 Pod 争用节点端口，推翻原文“不同 Pod 不可能端口冲突”的绝对说法。

依据：共享进程 namespace、Network policies、Docker security。

C30 · P60–62：Service 不一定有 selector；LoadBalancer 不一定公网

原题定位：Service 均由标签关联 Pod；LoadBalancer 必须公有云和公网 IP；ExternalName 被描述为代理外部服务。

更正〔API 语义〕：Service 可无 selector，由用户/控制器管理 EndpointSlice；LoadBalancer 可以由私有基础设施实现，也可以是内部地址。ExternalName 主要提供 DNS CNAME，不做普通 Service 的四层代理，HTTP Host/TLS 名称要额外匹配。headless Service 的 clusterIP: None 不分配普通虚拟 IP，DNS 可直接返回后端地址；selector、就绪状态及 publishNotReadyAddresses 会影响结果。

验证：kubectl get svc NAME -o yaml、kubectl get endpointslices -l kubernetes.io/service-name=NAME -o yaml，再在 Pod 内用 DNS 查询区分 CNAME、普通 ClusterIP 和 headless 地址。不能看到 Service 名字可解析就断言后端健康。

依据：Service 官方概念。

C31 · P66：etcd“双 leader”案例根因未证实，不能教成删数据重建

原题定位：重建后恢复，末尾自述原因没有定位、怀疑环境问题。

更正〔证据边界〕：原案例缺日志、cluster ID、member ID、term 和拓扑，无法确定是否误接了两个集群、旧数据目录、选举过渡或其他配置错误。Raft 同一集群同一 term 不允许两个有效 leader；非同时的观察、不同集群或旧 leader 的自我认知不等于两个 leader 都能提交写入。恢复成功不能反推根因。

验证路径：先保存日志和配置；通过显式 endpoints 执行 etcdctl endpoint status -w json、etcdctl member list -w json，对照 cluster ID、成员、leader ID、term，再检查 API Server 连接的 endpoints。按官方流程保存快照、校验并演练恢复。删除数据目录是有数据损失风险的重建动作，不能从测试环境经验推广到生产。

依据：etcd FAQ、etcd 维护与快照。

Redis

C32 · P66–67、P83：Redis 的许可证、线程模型和性能都要带版本与条件

原题定位：P66“完全开源免费、BSD”、固定读写 QPS；P67/P83“单进程单线程”“比 Memcached 快”。

更正〔Redis 版本/实现〕：Redis 7.2 及更早版本适用 BSD 3-Clause；7.4 改为 RSALv2/SSPLv1，Redis 8 增加 AGPLv3 选项，不能用 BSD 概括所有版本。常规命令主要由主线程串行执行，不代表整个服务只有一个线程：后台 IO、异步释放等可使用线程，持久化还可 fork；6.0 起引入可配置的网络 IO 线程。不能由此推导所有命令 O(1)，也不能断言固定 QPS 或必胜另一个产品。

验证：记录 INFO server 的版本、INFO commandstats、CONFIG GET io-threads、持久化配置和线程观测。压测说明命令、value 大小、pipeline 深度、连接数、网络及 P99 延迟；只比较同等资源/持久化条件下的结果。

依据：Redis 许可证说明、Redis 6 IO 线程说明、官方 benchmark 指南。

C33 · P66–67、P70：Redis 事务不提供运行期失败的整体回滚

原题定位：多处称 MULTI/EXEC 中命令要么全部成功，要么完全不执行。

更正〔事务语义〕：EXEC 中的命令顺序执行且不与其他客户端命令交错，但运行期类型错误不会撤销之前成功的命令，也不阻止之后命令继续。入队时的语法/参数错误会导致 EXEC 拒绝整个事务，与运行期错误不同。WATCH 检测冲突后可使 EXEC 不执行，客户端需要重试；DISCARD 是丢弃尚未执行的队列，不是执行后的回滚。Pipeline 更不等于事务。

验证：在独立测试库、同一 redis-cli 连接中逐条执行：

SET correction:kind text
MULTI
SET correction:first ok
LPUSH correction:kind item
SET correction:last ok
EXEC
MGET correction:first correction:last

预期 EXEC 的中间结果 WRONGTYPE，而两个 SET 都成功，MGET 返回两个 ok。不要以“EXEC 已返回”替代逐项检查响应。

依据：Redis transactions：错误处理。

C34 · P67–69：持久化不等于把一部分活跃数据移到磁盘，也不等于零丢失

原题定位：P67 将 Redis 描述为部分数据在硬盘、使用 VM；P68 称 fork 后主进程无 IO，并建议主库不持久化、仅从库 AOF。

更正〔普通 Redis OSS/实现〕：普通 Redis 的持久化文件用于恢复，不是透明的磁盘分页；历史 VM 机制不能当现代架构。区分 SAVE 阻塞与 BGSAVE 子进程快照，fork、写时复制和磁盘竞争仍可能增加延迟/内存。AOF everysec 通常有约一秒的数据丢失窗口；Redis 7.0 起采用多部件 AOF，不能一直按“唯一 aof 文件”运维。异步复制也不是数据备份。

仅从库持久化、主库无持久化且自动重启，可能出现空主库重新同步、从库数据也被清空。是否持久化和故障切换必须整体设计。

验证：INFO persistence、CONFIG GET appendonly、CONFIG GET appendfsync、INFO replication，结合实际恢复演练测 RPO/RTO；不能拿有 dump.rdb 就认定最近写入不会丢失。

依据：Redis persistence、复制与无持久化主节点风险。

C35 · P72：SCAN 是增量扫描，不是后台无阻塞快照

原题定位：“scan 可以无阻塞提取匹配 key，客户端去重即可”。

更正〔命令语义〕：SCAN 每次仍在命令执行线程上做工作；相较一次遍历的 KEYS，它把总工作拆成多次。COUNT 是工作量提示，不是精确页大小。一次返回空列表但游标非零时仍需继续；重复项允许出现，扫描期间增删的 key 不具有快照保证。完整遍历保证始终存在的元素被返回，不保证每个瞬时元素都能捕获。Cluster 通常要逐主分片扫描。

验证/现代做法：从游标 0 开始，将响应的新游标原样传回，直到重新为 0；下游操作做幂等，限制每批工作与速率。redis-cli --scan --pattern 'prefix:*' 可用于单节点人工排查，但匹配查询模式不能变成写入冻结时刻的一致快照。

依据：SCAN 的迭代保证和 COUNT。

C36 · P73：SET NX PX 只解决加锁原子性，还需所有者校验和租约边界

原题定位：原文已指出 SETNX 与 EXPIRE 分两步的 crash 窗口，但到“合成一条指令”即结束。

更正〔锁协议〕：单节点获取可用 SET key token NX PX ttl，token 应为每次获取唯一的随机值。释放必须原子比较 token 再删除，不能直接 DEL，否则旧持有者可能删除新持有者的锁。任务超过 TTL 后，旧持有者不会自动停止，因此租约不能单凭超时保证外部写入互斥；需要受保护资源执行 fencing token 或等效版本条件。异步主从故障切换也可能丢失锁记录。

SET correction:lock <unique-token> NX PX 30000

原子释放脚本（Lua；KEYS[1] 为锁名、ARGV[1] 为本次 token）：

if redis.call('GET', KEYS[1]) == ARGV[1] then
    return redis.call('DEL', KEYS[1])
end
return 0

验证：让 A 持锁过期、B 获取同一锁，再让 A 释放；脚本必须返回 0 且 B 的锁仍存在。这是在校验协议，不是在证明所有网络分区下的强互斥。

依据：Redis distributed locks。

C37 · P69–70：Cluster 副本数量可配置，不是每个节点 N−1 份

原题定位：P70“每个节点都会有 N−1 个复制品”“大部分节点无法通信仍可用”“最大节点 16384”。

更正〔Redis Cluster〕：16384 是槽位数，不是把所有类型节点统一限制为此数的理由。副本数来自部署配置，例如三个主节点各一个副本共六个节点；不是所有节点都互为全量副本。故障转移需要多数主节点参与授权等条件，失去多数一侧不能持续接受正常写入。槽缺失时的服务范围还受 cluster-require-full-coverage 等配置影响，不能仅凭 B 掉线就无条件断言全部不可用。

验证：CLUSTER INFO、CLUSTER NODES、CLUSTER SLOTS 和 CONFIG GET cluster-require-full-coverage，核对主从、槽归属与可达多数。主库已确认但未复制的写可能在故障切换时丢失；WAIT 可降低风险，但不能把异步复制升级为强一致事务。

依据：Redis Cluster 扩展与故障转移、WAIT 的保证边界。

C38 · P68–71：过期删除与内存淘汰是两套机制，策略不止旧版六种

原题定位：将“每键一个 timer”列为 Redis 实际删除机制；淘汰列出六种，且拼成 no-enviction。

更正〔Redis OSS 实现/配置〕：key 过期主要结合访问时被动检查与主动抽样清理，不是给每个 key 分配一个独立定时器保证准点物理释放。过期后的逻辑不可见与实际释放内存的时刻不同。maxmemory 淘汰另由策略控制；现代版本还有 allkeys-lfu、volatile-lfu，正确名称是 noeviction。近似 LRU/LFU 并不能数学保证缓存恰好都是最热的 20 万条。

验证：CONFIG GET maxmemory、CONFIG GET maxmemory-policy、INFO stats 中 expired_keys/evicted_keys；分别观察短 TTL 和内存压力实验。volatile 系列在没有可淘汰 TTL key 时可能无法释放空间；noeviction 下是需要额外内存的相关命令报错，不是所有写命令一概禁止。

依据：EXPIRE：过期机制、Key eviction。

C39 · P67、P72：字符串默认限制不是 513M；Top 10 的结束下标是 9

原题定位：P67“字符串最大 513M”；P72“前 10”却用 ZRANGE user_scores 0 10 WITHSCORES。

更正〔Redis 命令/版本配置〕：普通默认配置下字符串最大通常为 512 MiB，不是 513M；边界须结合版本和协议/批量长度配置，不能据此设计接近极限的大 value。ZRANGE 下标从 0 起、stop 包含在内，所以 0 到 10 最多有 11 个成员；默认分数升序，最高分 Top 10 应反向取。

ZRANGE user_scores 0 9 REV WITHSCORES

上式 REV 需 Redis 6.2+；更早版本用 ZREVRANGE。验证可插入 12 个不同分数成员，对比原指令与更正指令的成员数和排序；不需要创建 512 MiB 的测试值。

依据：Redis Strings、ZRANGE。

MySQL

C40 · P75、P79：READ COMMITTED 防脏读，不防不可重复读

原题定位：P75 将 read committed 解释为“脏读，不可重复读”；P79 将 RR 简化为 MVCC 解决问题。

更正〔InnoDB/MySQL 8.4〕：RC 的一致性读每条语句建立新快照，不能读取别人的未提交值，但同一事务多次读可能不同。RR 普通一致性读通常共享首次一致性读建立的快照；锁定读、UPDATE/DELETE 使用另一套加锁/可见性语义，不能混成“全事务永远读同一旧版本”。默认 RR 是 InnoDB 默认，不是所有数据库的共同默认。

验证：会话 A 设置 RC，BEGIN 后 SELECT；会话 B BEGIN、UPDATE 但不提交，A 再 SELECT 不应看到该未提交值；B COMMIT 后，A 再 SELECT 可见新值。改 RR 重做普通快照读，应继续看原快照。初始化表和数据、连接参数及每次 COMMIT 必须明确，不能只列四个名词。

依据：InnoDB transaction isolation levels。

C41 · P77：查询缓存阶段只适用于旧版本，MySQL 8.0 已移除

原题定位：“MySQL 查询缓存”把 SQL 文本和结果的缓存列入必经执行流程。

更正〔MySQL 版本〕：该 Query Cache 自 5.7.20 弃用，8.0 移除。MySQL 8.0/8.4 不能再按“连接 → 查询缓存 → 解析”的旧图背诵；InnoDB buffer pool 缓存数据/索引页，和缓存整条 SQL 的结果是不同机制。

验证：SELECT VERSION(); SHOW VARIABLES LIKE 'query_cache%';；在 8.x 不应靠设置旧 query_cache_size 调优。观察 buffer pool 应使用 InnoDB 指标；如需要应用层结果缓存，必须单独设计失效与一致性。

依据：MySQL 官方：移除 Query Cache、MySQL 5.7.20 发布说明。

C42 · P74、P76–77：InnoDB 二级索引不是行地址；范围后不等于全无索引用途

原题定位：MyISAM 因直接定位内存地址所以 SELECT 一定更快；P76 称 (a,b,c,d) 中 c 范围查询后 d“用不到索引”。

更正〔InnoDB/MySQL 优化器〕：InnoDB 聚簇索引存行，二级索引包含索引列和聚簇键；未覆盖时再按聚簇键查行。MyISAM 的数据位置不是稳定的内存地址，性能取决于缓存、访问模式与并发，不能由引擎名称定胜负。c 范围可能限制后续 d 缩小 B-tree 扫描区间的能力，但 d 仍可能用于索引条件下推过滤或覆盖查询；“用于定位”和“用于过滤/覆盖”要分开。

-- 假设 t 已有 INDEX ix(a,b,c,d)
EXPLAIN FORMAT=JSON
SELECT a,b,c,d FROM t WHERE a=1 AND b=2 AND c>3 AND d=4;

验证 used_key_parts、index_condition、attached_condition 与实际扫描量；覆盖查询与需回表查询分别观察。索引排序按整个工作负载设计，不是把每个列都按“最离散优先”机械排序。

依据：Clustered and secondary indexes、Index condition pushdown。

C43 · P74–75、P79：.frm 与默认引擎年份都是旧版本信息

原题定位：称 InnoDB/MyISAM 都有 .frm，InnoDB 总是 ibd+frm；P79 称 MySQL 5.1 后默认 InnoDB。

更正〔MySQL 版本/存储实现〕：InnoDB 成为默认引擎是 MySQL 5.5 起。MySQL 8.0 引入事务数据字典并移除 .frm；8.x 不能依赖复制 frm 文件恢复表定义。InnoDB 是否一表一 ibd 与 file-per-table、通用/系统表空间等配置有关；不能把所有部署都简化成两个文件。MyISAM 的 MYD/MYI 与旧版 frm 应区分。

验证：SELECT VERSION(), @@default_storage_engine, @@innodb_file_per_table; SHOW CREATE TABLE t;；结合 INFORMATION_SCHEMA 的表空间信息核对，不通过文件扩展名猜引擎或备份完整性。

依据：MySQL glossary：.frm/默认引擎、MySQL data dictionary。

C44 · P78：内部临时表不是一概 MEMORY/MyISAM，也不都活到连接关闭

原题定位：“临时表只对当前连接可见、连接关闭删除；内存 MEMORY、磁盘 MyISAM”。

更正〔MySQL 8.0/8.4〕：用户显式 CREATE TEMPORARY TABLE 的会话生命周期，与优化器内部临时表不是一回事。MySQL 8.4 内部内存临时表默认使用 TempTable，也可配置 MEMORY；内部磁盘临时表使用 InnoDB。查询中间结果通常按语句/执行阶段回收，不能一概等待连接断开。UNION ALL 在满足条件时可避免构造完整临时表，派生表也可能被合并。

验证：SHOW VARIABLES LIKE 'internal_tmp_mem_storage_engine';、EXPLAIN FORMAT=JSON、会话级 Created_tmp_tables/Created_tmp_disk_tables 前后差值。统计项有覆盖范围限制，不能只凭一个计数推断所有内存映射临时空间。

依据：MySQL 8.4 internal temporary tables。

C45 · P76、P78：SQL 优化口诀不能改变语义，也不能直接拿生产索引开刀

原题定位：固定“返回少于 30% 才走范围索引”“SELECT * 必全表扫”“不用 IS NULL”“BETWEEN 替 IN”；百万删除先删索引再建。

更正〔MySQL 优化器/操作方案〕：成本依赖统计、覆盖性、行宽与缓存，没有通用 30% 阈值；SELECT * 可用索引定位，IS NULL 也可用索引。IN (1,3) 与 BETWEEN 1 AND 3 不等价，后者还包含 2。删除索引可能去掉唯一性/外键所需约束，重建有锁、日志、IO 成本，原文分钟数没有数据规模、硬件和实验依据，不能作为普遍结论。

现代做法/验证：先核对结果集，再用 EXPLAIN 和代表性数据测量。对允许分批、具有 id 主键和截止条件的归档任务，可评估如下有界批次：

DELETE FROM events
WHERE id > ? AND id <= ? AND created_at < ?
ORDER BY id LIMIT 1000;

上式需应用绑定参数、设计断点和重试，并观察锁等待、undo、复制延迟及业务约束；它不是“复制即用”的万能删除脚本。EXPLAIN ANALYZE 会执行查询，优先在合适的只读/测试环境验证。

依据：Range optimization、IS NULL optimization、DELETE。

网络

C46 · P93：轮询不天然低效，中断也不天然“容易遗漏”

原题定位：“轮询效率低、等待长；中断容易遗漏、CPU 利用率不高”。

更正〔Linux 网络实现〕：中断在空闲/稀疏负载下可避免持续轮询；高包速下每包中断会带来调度开销，适度轮询、批处理可能更高效。Linux NAPI 结合事件通知和有预算的轮询，也支持 busy polling；不是二选一。事件丢失应归因于队列溢出、驱动/硬件或实现协议等具体原因，不能归结为中断这个机制。

验证：在同一工作负载测吞吐、P99、CPU 占用、软中断与丢包，观察 /proc/interrupts、/proc/softirqs、ethtool -S；不能只拿 CPU 利用率低当性能好或差。

依据：Linux kernel NAPI。

C47 · P93：TCP 不是固定客户端先关；SYN cookie 也不是先建半开 socket

原题定位：SYN cookie 被说成先“打开半开的套接字”；挥手被固定为客户端 FIN、客户端 TIME_WAIT；将 CLOSE_WAIT 解释成只要对方关闭。

更正〔TCP 协议/实现〕：三次握手同步两个方向的初始序号，并防止旧连接请求导致错误建立；ACK 的含义不能简化成应用已处理数据。SYN cookie 的关键是把可验证状态编码到 SYN-ACK 序号，在有效 ACK 到来前避免正常的半连接状态分配，并非先分配普通半开连接再获得保护；它也不是所有攻击的完整解法。

主动关闭方通常承担 TIME_WAIT，服务器也可主动关闭；FIN 与 ACK 可合并，关闭不保证抓包刚好四个报文。CLOSE_WAIT 表示本端收到 FIN 后尚未关闭本端发送方向，可能是合法半关闭，也可能是应用没收尾/资源泄漏。应按连接持有时间、业务和调用栈判断，不能只靠调小 TIME_WAIT 参数修复。

验证：Linux 用 ss -tanp state close-wait 定位进程，配合抓包观察 SYN/FIN 重传与半关闭，再审查连接关闭路径；Go HTTP 客户端还应按契约关闭响应 Body。协议依据是 RFC，系统参数及超时值另属 OS 实现。

依据：RFC 9293：TCP、RFC 4987：SYN flood 与 cookies。

Kafka

C48 · P95–96：ZooKeeper 依赖属于旧模式；4.0 起只支持 KRaft

原题定位：“ZooKeeper 在 Kafka 的作用”、通过 ZooKeeper 会话判断节点存活。

更正〔Kafka 版本〕：ZooKeeper 章节须标注历史模式。Kafka 3.x 有迁移阶段，4.0 已移除 ZooKeeper 模式，仅支持 KRaft；controller quorum 管理元数据，broker 向 controller 的注册/心跳参与存活判断。副本是否进入 ISR 与 broker 是否存活是不同判断：活着但跟不上复制的 follower 也可能被移出 ISR。

验证：核对实际版本及 process.roles、controller 配置、metadata.log.dir，用与发行版本配套的 kafka-metadata-quorum.sh ... describe --status 查看 quorum；不要在 4.x 故障排查中依赖 /brokers/ids。旧 ZooKeeper 集群应先走受支持的迁移流程，不能直接替换 4.0 二进制启动。

依据：Kafka 4.0 upgrading、KRaft 与 ZooKeeper 的差别。

C49 · P95–96：consumer group 不是由 ZooKeeper 直接分配；读副本也不绝对限 leader

原题定位：称 ZooKeeper 根据 partition/consumer 数做动态均衡；“生产者和消费者只与 leader 交互”。

更正〔Kafka 客户端协议/配置〕：现代 consumer group 由 broker 的 group coordinator 协调，不是客户端直接让 ZooKeeper 管每次分配。classic group 常由成员 leader 的 assignor 计算分配；4.0 的新 consumer 协议可用服务端分配，需区分所用协议。生产写入发往目标 partition leader，不存在全 topic 唯一的“broker leader”。消费默认常从 leader 读，但启用机架感知副本选择等配置时可从合适的 follower 读取。

验证：kafka-consumer-groups.sh --bootstrap-server HOST:9092 --describe --group GROUP；查看 group.protocol、client.rack、broker 的 replica.selector.class，再核对分区 leader 和客户端 fetch 路径。不能把默认值上升为协议永远禁止的行为。

依据：Kafka consumer configs、Kafka broker configs。

C50 · P95–96：同 key 与手动提交不是完整的顺序/不丢消息方案

原题定位：同 key 发到同分区即可保证业务顺序；send 成功加手动提交即可不丢消息；取到消息即自动提交。

更正〔Kafka 交付语义〕：分区日志有序不等于应用副作用按序完成；分区数或 partitioner 变更可能改变同 key 映射，异步并发处理也会乱序。非幂等生产者在多请求并发重试时可重排。消费者自动提交受客户端配置和周期影响，不是每抓取一条立即提交；手动提交前要确保对应分区之前所有记录的业务处理完成。

现代配置示例〔Kafka 4.0 Java 客户端属性〕：

# Producer；仍需处理发送回调/失败结果
acks=all
enable.idempotence=true
max.in.flight.requests.per.connection=5
# Consumer
enable.auto.commit=false

还需在 topic 上配置适当副本数与 min.insync.replicas；acks=all 不是等待全部配置副本都在线，也不意味着每条都强制 fsync。处理成功后提交下一条 offset 可获得通常的至少一次语义，崩溃窗口仍会重复；外部数据库写要幂等或协调提交。Kafka 事务可原子提交 Kafka 输出与消费位点，不会自动把任意外部数据库纳入同一事务。

验证：在发送后、业务成功后/提交前分别杀进程，检查丢失、重复和顺序；监控 ISR、发送错误和消费 lag。必须将“故障模型下的保证”写清，不能承诺绝对不丢。

依据：Producer configs：幂等/重试/顺序、Consumer configs：自动提交、Kafka design：交付语义。

C51 · P96–97：消费完成不触发日志删除；segment 名字是 base offset

原题定位：P96 称分段便于删除已消费文件、mmap 索引能避免 segment IO；P97 称新段以上一段最后 offset 命名、段大小恒等配置值。

更正〔Kafka 日志实现〕：保留策略通常按时间/大小删除旧 segment，或按 key 做 compaction，与某个 consumer 是否已消费无直接绑定；落后太久可以读不到已过保留期的数据。索引 mmap 可减少索引访问开销，读取日志数据仍需 page cache/磁盘 IO。段文件以前缀 base offset 表示该段的起始逻辑位置，不是复制上一段最后一个 offset。segment.bytes 是滚动约束，时间滚动、批大小、预分配和活跃段会使实际大小不等于配置值；压缩清理后 offset 也可能有空洞。

验证：用 kafka-configs.sh ... --describe 查看 topic 的 cleanup.policy、retention.ms/bytes、segment.bytes/ms；测试 topic 内比较多个 consumer group 的 offset 与实际日志保留范围。文件内容用发行版配套 dump-log 工具检查，不能拿索引映射成功当作数据已全部在内存。

依据：Kafka topic-level configs、Kafka 日志段源码。

复验范围与来源边界

各条均给出原题页码和官方资料；版本化源码只证明对应版本实现，不代替语言规范。没有提供环境和原始测量数据的 QPS、分钟数、GC 跨语言排名，以及 P66 的 etcd 故障根因，均不能据题库文字认定。产品文档可能随版本更新，历史行为应优先查对应版本的官方手册、发布说明或固定 tag 源码。

已在 go1.26.2 darwin/arm64 验证本页 13 个 Go 代码块：片段补齐 import、调用上下文后，均通过 go run -race -gcflags=all=-d=checkptr=2；HTTP 示例使用本地测试服务器。C14 的两个反例另行确认：含 slice 字段的 struct 比较编译失败，接口动态值为 slice 时比较触发预期 panic。该验证覆盖这些示例的执行路径，不代表所有 unsafe 用法或并发程序都已获证明。页面已通过 VitePress Markdown 解析、Vue SSR 编译及服务端渲染检查。

本页中的 Redis/MySQL/Kubernetes/Kafka 操作是可复验步骤；未连接读者的实际服务，也没有对其生产环境执行这些命令。包含占位符的命令、配置和 SQL 需按对应条目的前提替换后使用。