400错误源于请求不符合deepseek硬性校验规则。需检查：①model字段精确匹配官方值；②messages为含role（user/assistant/system）和content的非空数组；③content必须为纯字符串；④删除所有未声明字段；⑤authorization头为“bearer + api key”，content-type为application/json，deepseek-version为v4；⑥thinking mode下需原样回传thinking块，可用dsv4-cc-proxy自动补全。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
调用 DeepSeek API 时返回 400 错误，说明请求被服务端在解析阶段直接拒绝，根本没进到模型推理环节——不是网络不通、不是模型崩了、也不是 API Key 失效，而是你提交的请求内容不符合它的硬性校验规则。
检查请求体 JSON 结构是否合规
DeepSeek 对请求体字段名、嵌套层级、必填项和数据类型执行零容忍校验。任何偏差都会触发 400，且不报具体字段名。
第一步：确认 model 字段存在且值精确匹配官方列表，例如 【"deepseek-v4"】，大小写、拼写、多余空格全都不行。
第二步：检查 messages 是否为非空数组，每个元素必须同时包含 role 和 content 两个键，role 只能是"user"、"assistant"或"system"——注意：若走 /anthropic 兼容端点，【role: "system" 不允许出现在 messages 数组内】，必须提至顶层 system 字段。
第三步：逐个验证 content 字段是否为纯字符串。传 null、数字、对象、数组，哪怕只是多了一个换行符，都会被判定为非法。
第四步：删掉所有未在文档中声明的字段。比如自定义的 metadata、session_id、trace_id 等，DeepSeek 网关会直接拦截。
核对请求头是否严格达标
Authorization 和 Content-Type 是硬性门槛，缺一不可，格式错一个字符就 400。
方法一：Authorization 头必须以 【"Bearer "（注意末尾有空格）】 开头，后面紧接完整 API Key，不能截断、不能带换行、不能混入中文全角字符。
方法二：Content-Type 必须是 application/json，不能加 charset=utf-8，也不能用全角空格代替英文冒号后的空格。
方法三：如果文档要求 DeepSeek-Version 头，值必须为 v4，不能写成 V4、v4.0 或 "v4"（带引号）。
修复 thinking mode 下的多轮对话断裂
当你在 Claude Code 或类似客户端中使用 DeepSeek V4 的 thinking mode，并触发工具调用后，第二轮请求大概率报 400：The `content[].thinking` in the thinking mode must be passed back to the API。
这是因为 DeepSeek 要求每条 role: "assistant" 消息中的 thinking 块（或 reasoning_content 字段）必须原样回传，而 Claude Code 在序列化历史时会丢弃它。
运行这行命令启动本地代理，自动补全缺失字段：npx dsv4-cc-proxy
代理默认监听 127.0.0.1:15722，把原来指向 api.deepseek.com 的请求改发到该地址即可。它会在每次请求发出前扫描 messages，对每个 assistant 消息注入 thinking 块或 reasoning_content 字段。
无需修改客户端代码，不改变原有调用逻辑，也不影响其他模型——只对 DeepSeek V4 + thinking mode 生效。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
