结论概览
+
+
+
+ 2
+ 目标 issue：#5833、#5834
+
+
+ 2
+ 生产代码文件有改动
+
+
+ 1
+ 测试文件新增回归测试
+
+
+ 0
+ 数据库/前端/API 路由改动
+
+ + 本次改动的核心是：MiniMax 文本聊天走 OpenAI Chat Completions 输出时，强制使用项目已有的 OpenAI DTO 格式化路径，过滤 MiniMax 上游的私有字段。 +
+对应 Issue
+| Issue | +问题 | +本次覆盖方式 | +
|---|---|---|
| #5833 | +MiniMax 流式响应最后一个 chunk 多出 message 块，严格客户端可能重复追加完整内容。 |
+ 流式 E2E 和单测确认输出只保留 delta 与 finish_reason，不再输出 message。 |
+
| #5834 | +MiniMax 响应泄漏非 OpenAI 字段，例如 input_sensitive、service_tier、base_resp、name、audio_content。 |
+ 非流式和流式测试都扫描确认这些字段不再出现在客户端响应中。 | +
改动文件
+| 文件 | +类型 | +改动内容 | +为什么需要 | +
|---|---|---|---|
relay/channel/minimax/adaptor.go |
+ 生产代码 | +MiniMax + OpenAI Chat Completions 响应时设置 info.ChannelSetting.ForceFormat = true。 |
+ MiniMax 上游可能返回厂商私有字段；强制走已有 OpenAI DTO marshal 路径，相当于白名单输出。 | +
relay/channel/openai/relay-openai.go |
+ 生产代码 | +在 forceFormat 非流式响应 marshal 前清掉 choices[].message.name。 |
+ 项目复用了请求侧 dto.Message，请求里 name 合法，但 MiniMax 响应里的 name 是供应商元数据，不应出现在 OpenAI 响应。 |
+
relay/channel/minimax/adaptor_test.go |
+ 测试代码 | +新增非流式和流式回归测试，构造污染响应并断言输出已清洗。 | +锁定 #5833 / #5834 的真实问题形态，防止以后改回原样透传。 | +
前后对比
+
+
+
+
+
+ 修复前可能返回
+{
+ "message": {
+ "role": "assistant",
+ "content": "hello",
+ "name": "MiniMax AI",
+ "audio_content": ""
+ },
+ "input_sensitive": false,
+ "service_tier": "standard",
+ "base_resp": {"status_code": 0}
+}
+
+
+ 修复后实际返回
+{
+ "message": {
+ "role": "assistant",
+ "content": "hello"
+ },
+ "usage": {
+ "prompt_tokens": 1,
+ "completion_tokens": 2,
+ "total_tokens": 3
+ }
+}
+
+
+
+
+ 修复前流式尾块
+data: {
+ "choices": [{
+ "delta": {},
+ "message": {
+ "role": "assistant",
+ "content": "hello",
+ "name": "MiniMax AI"
+ },
+ "finish_reason": "stop"
+ }]
+}
+
+
+ 修复后流式尾块
+data: {
+ "choices": [{
+ "delta": {},
+ "finish_reason": "stop"
+ }]
+}
+
+data: [DONE]
+ 为什么这样改
+-
+
- 复用已有机制：项目已经有
ForceFormat，它会把响应反序列化为 OpenAI DTO 再 marshal，天然能过滤 DTO 不支持的字段。
+ - 范围小：只在 MiniMax + OpenAI Chat Completions 文本响应路径打开，不影响 MiniMax 图片、TTS、Claude 格式，也不影响普通 OpenAI 兼容渠道默认透传。 +
- 符合接口契约：
/v1/chat/completions对下游承诺的是 OpenAI 兼容响应，不应该泄漏 MiniMax 的厂商元数据。
+ - 避免重复内容：流式响应里
message属于非流式结构，严格客户端会把它当完整消息再追加一次。
+
没有修改的范围
+| 范围 | +是否修改 | +说明 | +
|---|---|---|
| 数据库 schema / migration | +没有 | +不涉及表结构、字段迁移或兼容性变更。 | +
| 前端页面 | +没有 | +没有改 web/default 或 web/classic。 | +
| 路由和鉴权 | +没有 | +没有改 router、middleware、token 验证逻辑。 | +
| 其他 provider | +仅间接受影响 forceFormat | +relay-openai.go 中清理 message.name 只在 forceFormat 为 true 时生效。默认普通 OpenAI 透传路径不受影响。 |
+
| MiniMax 图片/TTS/Claude 格式 | +没有 | +改动条件限定为 RelayModeChatCompletions 和 RelayFormatOpenAI。 |
+
你需要重点判断的点
+
+ 唯一值得审查的边界是：是否允许在
+ forceFormat 非流式响应中去掉 message.name。我的判断是应该去掉，因为这里处理的是响应输出，MiniMax 的 name 是厂商元数据；但如果项目明确希望保留 OpenAI 响应里的 assistant name，这部分需要调整为仅 MiniMax 生效。
+ -
+
- 如果你认为
message.name在 OpenAI 响应中必须保留：应把清理逻辑从通用 OpenAIforceFormat分支挪回 MiniMax 专属清洗。
+ - 如果你认为 MiniMax 私有字段不应在 OpenAI endpoint 暴露：当前改法是正确方向。 +
- 如果你担心其他开启
forceFormat的渠道：当前只清理message.name，其他字段仍按 DTO 原逻辑处理。
+
测试证据
+| 测试 | +结果 | +验证内容 | +
|---|---|---|
go test ./relay/channel/minimax ./relay/channel/openai -count=1 |
+ 通过 | +目标 MiniMax 和委托 OpenAI handler 包通过。 | +
go test ./relay/channel/... -count=1 |
+ 通过 | +相邻渠道包没有被破坏。 | +
go test ./... |
+ 通过 | +后端全量 Go 测试通过。 | +
| HTTP E2E：非流式 | +HTTP 200，通过 | +真实 new-api + 临时 SQLite + mock MiniMax upstream；响应不含污染字段。 | +
| HTTP E2E：流式 SSE | +HTTP 200，通过 | +真实 SSE 输出含 delta、finish_reason、[DONE]，不含 message/name/audio_content。 |
+
本次改动的最小代码片段
+MiniMax adaptor：只对 OpenAI 文本聊天强制格式化
+if info.RelayFormat == types.RelayFormatOpenAI &&
+ info.RelayMode == constant.RelayModeChatCompletions {
+ info.ChannelSetting.ForceFormat = true
+}
+
+ OpenAI handler：forceFormat 响应清理 message.name
+if forceFormat {
+ for i := range simpleResponse.Choices {
+ simpleResponse.Choices[i].Message.Name = nil
+ }
+ responseBody, err = common.Marshal(simpleResponse)
+}
+