Go中唯一被标准库和第三方包认可的带截止期限信号机制是context.Context，必须用context.WithDeadline或context.WithTimeout创建子context，函数签名应接收ctx context.Context作为第一个参数并在每个阻塞点响应ctx.Done()。
用 context.Context 传截止时间，不是用 time.Timer 或 time.AfterFunc
Go 中唯一被标准库和绝大多数第三方包认可的、带截止期限的信号传递机制是 context.Context。自己封装 time.Timer 或靠 select + time.After 手动控制，会导致上下文无法取消、无法传递值、无法链式传播，且与 http.Client、database/sql、grpc 等所有主流库不兼容。
关键点：截止时间必须通过 context.WithDeadline 或 context.WithTimeout 创建子 context，而不是把 time.Time 或 time.Duration 当参数传。
-
context.WithTimeout(parent, 5*time.Second)最常用，相对超时更易测试和调试 -
context.WithDeadline(parent, time.Now().Add(5*time.Second))适合需要对齐某个绝对时间点的场景（如分布式调度） - 永远不要在函数签名里加
deadline time.Time参数——这会让调用方绕过 context 取消链，也破坏了可组合性
函数签名必须接收 ctx context.Context，且在入口处检查是否已取消
任何可能阻塞或耗时的操作，只要支持 deadline，就必须把 ctx 作为第一个参数。这不是风格问题，而是能否被上层统一中断的分水岭。
常见错误：只在函数开头调用 ctx.Err() 检查一次，然后就忽略后续阻塞点。正确做法是每个可能挂起的地方都主动响应 ctx.Done()。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- HTTP 请求：直接传
ctx给http.NewRequestWithContext，别用旧版http.NewRequest+ 手动设置 header - 数据库查询：用
db.QueryContext而非db.Query；stmt.ExecContext同理 - 自定义 channel 操作：用
select { case ，而非轮询或忽略 <code>ctx.Done() - 注意：
ctx.Err()返回nil表示未取消，返回context.Canceled或context.DeadlineExceeded时必须立即返回，不能继续执行
避免在 goroutine 内部直接创建带 deadline 的 context
如果一个函数启动 goroutine 去做异步工作，它应该把接收到的 ctx 传进去，而不是在 goroutine 里调用 context.WithTimeout(context.Background(), ...)。后者会切断取消链，导致父级 cancel 无效。
典型反例：HTTP handler 里 spawn goroutine 处理后台任务，却用独立 timeout —— 这会让整个请求被 cancel 后，后台任务还在跑。
- 正确做法：把入参
ctx传给 goroutine，并在内部用select监听ctx.Done() - 若需额外超时（比如后台任务最长再跑 3 秒），用
context.WithTimeout(ctx, 3*time.Second)，让新 context 继承父 cancel 信号，再叠加自己的 deadline - 切忌用
context.WithCancel(context.Background())+ 手动控制——这等于放弃 context 的层级传播能力
context.WithValue 和 deadline 无关，别混用
context.WithValue 是为传递请求范围的元数据（如用户 ID、trace ID）设计的，不是用来“增强” deadline 功能的。有人试图把超时阈值塞进 context 值里，再手动计算时间，这是严重误用。
后果：失去标准错误类型（context.DeadlineExceeded）、无法被中间件识别、难以调试、与 net/http 等库的 timeout 日志不一致。
- deadline 必须由
WithDeadline/WithTimeout创建，其行为由 runtime 内置调度器保障 -
ctx.Value只能存不可变的小对象，且 key 类型必须是 unexported 类型（防止冲突），和超时逻辑完全正交 - 真正需要动态调整 deadline 的场景极少；多数时候是设计问题——比如本该拆成多个独立 context 的操作，却被塞进同一个 long-running 函数里
ctx，或者在 defer 里忘记检查 ctx.Err()。deadline 不是 set-and-forget 的配置项，它是贯穿整个调用栈的控制流信号。 
