DS2API citation/reference零基vs一基序号解析细节全解【免费下载链接】ds2apiDeepSeek-Compatible Middleware Interface: A technical exploration project in Go, focusing on high-concurrency protocol adaptation. It serves as a reference implementation for converting diverse web protocols into standardized formats.项目地址: https://gitcode.com/GitHub_Trending/ds/ds2apiDS2API 是一款基于 Go 的DeepSeek 兼容中间件负责把上游 SSE 流转换成 OpenAI / Claude / Gemini 等标准协议。开启联网搜索后回答里会出现[citation:1]、[reference:0]这类引用序号标记——但上游的序号到底是零基0 开始还是一基1 开始DS2API 用双流收集 冲突仲裁的策略统一处理了这个问题。本文带你从新手视角看懂这条引用解析链路的每个细节。 一分钟看懂引用标记的序号陷阱DeepSeek 上游流里引用信息分散在两处来源示例序号体系回答正文中的标记[citation:1]、[reference:0]可能是零基也可能是一基SSE 元数据urlcite_index片段附带的来源链接同样存在零基/一基两种版本麻烦在于正文标记的起点和元数据cite_index的起点未必一致。DS2API 的解法分两步——先在流中收集最后再替换每一步都对零基/一基做了防御。 第一步SSE 流中的引用收集核心实现在 internal/sse/citation_links.go收集器维护两条轨道ordered按出现顺序记录每条http(s)来源 URL隐含一基序号第 i 条就是序号 iexplicitRaw记录元数据里显式的cite_index → url映射。真正的零基/一基判定发生在 buildNormalizedExplicit()默认按一基处理正数索引原样保留零索引被跳过一旦出现过cite_index 0即 hasZeroIdx 被置位说明上游大概率使用零基体系于是给每个索引追加一个1 偏移候选冲突仲裁同一目标序号同时存在原始值和1 偏移值时由 preferURLForIndex() 裁决——谁的 URL 与ordered中该序号位置的实际出现顺序吻合就选谁。 为什么用出现顺序当裁判因为来源 URL 在流里的到达顺序天然等于它在正文中的引用顺序是最可靠的锚点。最后由 build() 输出显式索引优先空缺位置用ordered按一基idx i 1补位。最终产物是一张一基的map[序号]URL。✍️ 第二步把序号标记替换成 Markdown 链接替换逻辑在 internal/httpapi/openai/shared/citation_links.go用正则忽略大小写、允许冒号后空格匹配[citation:N]和[reference:N]两种标记查表时默认lookupIdx N一基直查关键细节如果正文里出现了[reference:0]说明 reference 标记是零基的则仅对reference标记做N 1偏移查表而[citation:N]仍按一基处理——两种标记各自独立判定基线替换后展示数字保留原文零基的[reference:0]会渲染成0不强行改成 1避免与正文语义错位查不到的序号原样保留绝不瞎配链接。这些行为都有对应测试用例兜底见 citation_links_test.go其中零基 reference 与一基 citation 混用的用例最能说明设计意图。 流式输出时为什么标记会被暂时隐藏流式场景有个尴尬点正文先到、引用元数据可能晚于FINISHED状态到达consumer.go 特意在结束后继续扫描元数据直到[DONE]。因此在链接表就绪前DS2API 会先剥掉未定型的标记Go 端StripReferenceMarkers()流式面默认开启浏览器端 JS 代理做了同样的事stripReferenceMarkersText() 用相同正则清洗。流结束后统一走第二步替换用户最终看到的是干净的可点击链接。✅ 新手自查清单cite_index从 0 开始 → 上游零基靠hasZeroIdx触发 1 候选只有正数索引 → 按一基直用两种候选冲突 → 以 URL 出现顺序为仲裁[reference:0]只影响 reference 查表偏移citation 不动查不到链接的序号 → 保留原文流式中先隐藏。 相关源码与文档收集器零基/一基判定核心internal/sse/citation_links.go标记替换正则 偏移查表internal/httpapi/openai/shared/citation_links.go流式标记剥离internal/textclean/reference_markers.goJS 端同款清洗internal/js/chat-stream/sse_parse_impl.js单元测试internal/httpapi/openai/citation_links_test.go架构总览docs/ARCHITECTURE.md读懂这套双轨收集 基线仲裁的设计你就能理解 DS2API 如何在多种上游变体下稳定地把引用序号还原成正确的来源链接。【免费下载链接】ds2apiDeepSeek-Compatible Middleware Interface: A technical exploration project in Go, focusing on high-concurrency protocol adaptation. It serves as a reference implementation for converting diverse web protocols into standardized formats.项目地址: https://gitcode.com/GitHub_Trending/ds/ds2api创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/16 11:14:45 · 阅读 1.2k DS2API citation/reference零基vs一基序号解析细节全解
DS2API citation/reference零基vs一基序号解析细节全解【免费下载链接】ds2apiDeepSeek-Compatible Middleware Interface: A technical exploration project in Go, focusing on high-concurrency protocol adaptation. It serves as a reference implementation for converting diverse web protocols into standardized formats.项目地址: https://gitcode.com/GitHub_Trending/ds/ds2apiDS2API 是一款基于 Go 的DeepSeek 兼容中间件负责把上游 SSE 流转换成 OpenAI / Claude / Gemini 等标准协议。开启联网搜索后回答里会出现[citation:1]、[reference:0]这类引用序号标记——但上游的序号到底是零基0 开始还是一基1 开始DS2API 用双流收集 冲突仲裁的策略统一处理了这个问题。本文带你从新手视角看懂这条引用解析链路的每个细节。 一分钟看懂引用标记的序号陷阱DeepSeek 上游流里引用信息分散在两处来源示例序号体系回答正文中的标记[citation:1]、[reference:0]可能是零基也可能是一基SSE 元数据urlcite_index片段附带的来源链接同样存在零基/一基两种版本麻烦在于正文标记的起点和元数据cite_index的起点未必一致。DS2API 的解法分两步——先在流中收集最后再替换每一步都对零基/一基做了防御。 第一步SSE 流中的引用收集核心实现在 internal/sse/citation_links.go收集器维护两条轨道ordered按出现顺序记录每条http(s)来源 URL隐含一基序号第 i 条就是序号 iexplicitRaw记录元数据里显式的cite_index → url映射。真正的零基/一基判定发生在 buildNormalizedExplicit()默认按一基处理正数索引原样保留零索引被跳过一旦出现过cite_index 0即 hasZeroIdx 被置位说明上游大概率使用零基体系于是给每个索引追加一个1 偏移候选冲突仲裁同一目标序号同时存在原始值和1 偏移值时由 preferURLForIndex() 裁决——谁的 URL 与ordered中该序号位置的实际出现顺序吻合就选谁。 为什么用出现顺序当裁判因为来源 URL 在流里的到达顺序天然等于它在正文中的引用顺序是最可靠的锚点。最后由 build() 输出显式索引优先空缺位置用ordered按一基idx i 1补位。最终产物是一张一基的map[序号]URL。✍️ 第二步把序号标记替换成 Markdown 链接替换逻辑在 internal/httpapi/openai/shared/citation_links.go用正则忽略大小写、允许冒号后空格匹配[citation:N]和[reference:N]两种标记查表时默认lookupIdx N一基直查关键细节如果正文里出现了[reference:0]说明 reference 标记是零基的则仅对reference标记做N 1偏移查表而[citation:N]仍按一基处理——两种标记各自独立判定基线替换后展示数字保留原文零基的[reference:0]会渲染成0不强行改成 1避免与正文语义错位查不到的序号原样保留绝不瞎配链接。这些行为都有对应测试用例兜底见 citation_links_test.go其中零基 reference 与一基 citation 混用的用例最能说明设计意图。 流式输出时为什么标记会被暂时隐藏流式场景有个尴尬点正文先到、引用元数据可能晚于FINISHED状态到达consumer.go 特意在结束后继续扫描元数据直到[DONE]。因此在链接表就绪前DS2API 会先剥掉未定型的标记Go 端StripReferenceMarkers()流式面默认开启浏览器端 JS 代理做了同样的事stripReferenceMarkersText() 用相同正则清洗。流结束后统一走第二步替换用户最终看到的是干净的可点击链接。✅ 新手自查清单cite_index从 0 开始 → 上游零基靠hasZeroIdx触发 1 候选只有正数索引 → 按一基直用两种候选冲突 → 以 URL 出现顺序为仲裁[reference:0]只影响 reference 查表偏移citation 不动查不到链接的序号 → 保留原文流式中先隐藏。 相关源码与文档收集器零基/一基判定核心internal/sse/citation_links.go标记替换正则 偏移查表internal/httpapi/openai/shared/citation_links.go流式标记剥离internal/textclean/reference_markers.goJS 端同款清洗internal/js/chat-stream/sse_parse_impl.js单元测试internal/httpapi/openai/citation_links_test.go架构总览docs/ARCHITECTURE.md读懂这套双轨收集 基线仲裁的设计你就能理解 DS2API 如何在多种上游变体下稳定地把引用序号还原成正确的来源链接。【免费下载链接】ds2apiDeepSeek-Compatible Middleware Interface: A technical exploration project in Go, focusing on high-concurrency protocol adaptation. It serves as a reference implementation for converting diverse web protocols into standardized formats.项目地址: https://gitcode.com/GitHub_Trending/ds/ds2api创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考