2026年 Node.js 大模型API接入 示例代码：从环境配置到流式输出

2026年 Node.js 大模型API接入 示例代码：从环境配置到流式输出

在 Node.js 里接大模型接口，真正卡住新手的通常不是模型能力，而是环境、鉴权、Base URL 和流式输出这四件小事。

本文按“环境准备 → 最小可用调用 → 流式输出 → 排错与多模型管理”的顺序，把 Node.js 大模型API接入拆成可以逐步验证的步骤。每一步都以你所用平台控制台当前显示的信息为准，避免照抄旧教程里的接口地址和模型名称。

一、写代码前必须确认的三件事

先确认下面三项信息。它们决定了报错时你能否快速定位问题，而不是在业务代码里反复改来改去。

1. 运行环境与依赖

建议使用仍在维护周期内的 Node.js LTS 版本（18 及以上），并确认 npm 能正常拉取依赖。主流兼容 OpenAI 协议的 SDK 在这类版本上都能正常工作，不需要额外的构建工具。

node -v
npm -v
npm init -y
npm install openai dotenv

2. API Key、Base URL 与模型名称

API Key 决定身份，Base URL 决定请求发往哪里，模型名称决定你实际调用哪一个模型。这三项都属于会随时更新的信息，必须以控制台和文档当前展示的值为准。如果你打算用一个接口地址接入多个模型，可以先到 通联AI中转站 的控制台核对 Base URL、可用模型名称与兼容协议，再回来改代码，通常比逐个平台试错更省时间。

3. 把密钥放进环境变量

不要硬编码 Key，也不要把带 Key 的文件提交到代码仓库。放进 .env，由进程读取即可。

API_KEY=你的Key
BASE_URL=控制台显示的接口地址
MODEL=控制台显示的模型名称

二、先跑通一次最小调用

不要一上来就写流式。先用非流式请求验证鉴权、地址和模型名称是否正确，这样出错时排查范围只有配置项。

import OpenAI from 'openai';
import 'dotenv/config';

const client = new OpenAI({
  apiKey: process.env.API_KEY,
  baseURL: process.env.BASE_URL,
});

const res = await client.chat.completions.create({
  model: process.env.MODEL,
  messages: [
    { role: 'system', content: '你是一个简洁的技术助手。' },
    { role: 'user', content: '用三句话解释什么是流式输出。' },
  ],
});

console.log(res.choices[0].message.content);

如果这一步能返回正常内容，说明鉴权和路由已经通了；如果出现 401、404 或提示模型不存在，问题基本都在配置项上，而不是业务逻辑。建议日志里只记录模型名称、耗时和错误码，不要把 Key 和完整提示词一起打进日志。

三、流式输出：从一次性返回到逐块渲染

1. 打开 stream 参数

流式输出的关键只有两处：请求时打开 stream，响应时逐块消费并立即输出。

const stream = await client.chat.completions.create({
  model: process.env.MODEL,
  stream: true,
  messages: [{ role: 'user', content: '写一段两百字的接口说明。' }],
});

for await (const chunk of stream) {
  const text = chunk.choices[0]?.delta?.content || '';
  process.stdout.write(text);
}

2. 在 Web 服务里转发给前端

如果用 Express 或 Fastify 之类的框架，可以把每个增量片段按 SSE 推给浏览器。要点有三个：响应头要声明事件流类型；服务端不要做多余缓冲；结束时显式结束响应，避免连接长期挂起。

res.setHeader('Content-Type', 'text/event-stream');
res.setHeader('Cache-Control', 'no-cache');
res.setHeader('Connection', 'keep-alive');

for await (const chunk of stream) {
  const text = chunk.choices[0]?.delta?.content || '';
  if (text) res.write('data: ' + JSON.stringify({ text }) + '\n\n');
}

res.write('data: [DONE]\n\n');
res.end();

流式输出只是把结果分成多次返回，模型本身的推理成本、并发占用和计费方式并没有因此改变。真正需要额外关注的是超时设置、连接保持，以及中途断开后的重试策略。

3. 流式场景最容易踩的坑

• 超时设置过短：长回答在流式下总时长更长，超时值要按最慢场景设定，而不是按平均值。
• 没有处理空增量：部分分片的 delta 可能为空，拼接前要做空值判断。
• 字段取错：流式分片的结构与非流式不同，不要沿用 message.content 的取值路径。
• 忘记结束响应：前端会一直显示加载状态，也会占用服务端连接。
• 模型名称写错：这类错误经常返回 404 而不是参数错误，容易被误判为网络问题。

四、从单模型调用走向统一管理

当项目里开始同时用到对话、图像、视频、语音等不同类型的模型，麻烦往往不是写调用代码，而是维护多套 Key、多个地址和多份配额。更省事的做法是先把需要的能力列成清单，再逐一核对平台是否提供对应模型与兼容协议。

例如在 通联AI中转站 的模型广场与文档里，可以先确认各类模型的名称、协议方向与接入说明，再决定是否把它们的 Base URL 和 API Key 收敛到一套配置上，减少多平台切换带来的维护量。

代码层面的建议很简单：把 Base URL、模型名称、超时和重试策略都抽成配置项，不要在业务代码里散落硬编码。这样更换模型或调整供应商时只需要改一处配置，回归测试的范围也可控。这也是 Node.js 大模型API接入项目后期最容易忽略、却最影响维护效率的一步。

示例代码跑通之后，下一步就是把它接到真实业务里。你可以到通联注册账号，获取 API Key，在控制台确认 Base URL 与模型名称，用本文的最小示例完成第一次调用，再切换到流式输出做一次端到端测试。

注册通联后获取 API Key 并完成首次调用