问题出现得很突然，日志倒是留得挺全。vLLM 0.8.5 起 Qwen3-8B，客户端拿到的 content 里夹着整段思考过程，前端把它当答案展示，而日志里 reasoning_content 字段一直是空的。启动命令只给了 --model 和 --max-model-len，后来补了 --enable-auto-tool-choice 也没有变化。
刚开始盯着「客户端只读旧字段，服务端其实已经返回了新字段」，折腾了半个多小时，排掉了。
原因不止一个，得分开看。服务端没指定 reasoning parser，思考段没被拆出去。另一种情况是模型模板里的思考标记与 parser 名称对不上。
不容易想到的是，网关重组响应体，只保留了 content 一项。
上来先看原始响应里有没有 reasoning_content
curl -s http://localhost:8000/v1/chat/completions -H "Content-Type: application/json" -d '{"model":"Qwen3-8B","messages":[{"role":"user","content":"1+1 等于几"}]}' | jq '.choices[0].message'然后重启服务并显式指定 parser 名称
vllm serve Qwen/Qwen3-8B --reasoning-parser qwen3 --max-model-len 16384随后确认模型自带的 chat template 与 parser 对得上
python -c "from transformers import AutoTokenizer;t=AutoTokenizer.from_pretrained('Qwen/Qwen3-8B');print(t.chat_template[:200])"前端改成优先渲染 reasoning_content，缺失时再退回 content
python check_fields.py --url http://localhost:8000/v1/chat/completions怎么算真的好了，看的是同一批现象。同一条请求的 message 里 reasoning_content 非空且 content 只剩结论，流式响应中两个字段分别落在不同 chunk。
parser 名称写错时服务不一定报错，只是按普通文本返回，排查时要先看启动日志里有没有加载成功的提示。如果同一现象隔几天又出现，说明根因没找到，别当偶发处理。