DeepSeek API返回400错误是因请求不符合服务端校验规则，需检查JSON格式、必填字段（messages非空且每项含role/content）、数值参数范围（如temperature∈[0.0,2.0]）、thinking模式下reasoning_content回传、请求头仅限Authorization和Content-Type、密钥格式正确性，以及本地部署时GPU与模型加载状态。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
DeepSeek API调用时返回400错误，说明请求体格式、字段值或协议逻辑不符合服务端校验规则，不是网络问题也不是模型挂了，而是你的请求没用对它的“语言习惯”——一个空格、一个未声明字段、一次thinking block丢失，都会被网关直接拦截并返回{"error": {"message": "invalid request"}}。
检查请求体JSON结构与字段合法性
第一步：用在线JSON校验工具（如jsonlint.com）粘贴你的完整请求体，确认无语法错误——DeepSeek不接受尾随逗号、多余空格、单引号字符串、注释或任何非标准JSON字符。
第二步：对照OpenAPI Spec核对必填字段。/v1/chat/completions接口中，【messages数组不能为空，且每个message必须包含role和content两个键】；role只能是"user"、"assistant"或"system"，拼错成"usr"或"User"会直接400。
第三步：检查temperature、top_p等数值型参数是否越界。DeepSeek严格校验范围：temperature必须在0.0～2.0之间（含边界），传3.0或-1.0会触发400；max_tokens若为0或负数同样报错。
修复thinking mode下的reasoning_content回传缺陷
如果你在Claude Code、WorkBuddy或自研前端中启用DeepSeek V4的思考模式，工具调用后第二轮请求必报400，根因是客户端未将上一轮返回的reasoning_content原样塞回下一轮请求的content字段中。
方法一：改用dsv4-cc-proxy代理（推荐）
终端执行：npm install -g dsv4-cc-proxy && dsv4-cc-proxy --port 3000，然后把原API地址从https://api.deepseek.com/v1/chat/completions改成http://localhost:3000/v1/chat/completions。该代理自动补全丢失的thinking block，无需改代码。
方法二：手动构造请求体
从上一轮响应中提取content[0].thinking字段值（注意是字符串，不是对象），在下一轮请求的messages末尾插入一条role为"assistant"、content为该字符串的新消息。漏掉这一步，服务端立刻拒绝。
验证API密钥与请求头配置
① 打开终端，运行curl命令测试基础连通性：curl -X GET "https://api.deepseek.com/v1/models" -H "Authorization: Bearer sk-xxx" -H "Content-Type: application/json"
WorkBuddy 桌宠工厂 —— 给一张角色图、一个 codex.pet 链接、一条 codex-pets.net 下载 URL、或一份现成的精灵表，就能自动创建一只可联动 WorkBuddy 状态的桌面宠物。当用户说"创建桌宠"、"做一只桌宠"、"用这张图做桌宠"、"从 codex.pet 安装桌宠"、"导入 codex 桌宠 XX"、"装一下 codex-pets.net 上的 XX&quo
② 若返回403，说明密钥无效或权限不足；若返回400，说明请求头里混入了非法字段——【DeepSeek只认Authorization和Content-Type两个请求头，多加X-Forwarded-For或User-Agent会导致400】。
③ 密钥必须以sk-开头，长度固定为48位（含短横线）。少一位、多一位、含中文字符或全大写，全部判定为非法请求。
排查PyTorch/CUDA环境引发的本地部署400
本地运行DeepSeek模型（如Ollama+deepseek-coder:1.3b）时出现400，大概率是推理服务启动失败后仍返回HTTP 400而非5xx，本质是进程未就绪却收到请求。
先执行ollama list确认模型已正确加载；再运行ollama run deepseek-coder:1.3b手动触发一次交互，看终端是否打印“successfully loaded”字样。如果卡在“loading model…”超过90秒，说明CUDA版本不匹配或显存不足，此时服务虽监听端口但无法处理请求，对外表现为400。
验证GPU可用性：python -c "import torch; print(torch.cuda.is_available(), torch.cuda.device_count())"。输出False或0，本地部署必然失败，400是唯一可能返回码。
