我在练习一个很小的 RAG 流程：抓取一篇网页文章。切成多个 chunk，写入内存向量库，再检索并让模型回答问题。流程不复杂，但第一次跑到“创建向量存储”就报错了：

TypeError: Cannot read properties of null at OpenAIEmbeddings.embedDocuments

这篇文章记录完整的排查方法。它不只是一次 API Key 问题，更是一次关于 Node.js 环境变量优先级 的实战复盘。

先看这个 RAG 小项目在做什么

项目使用 ESM，入口文件一开始就加载了 dotenv

import "dotenv/config";import { CheerioWebBaseLoader } from "@langchain/community/document_loaders/web/cheerio";import { RecursiveCharacterTextSplitter } from "@langchain/textsplitters";import { MemoryVectorStore } from "@langchain/classic/vectorstores/memory";import { ChatOpenAI,OpenAIEmbeddings } from "@langchain/openai";

后面的主链路可以概括为：

网页 URL -> CheerioWebBaseLoader 提取指定段落
-> RecursiveCharacterTextSplitter 递归切分
-> OpenAIEmbeddings 生成向量
-> MemoryVectorStore 建库与检索
-> ChatOpenAI 根据检索片段回答问题

RecursiveCharacterTextSplitter 配置了 chunkSize 与 chunkOverlap。它会优先按中文句末标点切分，无法自然切开时才继续尝试更细的边界。网页抓取和文档切分都成功了日志显示“文档分割完成，共 X 个 chunks”。

故障范围已经可以缩小：问题发生在第一笔 embedding 请求，而不是 loader 或 splitter。

这个 TypeError 为什么容易把人带偏

报错位置在依赖内部：

embeddings.push;老实说，

表面上看是 LangChain 对 null 做了数组访问。很多人会立刻怀疑：

• chunk 是不是空了？
• embedding 模型名是不是写错了？老实说，
• LangChain 版本是不是不兼容？

这些方向并非没有可能，但先改代码只会扩大噪音。话说回来，

主要痛点：batches 返回的 `batchResponse` 为 `null`。根源在于 API 实际没有返回有效数据。

直接请求 embedding 接口，看到真实响应

I wrote a minimal script that sends a single embedding request and prints only status and wher an embedding exists:

import "dotenv/config";不过，const base = process.env.OPENAI_BASE_URL.endsWith
process.env.OPENAI_BASE_URL
: `${process.env.OPENAI_BASE_URL}/`;const response = await fetch(`${base}embeddings`,{
method这方面，"POST",headers: {
"Content-Type": "application/json"。Authorization: `Bearer ${process.env.OPENAI_API_KEY}`,},body: JSON.stringify({
再看model，process.env.EMBEDDINGS_MODEL_NAME,input: "test",}),});const body = await response.json;console.log({
status这方面，response.status。hasEmbedding:
typeof body.data?.，.embedding?
. === "number",error: body.error?.message，?话说回来，body.msg?，null,});

The raw response turned out not to be an OpenAI‑compatible structure,but:

{
从"code"来看，-1,"msg": "旧转发链路已关闭","data": null
}

This explains internal TypeError：S​DK expects `data` to be an array of vectors,but gateway returned `null`. Moreover。gateway incorrectly used a successful HTTP status code,so “HTTP success ≠ business success”.

.env 被已有环境变量覆盖——根因揭秘

I originally thought provided `.env` wasn’t being read,yet first line of `index.mjs` clearly loads it:

import "dotenv/config";

The crucial detail is dotenv’s default behavior:

If Windows already has user‑level environment variables like OPENAI_BASE_URL and OPENAI_API_KEY,Node inherits m on startup. When dotenv runs it sees those keys are present and leaves m untouched. Consequently code actually contacts old gateway instead of service defined in `.env`.

从#痛点对比来看。文件值 vs 实际生效值

A quick check can confirm wher overriding happened. The snippet below prints **true** if value loaded from `.env` matches what Node is actually using:

import fs from "node:fs";
import dotenv from "dotenv";
const fileEnv = dotenv.parse);await import;for (const key of ) {
console.log;}

If any line shows false – especially for `OPENAI_BASE_URL` or `OPENAI_API_KEY` – stop tweaking LangChain code and hunt down source of those stale variables.

You can also inspect m directly in PowerShell:

Get-ChildItem Env:OPENAI_*
# 查看使用者级持久配置
::GetEnvironmentVariable
::GetEnvironmentVariable

至于#方法，让当前终端摆脱旧值

• #临时办法：

Remove-Item Env:OPENAI_BASE_URL -ErrorAction SilentlyContinue
Remove-Item Env:OPENAI_API_KEY -ErrorAction SilentlyContinue
node src/index.mjs #
运行

This clears variables for this session without affecting or projects.

• #永久办法：

1. 打开 “编辑账户的环境变量”。删除使用者变量中的 OPENAI_BASE_URL​、OPENAI_API_KEY​
2. 重启 VS Code、终端或任何运行 Node 的进程。
3. .env now wins.`

说到#第二类错误，真正的 API Key 问题

If you’ve cleared stale gateway,a new error may surface:

Incorrect API key provided
code的观点是，invalidapikey

This error is unrelated to previous TypeError. It means your request finally reached intended service。but key itself is wrong .

现象	请求实际到达的位置	优先排查方向
data: null → SDK 抛 TypeError	已关闭或不兼容的代理网关 被覆盖	检查 .env 与程序 env 是否一致
invalid_api_key	目标模型服务	Key 是否完整、是否过期、是否对应正确服务商
insufficient_quota 已通过认证的账户 检查额度、消费上限或组织配额
model_not_found / ... 目标模型服务	确认模型名、项目权限、组织配置是否匹配

#要不要在代码里强制覆盖？

`dotenv` 支持显式覆盖已有变量：

 import dotenv fro m" d ot en v ";说起来，dotenv . config;

But forcing an override isn’t always safe—CI/CD pipelines or container runtimes often inject production keys via environment variables. Overriding m locally could unintentionally push a development key into production.

推荐做法：

1. 本地项目把 Key 放进 .env 并确保其已加入 .gitignore。
2. 避免在 Windows 使用者环境变量中长期保留同名项目专用 Key。
3. 排错时打印 “是否存在 / 是否一致 / 长度或指纹”，绝不直接输出密钥原文。
4. 使用第三方兼容网关时额外校验响应结构是否真的符合 OpenAPI 标准。

先定位出错阶段 → 再看原始 API 响应 → 比较 .env 与 process.env → 最终判断 Key、额度或模型权限。

RAG 的 loader、切分、向量化和检索看似是一条业务链，但每一步都依赖配置和外部服务。遇到依赖内部的模糊错误时拆解请求链路往往比盯着堆栈反复改代码更快。

相关技术 LangChain,Node.js。dotenv,RAG,OpenAI Embeddings,阿里云百炼

。

---