Go context 怎么从父截止时间拆分子任务预算

父 Context 已经带有截止时间时，子任务不要再机械写一个固定的 5*time.Second。更稳妥的做法是读取父 Deadline，计算当前剩余时间，先扣掉返回、日志和资源释放需要的余量，再把可用部分分给子任务。子 Context 仍然以父 Context 为 parent，因此无论计算结果多大，都不会越过更早的父截止时间。

推荐公式：子任务预算 = min((父剩余时间 - 收尾余量) × 分配比例, 子任务最大值)。剩余时间不足时直接拒绝启动，而不是创建一个几乎立即超时的调用。

一、先把父 Deadline 换算成可分配余额

Deadline() 返回绝对时间和一个 ok 标记。真正能分配的是 time.Until(deadline)，因为处理链前面的解析、鉴权或排队已经消耗了一部分总预算。假设父级还剩 900 毫秒，预留 150 毫秒收尾，则可分配余额只有 750 毫秒。

二、封装一个可复用的预算函数

下面的函数处理三件事：父级无 Deadline 时使用业务最大值；父级有 Deadline 时扣除余量；可用时间小于等于零时不再启动子任务。

func childBudget(
	parent context.Context,
	share float64,
	reserve time.Duration,
	max time.Duration,
) (context.Context, context.CancelFunc, bool) {
	deadline, ok := parent.Deadline()
	if !ok {
		// 父级没有截止时间时，仍用业务上限约束子任务
		ctx, cancel := context.WithTimeout(parent, max)
		return ctx, cancel, true
	}

	available := time.Until(deadline) - reserve
	if available  max {
		budget = max // 宽松父级也不能突破单任务上限
	}
	if budget 

share 通常取 0 到 1 之间。生产代码可以进一步在配置加载阶段约束范围，避免负数或大于 1 的比例进入运行路径。

三、为不同依赖设置比例和硬上限

调用时，把比例和最大值写成业务策略，而不是散落在各个函数中的魔法数字：

dbCtx, cancel, ok := childBudget(ctx, 0.45, 150*time.Millisecond, 800*time.Millisecond)
if !ok {
	return errors.New("父请求剩余时间不足") // 不再启动数据库查询
}
defer cancel() // 查询提前结束时释放子 Context 资源

rows, err := repo.Query(dbCtx)
if err != nil {
	return fmt.Errorf("query repository: %w", err)
}
defer rows.Close() // 及时释放结果集占用的连接

如果子任务串行执行，每次都应重新调用预算函数，因为前一个任务已经消耗了时间。如果多个子任务并行，它们可以共享同一个父截止时间，但比例不是简单相加后的执行顺序；还要考虑连接池、并发数和下游容量。

四、三个容易误判的边界

• 子超时不能延长父级：WithTimeout(parent, 2*time.Second) 遇到只剩 300 毫秒的父级，子 Context 仍会在更早的父 Deadline 结束。
• 父级没有 Deadline：不要返回无限期 Context，使用当前依赖的最大值作为兜底。
• 余量不是浪费：如果把全部剩余时间交给下游，请求很可能在序列化或写回响应时才超时，最终仍然失败。

相关问题

多个并行子任务的比例必须加起来等于 1 吗？

不必。比例描述各任务相对父余额的超时上限，并行任务会同时消耗墙钟时间；更重要的是为每个依赖设置合理硬上限和并发限制。

为什么计算预算后还要以父 Context 创建子 Context？

这样父请求主动取消时，所有子任务仍能立即收到取消信号；预算函数只缩短等待时间，不应切断父级取消传播。