推荐API返回图片URL而非二进制流或Base64；URL方案支持缓存、追踪与复用，Base64仅适用于≤1KB无缓存需求的小图；需规范HTTP状态码、防缓存处理及MIME配置。
PHP API 返回图片时不能直接返回二进制流并声称是 JSON，这是常见误解——你得在 JSON 响应里提供图片的访问地址或 Base64 数据，而不是把图片塞进 Content-Type: application/json 里强行“返回图片”。
API 返回图片 URL 是最推荐的做法
前端需要刷新图片（比如验证码、用户头像、图表），后端不该每次返回 raw 图片字节，而应返回一个可复用、可缓存、可追踪的 URL。这样前端只需更新 src 属性即可触发浏览器重新加载。
- 后端生成图片后保存到 Web 可访问路径（如
/uploads/verify/abc123.png），并返回该相对或绝对 URL - JSON 响应结构保持标准：包含
code、message、data，其中data.url是图片地址 - 避免返回临时签名 URL 时漏掉过期时间字段，否则前端无法预判失效时机
- 注意 Web 服务器对图片后缀的 MIME 类型配置（如 Nginx 要确保
.png返回image/png）
{
"code": 0,
"message": "success",
"data": {
"url": "/uploads/verify/7f3a9c.png",
"expires_at": 1717023600
}
}
Base64 内联方式只适用于小图且无缓存需求
当图片极小（如 1KB 以内图标）、且必须避免额外 HTTP 请求时，才考虑将图片转为 Base64 放进 JSON 的 data.image 字段。但要注意：
- PHP 中用
base64_encode(file_get_contents($path))即可，但务必检查文件是否存在、是否为图片类型 - JSON 响应体积会显著增大，HTTP 响应体可能翻 3–4 倍，不适用于 >5KB 的图
- 前端需拼接前缀如
"data:image/png;base64," + base64str才能用于 - 浏览器不会缓存 Base64 图片，每次刷新都重新解析渲染，CPU 开销略高
状态码别乱用 200 搞定一切
API 返回图片相关数据时，HTTP 状态码要反映业务逻辑，不是所有成功都用 200 OK：
