Go NATS Go 客户端怎样给请求响应设置截止时间

Go NATS 客户端给请求响应设置截止时间，最直接的写法是给 nc.Request 传入一个 time.Duration；如果还要让上游取消、统一传递截止时间，就用 context.WithTimeout 配合 nc.RequestWithContext。两种方式都要把“没有收到响应”当成可处理的错误，而不是让请求无限等待。

官方地址：https://nats.io/

先选对 NATS 的请求接口

NATS 的 request/reply 是一次请求对应一个响应的模型。当前 Go 客户端同时提供 Request(subj, data, timeout) 和 RequestWithContext(ctx, subj, data)：前者把等待上限写在调用点，后者把等待上限放进 context。官方 API 文档对 Request 的描述包含“没有正确收到消息时返回超时错误”，而 RequestWithContext 则等待 context 或响应先结束。

因此，可以先按调用场景做选择：没有上游取消语义、只需要固定 800 毫秒的内部调用，用 Request 更直白；HTTP 请求、任务执行或批处理已经有 context 时，优先沿用它的 deadline，避免每一层各自计时。

固定时长：直接给 Request 设置响应上限

只关心“这次请求最多等多久”时，可以直接把时长交给 Request。下面的示例让请求最多等待 800 毫秒，并把返回消息和错误分开处理。代码中的订阅者只是示意，真实服务可以运行在另一个进程或服务中。

package main

import (
    "fmt"
    "time"

    "github.com/nats-io/nats.go"
)

func requestOnce(nc *nats.Conn, subject string, payload []byte) ([]byte, error) {
    // 把等待上限集中在调用点，避免无响应时一直阻塞。
    msg, err := nc.Request(subject, payload, 800*time.Millisecond)
    if err != nil {
        // 超时、连接关闭或 subject 权限问题都从这里返回给上层。
        return nil, fmt.Errorf("NATS request %q: %w", subject, err)
    }
    // 复制响应数据，避免把消息对象的生命周期带到调用方之外。
    return append([]byte(nil), msg.Data...), nil
}

固定时长的优点是读代码时一眼能看到等待上限；代价是上游无法在更早结束时通知这一层。比如 HTTP 客户端已经断开，但 NATS 请求仍可能继续等到 800 毫秒，这时就应该改用带 context 的接口。

可取消上下文：用 WithTimeout 统一截止时间

RequestWithContext 的关键不是把 time.Duration 换了一个名字，而是让请求共享一条可取消的控制线。官方示例使用 context.WithTimeout 创建两秒 deadline；调用结束后必须执行 cancel，及时释放与该 context 相关的计时器资源。

package main

import (
    "context"
    "errors"
    "fmt"
    "time"

    "github.com/nats-io/nats.go"
)

func requestWithDeadline(parent context.Context, nc *nats.Conn) ([]byte, error) {
    // 子 context 让本次 NATS 请求最多占用 800 毫秒。
    ctx, cancel := context.WithTimeout(parent, 800*time.Millisecond)
    defer cancel() // 无论成功还是失败，都回收计时器资源。

    msg, err := nc.RequestWithContext(ctx, "orders.lookup", []byte("order-42"))
    if err != nil {
        // 区分 deadline 到期和上游主动取消，便于调用方决定是否重试。
        switch {
        case errors.Is(err, context.DeadlineExceeded):
            return nil, fmt.Errorf("订单查询超时: %w", err)
        case errors.Is(err, context.Canceled):
            return nil, fmt.Errorf("订单查询已取消: %w", err)
        default:
            return nil, fmt.Errorf("NATS request failed: %w", err)
        }
    }
    // 响应数据脱离 Msg 后再交给业务层，边界更容易管理。
    return append([]byte(nil), msg.Data...), nil
}

如果 parent 已经有更早的 deadline，子 context 不会把它延长；实际截止时间取更早的那个。这样 HTTP 请求、队列任务和 NATS 调用可以自然地共享剩余时间，而不是层层叠加等待。

超时、取消与无响应者不要混成一种错误

请求失败后先判断错误来源，再决定日志级别和重试策略。context.DeadlineExceeded 表示 deadline 到期，context.Canceled 通常表示上游不再需要结果；如果服务端明确告诉客户端没有响应者，客户端还可能得到 NATS 的 ErrNoResponders。连接关闭、断开和权限错误则属于连接或部署问题，不能靠盲目延长 timeout 解决。

几个容易踩到的上下文边界

• 不要传 nil context。RequestWithContext 需要有效 context；nil 不是“永不超时”的安全写法。
• 要有 deadline。当前客户端的上下文相关接口要求 deadline，使用 context.WithCancel 但没有截止时间时，应该先确认接口语义，不要把取消和超时混为一谈。
• 不要复用已经结束的 context。一次请求结束后，下一次调用应创建新的子 context；已到期的 context 会让后续请求立即失败。
• 不要把单次响应当成流。RequestWithContext 期待一个响应；需要持续接收消息时，应使用订阅接口并单独设计订阅生命周期。
• 不要用加大 timeout 掩盖服务问题。如果响应本身需要排队、重试或下游调用，应该拆出各阶段耗时，再分配总 deadline。

落地时可以这样定规则

在业务代码中，建议让负责发起请求的函数接收 context.Context，只在边界处补充一个更短的子 deadline；统一包装错误时保留原始 error，调用方才能用 errors.Is 做判断。固定时长适合简单、封闭的内部调用；可取消上下文适合已经存在请求链路的服务。无论选哪种方式，都要明确“响应没有在截止时间前到达”之后是否允许重试，以及重试是否会重复提交业务动作。

常见问题

Go NATS 的 Request 第三个参数是什么？

它是 time.Duration 类型的等待上限，例如 800*time.Millisecond。超时后调用返回错误，不会继续无限等待。

RequestWithContext 能不能直接传 context.Background？

不建议。背景 context 没有截止时间，也没有取消来源；请求链路应传入带 deadline 的父 context，或用 context.WithTimeout 创建子 context。

超时后能不能马上重试？

要先判断请求是否幂等、服务端是否可能已经处理但响应丢失，以及剩余总 deadline 是否足够。查询类请求通常更容易重试，写入类请求应先设计幂等键或去重策略。

为什么只把 timeout 调大仍然失败？

因为失败可能来自没有响应者、连接断开、权限错误或上游取消，而不只是服务端慢。先按错误类型分流，再决定调整服务、连接还是请求预算。