mysql无法直接显示blob图片，需应用层处理：先用magic number校验真实mime类型，再通过data url或接口渲染，同时注意编码陷阱与csp限制。
mysql 查询结果里直接显示图片 blob 字段？不行，得靠应用层处理
数据库本身不渲染图片，blob 存的是二进制字节流，sql 客户端（比如 mysql workbench、dbeaver）或命令行 mysql 工具根本不会识别这是图片，更不会自动转成预览。你看到的只会是乱码、十六进制字符串，或者干脆报错截断。
真正能“显示图片”的环节，一定在你的前端页面或后端服务里——BLOB 字段要先读出来，再根据 _MIME 类型（比如 image/jpeg）构造合法的 data URL 或提供可访问的图片接口。
怎么安全提取并验证 _MIME 字段？别信表名或扩展名
很多项目会额外存一个 mime_type 字段，但这个值可能被伪造、过期、甚至为空。最可靠的方式是读取 BLOB 前几个字节做 magic number 判断，而不是依赖字段名带 _MIME 就以为它可信。
-
SELECT id, mime_type, image_data FROM uploads LIMIT 1—— 这条查出来mime_type是image/png，但image_data实际可能是 PDF 的二进制，浏览器一加载就报错 - Python 示例：用
python-magic库检测真实类型：import magic<br>m = magic.Magic(mime=True)<br>real_mime = m.from_buffer(blob_bytes)
- Node.js 可用
file-type库，传入Buffer得到真实mime；Go 用http.DetectContentType（注意只看前 512 字节） - 如果没条件做 runtime 检测，至少加个 SQL 约束：
CHECK (mime_type IN ('image/jpeg', 'image/png', 'image/gif'))，防住明显非法值
前端用 data URL 渲染图片：小心体积和 CSP 限制
把 BLOB 转成 base64 放进 src="data:<mime>;base64,<data>"</data></mime> 最简单，但只适合小图（
- 后端返回时别直接拼 data URL，而是返回
{ url: "/api/image/123", mime: "image/webp" }更可控 - 如果真要用 data URL，前端必须做大小拦截：
if (blob.length > 100 * 1024) { throw new Error("Image too large"); } - Content-Security-Policy 里若禁了
data:，图片会直接 403；需显式加img-src 'self' data: - 别用
atob()手动解 base64 —— 用Uint8Array+Blob+URL.createObjectURL()更稳妥，兼容二进制非 ASCII 字符
PHP/Python/Node.js 读 BLOB 时的编码陷阱
默认连接配置可能把 BLOB 当文本处理，导致字节损坏。MySQL 的 binary 类型在传输中被错误转码（比如 utf8mb4 强制转换），图片就打不开。
- PHP PDO 必须设
PDO::ATTR_STRINGIFY_FETCHES => false，且charset参数不能写utf8，要用binary或留空 - Python PyMySQL 默认把
BLOB当bytes，但mysql-connector-python需手动设raw=True或用cursor(buffered=True) - Node.js mysql2 驱动要加
supportBigNumbers: true, bigNumberStrings: false，否则超长二进制会被转成科学计数法字符串 - 查完立刻用
typeof blob === 'object' && blob instanceof Uint8Array校验类型，别等渲染时报 “Invalid image buffer”
实际部署时，_MIME 字段和 BLOB 数据不同步是最常被忽略的点——更新图片忘了更新 mime，或事务失败导致只存了半截 BLOB。这类问题不会在本地测试暴露，得靠上线后日志里的 ERR_INVALID_URL 或 DOMException: The source image cannot be decoded 反向排查。
