不会干扰，但易误以为并行可绕过超时；t.parallel()仅影响调度，实际超时由go test -timeout或context.withtimeout控制，子测试共享父测试超时上下文，超时后整棵子树被强制终止。
测试函数里直接用 t.Parallel() 会干扰超时判断吗？
不会干扰，但容易让人误以为并行执行能“绕过”超时。实际上 t.Parallel() 只影响测试调度顺序，go test -timeout=5s 或 t.Run() 内部的 context.WithTimeout 才真正起作用。并行测试共享父测试的超时上下文，一旦超时，整个子测试树会被强制终止。
- 父测试设了
-timeout=3s，即使子测试调用t.Parallel()，它仍会在 3 秒后被中断 - 若在子测试内手动创建新 goroutine 且未监听
t.Cleanup或context.Done()，可能引发 goroutine 泄漏 - 推荐做法：对耗时操作统一用
context.WithTimeout(t.Context(), 2*time.Second)，而非依赖全局-timeout
用 testify/assert 时如何避免断言卡死导致超时？
testify/assert 本身不阻塞，但常和 time.Sleep、通道等待、HTTP 轮询等组合使用，这些才是超时元凶。关键不是换断言库，而是控制等待逻辑本身的生命周期。
- 别写
for { assert.Equal(t, "ready", getStatus()) }这种无限循环——应加计数或超时控制 - 正确姿势是：用
assert.Eventually(t, func() bool { return getStatus() == "ready" }, 3*time.Second, 100*time.Millisecond) - 如果自己手写轮询，必须用
select监听t.Context().Done()，否则测试无法响应超时信号
go test -timeout 和 t.Deadline() 哪个优先级更高？
go test -timeout 是进程级硬限制，触发时直接发送 SIGQUIT 终止整个 go test 进程；t.Deadline() 只是返回一个时间点，需你主动检查。两者不冲突，但行为完全不同。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
-timeout=1s下，哪怕你在测试里调用time.Sleep(2 * time.Second)，1 秒后测试进程就被杀掉，不会等到 sleep 结束 -
t.Deadline()返回的是time.Time，适合做轻量级截止判断，比如if time.Now().After(t.Deadline()) { t.Fatal("deadline exceeded") } - 真正可控的超时应在业务逻辑层实现，例如 HTTP client 设置
Timeout字段，数据库 query 设置Context，而不是只靠-timeout挡枪
HTTP handler 测试中如何模拟请求超时并验证错误路径？
不能只测 “正常返回”，必须显式构造超时场景。核心是让 handler 内部的下游调用（如 http.Client.Do）在指定时间内失败，并确保 handler 正确透传或处理该错误。
- 用
http.TimeoutHandler包裹 handler，设置500 * time.Millisecond，再发请求观察是否返回 503 - 更精准的做法：mock 下游 client，让它在
RoundTrip中根据req.Context().Done()返回context.DeadlineExceeded - 注意：handler 里若用
time.Sleep模拟慢响应，要改成select { case ，否则无法响应取消
测试超时控制最易被忽略的一点：超时不是“加个 flag 就完事”，而是从测试启动、goroutine 创建、外部调用、到 cleanup 全链路都要感知 context 生命周期。尤其当测试涉及 channel、timer、第三方 client 时，漏掉任意一环都可能导致测试挂住或假成功。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
