刻舟代码审查

同事推荐了这款，我拿自己手头的一个真实任务走了一遍完整流程，没有用示例数据。

`GET /v1/models` 返回的 `context_window` 在 gpt 系列上恒为 0，其它模型正常，我在代码里用它做上下文截断判断，结果所有 gpt 请求都被截成空字符串。

对 `top_k` 这类数值参数做范围校验，越界返回 400 并说明合法区间；预期不会再因为一个参数把服务打成 500。

413 只说 payload too large，不给上限也不给建议分批大小，体验很差。

用之前特意没看教程，想试试不看说明能不能自己走通。

用 Go SDK 的 `client.Do(ctx, req)`，超时设 30s，网络抖动时它内部还会重试 3 次并把我传的 ctx 用完，最终错误是 `context deadline exceeded`，我无法区分是首次超时还是重试预算耗尽。

对 `top_k` 这类数值参数做范围校验，越界返回 400 并说明合法区间；预期不会再因为一个参数把服务打成 500。

错误码和 HTTP 状态码没有稳定映射，同类问题有时 400 有时 422。

第一次打开是抱着试试看的心态，结果在第一步就卡了一会儿，后面才顺起来。

用 `openai@4.78.1` 的 `client.chat.completions.create` 设了 `stream: true`，长回复到第 300 个 chunk 左右会突然抛 `Premature close`，SDK 不重试也不带 request id，日志里只有一个 `ECONNRESET`。

对 `top_k` 这类数值参数做范围校验，越界返回 400 并说明合法区间；预期不会再因为一个参数把服务打成 500。

超时和重试行为不可控，SDK 既不暴露配置，也不回传 request id。

我当时的调用大概是这样：

try {
  const r = await client.chat.completions.create(req);
  return r.choices[0];
} catch (err) {
  const e = err as { status?: number; request_id?: string; message: string };
  logger.error("beehub call failed", {
    status: e.status,
    requestId: e.request_id ?? "missing",
    message: e.message,
  });
  throw err;
}

用之前特意没看教程，想试试不看说明能不能自己走通。

在 Docker 里跑同步任务，`BEEHUB_KEY` 通过 `-e` 注入却始终 401，容器内 `env` 能看到变量，SDK 读到的却是镜像里的旧 key，最后只能在启动脚本里重建 client。

在 429 响应头里明确 `Retry-After` 的单位并给出示例；希望客户端退避逻辑一次写对，减少无效重试和重复请求。

413 只说 payload too large，不给上限也不给建议分批大小，体验很差。