报错是这么冒出来的。用 dashscope 的 qwen-vl-max 做商品图对比，messages 的 content 里拼了四个 image_url 块，返回的描述只提到第一张图，后三张完全没提，把四张图单独调用都能正常识别，温度已经设成 0。
中间走过弯路，把「图片 URL 带签名参数，后三张返回 403 被当成空图」当成主因，改完现象没变。
原因不止一个，得分开看。content 数组里 image_url 与 text 的顺序不对，模型按位置截断。少数情况下是单条消息图片数量有上限，超出部分被静默丢弃。
不容易想到的是，multimodal 开关没开，走的是纯文本模型路由。
动手时先把每张图的 URL 单独 HEAD 一次看状态码
curl -I "https://oss.example.com/p1.jpg?Expires=1700000000" | head -3再往下用本地文件转 base64 排除 URL 失效
python -c "import base64;print('data:image/jpeg;base64,'+base64.b64encode(open('p2.jpg','rb').read()).decode()[:40])"随后把图片逐张与文字交替排列后重发
curl https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions -H "Authorization: Bearer $DASHSCOPE_KEY" -d @multi.json请求里打印实际发出的 content 长度
python -c "import json;d=json.load(open('multi.json'));print(len(d['messages'][0]['content']))"怎么算真的好了，看的是同一批现象。四张图的内容都能在回答里被分别描述，换一组商品图结果一致，日志里 content 块数量与实际图片数相同。
多图不是把图堆进去就行，图片和文字的先后顺序会影响模型关注点，数量接近上限时要按业务拆成多次请求。同一份配置在测试环境跑通，不代表线上没事，两边的默认值经常不一样。