Anthony 技术文档

Appearance

New API ​

最近查看了 QuantumNous/new-api，主要想确认一个隐私问题：用户通过 API Key 调用模型后，New API 的后台管理员能不能根据这把 Key 查到用户发送的消息，以及 AI 返回的完整内容。

本文基于 main 分支提交 9c97e78 的源码确认，重点区分 New API 自带的后台日志和服务器运维层面的额外记录手段。

先说结论 ​

如果使用的是原版 New API 的后台页面、日志接口和默认数据库：

可以查到某个 API Key 的调用记录和用量，但不能在后台直接查看完整的聊天正文。

具体区别如下：

查看内容原版后台是否能查到
哪个用户使用了这把 Key可以
调用时间、模型、渠道、分组可以
输入和输出 Token 数量可以
扣费、耗时、是否流式可以
Request ID、上游 Request ID可以
用户发送的完整消息默认不可以
AI 返回的完整回答默认不可以

这里的“默认不可以”非常重要。它表示 New API 自带的日志功能没有把完整请求和响应保存成可查询的聊天记录，并不表示服务器运营者在技术上绝对无法记录这些内容。

后台日志到底记录了什么 ​

New API 的消费日志结构主要是面向计费和运行统计的。日志字段包括：

  • TokenName、TokenId：使用的令牌名称和内部 ID；
  • ModelName：请求模型；
  • PromptTokens、CompletionTokens：输入和输出 Token 数；
  • Quota：本次消耗的额度；
  • UseTime：请求总耗时；
  • IsStream：是否使用流式响应；
  • ChannelId、Group：渠道和分组；
  • RequestId、UpstreamRequestId：请求链路标识；
  • Ip：是否记录 IP 取决于对应用户的 IP 日志设置；
  • Other：倍率、缓存 Token、模型价格、首字时间等统计信息。

管理员后台可以按 Token、用户名、模型、渠道、分组和 Request ID 筛选日志。因此管理员能够确认“这把 Key 在什么时候调用过什么模型、消耗了多少”，但这些字段本身不包含聊天正文。

Content 字段不是聊天内容 ​

日志表里确实有一个名为 Content 的字段，容易让人误以为这里保存了用户消息或 AI 回复。

实际情况是，普通文本调用完成后，New API 传入这个字段的是计费或模型说明，例如模型映射、固定价格、操作类型等信息。随后 RecordConsumeLog 将它和 Token、耗时、渠道等字段一起写入消费日志。

源码可以对照查看：

在这些日志参数里没有用于保存完整 messages、用户 prompt 或 AI 输出正文的字段。后台“日志详情”展示的也是 Token、计费、模型转换和耗时等信息，不是聊天窗口。

请求和响应是否经过 New API 服务器 ​

会经过。

New API 本质上是 API 网关和转发层。用户请求到达 New API 后，服务器需要读取请求体、解析或转换请求格式，再把请求发送给上游模型；上游返回响应后，New API 再将响应转发给用户，并根据响应统计 Token 和费用。

这意味着服务器在处理过程中能够接触到明文请求和响应，但“能够在内存中处理”与“把内容长期保存到后台日志”是两件事。

当前源码中的请求体存储主要是为了让多个适配器重复读取请求。请求结束后，中间件会清理这部分内存或临时文件：BodyStorageCleanup。它不是一个聊天记录功能。

不修改项目源码，运维还能不能记录正文 ​

需要分清“没有修改 New API 源码”和“服务器完全没有额外记录能力”这两个概念。

只使用 New API 自带功能 ​

如果运维只是登录 New API 后台，查看数据库里的消费日志：

查不到完整的用户消息和 AI 回复，只能查到调用元数据。

在外部增加记录手段 ​

如果运维拥有服务器或网关权限，即使不修改 New API 源码，也可能通过以下方式额外记录：

  • 修改 Nginx、OpenResty、API 网关或 WAF 的请求审计配置；
  • 在 New API 前面增加一个能够记录请求和响应的代理；
  • 在应用容器、主机或网络层部署额外的审计工具；
  • 查看上游模型供应商自己的请求记录或用量后台。

这些都不属于 New API 原版后台的功能，而是部署环境增加的能力。如果 New API 前面配置了 HTTPS 终止、请求体审计或响应采集，完整聊天内容就可能被外部组件保存下来。

因此更准确的说法是：

New API 原版后台默认不保存、也不能按 API Key 展示完整聊天内容；但拥有服务器、网关或上游账号权限的运营者，仍可能通过系统外部手段获得这些内容。

截图里的“首字”是什么 ​

日志列表中的“首字”不是用户消息的第一个字，也不是聊天内容的一部分。

它表示从请求开始，到客户端收到 AI 第一个输出 Token 或第一段流式响应之间的时间，英文通常叫：

  • TTFT：Time To First Token；
  • FRT：First Response Time。

例如：

text
首字：19.1s
耗时：20.0s

表示请求发出后约 19.1 秒收到了第一段 AI 输出，整个响应在约 20 秒时结束。首字之后剩余内容大约用了 0.9 秒完成。

New API 后端把首次响应时间写入 Other.frt 字段：log_info_generate.go。前端只对流式请求显示这个指标；非流式请求通常会显示“首字不适用”：timing-metrics-cell.tsx。

所以，“首字 19.1s”只能说明模型响应速度较慢，不能说明后台已经保存或展示了第一句话。

最终判断 ​

如果担心的是 New API 自带后台是否会把聊天内容展示给管理员，结论是：

默认不会。后台能看到 API Key 的调用和计费记录，但看不到完整的用户消息和 AI 回复。

如果担心的是服务器运营者能否接触聊天内容，则不能仅凭“没有修改项目源码”来判断安全性。New API 在转发请求时必然接触请求和响应，网关、主机审计、上游供应商日志等外部环节都可能保存正文。

New API 文档站使用的技术栈 ​

目标站点：docs.newapi.pro

前面分析的是 New API 网关本身的日志和隐私边界。下面再看它的官方文档站：只通过公开页面、静态资源和响应头，判断这个文档站使用的前端技术栈。

先给结论：这是一个以 Next.js（React）为底层框架、使用 Fumadocs 搭建文档界面的站点，内容层使用 MDX，样式主要采用 Tailwind CSS，交互组件中能看到 Radix UI 的特征。

一、先看 HTTP 响应头 ​

bash
curl -sSIL https://docs.newapi.pro/

响应中最有价值的字段不是 server，而是这些框架特征：

响应或资源特征说明
/_next/static/Next.js 构建后的静态资源目录
x-nextjs-prerender: 1页面由 Next.js 预渲染
vary: rsc使用 React Server Components（RSC）相关请求协商
x-nextjs-stale-timeNext.js 的页面缓存/重新验证信息
x-vercel-id请求链路中出现了 Vercel 的部署标识

这些信号共同指向 Next.js，而不是 VitePress、Docusaurus 或纯静态 HTML。

为什么不能只看 server ​

这个站点的响应头里还会出现 server: ESA。这更像是前置 CDN 或边缘网络的标识，不能据此判断网站是用 ESA 开发的。判断应用框架时，应优先看静态资源路径、RSC 标识和页面结构，CDN 只说明请求经过了哪一层网络。

二、从 HTML 找 Next.js 和 React ​

直接查看页面源码：

bash
curl -sSL https://docs.newapi.pro/en/ | head -c 20000

可以看到类似下面的资源：

html
/_next/static/chunks/...

页面还包含多个异步 JavaScript chunk，以及 React Server Components 常见的加载方式。这里的 /_next/ 路径是 Next.js 最容易识别的指纹之一。

这也说明它不是传统的“Markdown 编译成一堆 HTML 文件”的纯静态文档站，而是基于 React 组件渲染页面，并由 Next.js 负责路由、构建和服务端渲染/预渲染。

三、fd-* 和 nd-* 暴露了 Fumadocs ​

打开文档页源码：

bash
curl -sSL https://docs.newapi.pro/en/docs | rg -o \
  'id="[^"]+"|class="[^"]*fd-[^"]*"|class="[^"]*nd-[^"]*"'

能够看到这些标识：

text
id="nd-docs-layout"
id="nd-sidebar"
id="nd-toc"
class="fd-default-layout"
class="bg-fd-background"
class="text-fd-muted-foreground"

fd 和 nd 不是普通业务命名，而是 Fumadocs UI 的典型命名空间。Fumadocs 是建立在 Next.js 之上的文档框架，提供了文档站常见的能力：

  • 左侧文档导航和折叠目录
  • 右侧目录（Table of Contents）
  • 文档页面布局
  • 搜索入口
  • 暗色模式和主题变量
  • MDX 内容渲染

所以更准确的说法不是“这个站用了一个 Fumadocs 模板”，而是：Next.js 提供应用框架，Fumadocs 提供文档站 UI 和内容组织方式。

四、MDX、Tailwind CSS 和 Radix UI ​

页面源码里可以看到大量 Markdown 风格内容和 mdx 相关输出，说明文档正文很可能以 MDX 文件维护。MDX 允许在 Markdown 中嵌入 React 组件，比单纯 Markdown 更适合做交互式文档。

样式类名也很明显：

text
flex
rounded-lg
border
text-sm
bg-fd-background
text-fd-muted-foreground

这类原子化工具类符合 Tailwind CSS 的使用方式。fd-* 则是 Fumadocs 在 Tailwind 主题变量之上的语义化封装。

导航菜单、弹窗、语言选择器等交互区域还能看到 data-radix-*、radix- 等属性，说明部分无障碍交互组件使用了 Radix UI。图标则能看到 Lucide 的 lucide-* 类名。

五、最终技术栈 ​

层次技术判断依据
应用框架Next.js/_next/static、x-nextjs-prerender、RSC 响应头
UI 框架ReactReact Server Components 和 React chunk 加载方式
文档框架Fumadocsnd-*、fd-* 布局与主题类名
内容格式MDX文档页面的 MDX 输出特征
CSS 方案Tailwind CSS大量原子化 utility class
交互组件Radix UIdata-radix-* 和 radix- 属性
图标Lucidelucide-* 图标类名
边缘/部署线索ESA CDN + Vercel 标识server: ESA、x-vercel-id

六、这类判断的边界 ​

通过公开页面可以可靠判断“使用了什么前端框架和文档 UI”，但不能确认所有构建细节，例如：

  • Next.js 的具体版本号
  • 是否使用了某个私有组件库
  • MDX 文件在仓库中的真实目录结构
  • Vercel 是否是最终部署平台，还是只在链路中提供了部分服务

除非项目公开仓库或构建产物进一步暴露 package.json、Source Map 等信息，否则不应把推测写成确定事实。

总结 ​

New API 文档站的技术栈可以概括为：

text
Next.js
└── React Server Components
    └── Fumadocs
        ├── MDX
        ├── Tailwind CSS
        ├── Radix UI
        └── Lucide

以后分析陌生网站时，可以按这个顺序排查：先看响应头，再看静态资源路径，最后看 DOM 的命名空间和组件属性。三类证据互相印证，比单独依赖某个在线识别工具更可靠。

参考链接：New API 官方文档 · New API GitHub

技术笔记

Copyright © 2026 Anthony