调用摘要api必须通过httpclient发送http请求，不存在内置summarize()方法；需注意分块预处理、camelcase序列化、并发控制及异常处理等关键细节。
用 HttpClient 调用本地或云上摘要 API 最直接
没有现成的“C# 内置摘要函数”，Summarize() 这类方法根本不存在。所有实用方案都得走 HTTP 请求调用外部模型服务，比如 Ollama 本地运行的 llama3.2、Azure AI 的 DocumentSummarization，或者 Hugging Face Inference Endpoints。
常见错误是试图用 Microsoft.ML 或 TextAnalyticsClient 做长文档摘要——它们不支持；TextAnalyticsClient 的 ExtractKeyPhrases 或 RecognizeEntities 只能辅助，不能生成连贯摘要。
- 优先选流式 POST：长文档（>10KB）必须用
PostAsync+HttpContent，别拼接字符串再传 - 注意请求头：
Content-Type: application/json和认证头（如Authorization: Bearer xxx）缺一不可 - 超时设够：默认 100 秒不够，大模型推理常需 30–120 秒，显式设
httpClient.Timeout = TimeSpan.FromMinutes(3)
System.Text.Json 序列化时字段名大小写易错
多数摘要 API 要求 JSON body 里字段名小写（如 {"text": "...", "max_length": 200}），但 C# 默认序列化用 PascalCase（Text, MaxLength）。不处理就会返回 400 Bad Request 或静默忽略字段。
不用第三方库也能解：用 JsonSerializerOptions.PropertyNamingPolicy = JsonNamingPolicy.CamelCase 即可。
- 别手动拼 JSON 字符串——引号、转义、嵌套全得自己管，极易出错
- 如果 API 强制要求 snake_case（如某些 Ollama 封装接口），就用
JsonSerializerOptions.Converters.Add(new JsonStringEnumConverter(JsonNamingPolicy.SnakeCaseLower)) - 响应反序列化同理：定义 DTO 类时字段名要匹配返回体，否则
text字段可能为null
分块（chunking）不是可选项，是必做预处理
无论用什么模型，单次输入都有长度限制（llama3.2 通常 8K token，GPT-4-turbo 约 128K，但费用和延迟飙升）。直接传 50 页 PDF 的纯文本？99% 情况下会截断或报 413 Payload Too Large。
别信“模型自己会切”——它不会。你得在 C# 里先按语义分段：按段落、按句子、或用 Microsoft.SemanticKernel 的 TextChunker。
- 简单场景用
string.Split(new[] { "\n\n", "\r\n\r\n" }, StringSplitOptions.RemoveEmptyEntries)切段落，再按字符数合并到 1500–3000 字/块 - 避免按固定字数硬切：会把一句话劈成两半，影响摘要质量
- 保留标题上下文：每块开头带上最近的
H1/H2文本（若原文有结构），否则模型不知道“这个段落在讲啥章节”
异步等待与并发控制不当会导致请求失败或结果错乱
一次摘要常需多次 API 调用（分块 → 摘要 → 合并），用 Task.WhenAll 并发太多，Ollama 或免费 API 会限流，返回 429 Too Many Requests；全用 await 串行又太慢。
真实项目里得折中：用 SemaphoreSlim 控制并发数（比如最多 3 个并发请求），同时每个请求带唯一 requestId 日志标记。
- 别在循环里直接
await：会导致 N 次阻塞，总耗时 ≈ 所有请求时间之和 - 别漏掉异常捕获：
HttpRequestException和JsonException必须分开处理，否则一个块失败整批崩 - 合并摘要时注意顺序：用
tasks.Select((t, i) => new { Task = t, Index = i })保证结果按原始块序排列
真正难的不是调 API，而是判断哪块该重试、摘要结果是否可信、要不要加引用溯源——这些没标准答案，得看文档类型和业务容忍度。比如法律合同摘要漏掉一条违约条款，技术上再准也没用。
