用 HttpClient 调通 OpenAI 兼容接口需手动构造 HttpRequestMessage、复用客户端、设置正确请求头，响应用 ReadAsStream() + 逐行解析 SSE；避免 PostAsJsonAsync 和直接反序列化整块 JSON，应按行处理 data: 前缀并动态解析字段。
怎么用 HttpClient 调通 OpenAI 兼容接口
绝大多数 C# 项目调大模型，不是靠“AI SDK”，而是直接发 HTTP 请求——因为稳定、可控、不被封装绑架。OpenAI 官方 SDK（OpenAI.DotNet）维护滞后，且不支持流式响应的细粒度控制；而自己用 HttpClient，能精准处理 429 限流、503 服务不可用、token 截断等真实问题。
关键点：别用 PostAsJsonAsync 简单封装，它会强制读取整个响应体，导致流式响应（text/event-stream）失效。
- 必须手动构造
HttpRequestMessage，设置Content-Type: application/json - 响应要用
response.Content.ReadAsStream()拿到原始流，再用StreamReader逐行解析 SSE -
HttpClient实例要复用（全局单例），否则高并发下会耗尽 socket - 请求头必须带
Authorization: Bearer <your-key></your-key>，部分国内代理还要求HTTP-Referer
为什么 System.Text.Json 解析 ChatCompletion 响应容易出错
OpenAI 的 JSON 响应字段名是 choices，但很多国产模型（如千问、混元）返回的是 data 或 output；更麻烦的是，流式响应每条数据是独立 JSON 对象，不是合法数组——直接 JsonSerializer.Deserialize<t>()</t> 必炸。
正确做法是按行切割 + 单独反序列化每一行，而不是试图一次解析整块响应。
- 流式响应中每行以
data:开头，需先TrimStart("data: ")再解析 - 非流式响应也建议用
JsonDocument.Parse()动态读取，避免因字段缺失（比如没usage）抛JsonException - 别硬套
ChatResponse类——字段名大小写、嵌套层级、空值处理全都不统一，动态解析更鲁棒
同步阻塞调用 vs async/await 流式处理的实际区别
很多人以为“加个 await 就算异步”，结果 UI 线程卡死或 ASP.NET Core 请求超时。真正决定是否阻塞的，是流读取方式和线程调度上下文。
- 用
ReadLineAsync()配合ConfigureAwait(false)才能释放线程，否则 WinForms/WPF 下会死锁 - ASP.NET Core 中若在 Controller 里用
Task.Run(() => { /* 同步 HttpClient */ })，等于把同步阻塞搬到后台线程——浪费线程池资源，且无法及时响应取消 - 流式场景下，
cancellationToken必须传给ReadLineAsync()和WriteAsync()，否则用户点了“停止”按钮，请求还在后台跑
国产模型 API 的三个典型兼容性坑
调通 OpenAI 接口不等于能调通国内模型。字节、百度、阿里各家对 OpenAI 兼容层的实现程度不同，参数名、错误码、流格式都可能差一截。
-
model参数：通义千问要填qwen-max，不是qwen1.5-72b；讯飞星火必须用spark-lite这类固定字符串，填错直接400 - 错误响应结构不一致：
error.message在 OpenAI 是字符串，在智谱是对象，直接映射会NullReferenceException - 流式响应末尾可能多一行空
data:或[DONE]，不判断会导致解析失败或死循环
最省事的办法：所有模型请求走同一套流解析逻辑，但用配置开关切换字段路径和终止条件——别指望一个 DTO 通吃。
