MySQL 8.0+ 的FROM_BASE64()返回VARBINARY类型，需CONVERT(... USING utf8mb4)转码才能正确显示中文或参与文本比较；低版本行为不一致，且对非法输入静默返回NULL，须前置校验并清理换行符。
MySQL 8.0+ 可直接用 FROM_BASE64()，但解出来是 VARBINARY，不是字符串；低版本（如 5.7）虽有该函数，但行为不一致，必须显式转码才能正确显示中文或参与文本比较。
FROM_BASE64() 返回 VARBINARY，不是 VARCHAR
很多人执行 SELECT FROM_BASE64('5L2g5aW9') 看到乱码或空结果，不是函数错了，而是它返回的是二进制类型 VARBINARY。MySQL 不会自动按 utf8mb4 解释这些字节，客户端默认用 latin1 显示，自然变成 或其他符号。
- 直接 SELECT 会触发隐式字符集转换，结果不可靠
- 不能和
VARCHAR字段用=直接比较，比如WHERE name = FROM_BASE64('xxx')永远为 false - 正确做法：用
CONVERT(FROM_BASE64('xxx') USING utf8mb4)强制指定编码 - 若原始数据是 ASCII（如 'hello'），
CONVERT(... USING ascii)也行，但 utf8mb4 更通用
输入带 JSON 引号或换行时会失败
从 JSON 字段里取 Base64 字符串，常见写法是 JSON_EXTRACT(json_col, '$.field')，但它返回带双引号的字符串（如 "SGVsbG8="），而 FROM_BASE64() 只接受无引号的 Base64 内容。
- 错误示例：
FROM_BASE64('"SGVsbG8="')→ 返回NULL（引号不是合法 Base64 字符） - 正确做法：先用
JSON_UNQUOTE()去掉外层引号，再传给FROM_BASE64() - 如果 Base64 字符串本身含换行（比如从邮件或旧系统导入），
FROM_BASE64()会静默返回NULL—— 它只忽略空白字符，但换行在某些上下文里不算“空白” - 稳妥处理：用
REPLACE(REPLACE(encoded_str, '\r', ''), '\n', '')清理后再解码
低版本 MySQL 的兼容陷阱
MySQL 5.6.17+ 开始支持 FROM_BASE64()，但 5.7 和早期 8.0 存在几个关键差异：
- 5.7 中
FROM_BASE64()对非法输入（如长度非 4 的倍数、含空格）返回NULL，但不报错，容易漏判 - 5.7 不支持
TO_BASE64()的REPLACE自动清理换行，所以你存进数据库的 Base64 很可能自带\n，解码时就挂了 - 若字段原始是
BLOB或TEXT，确保连接层字符集设为utf8mb4，否则TO_BASE64()编码时已截断中文 - 别依赖
IFNULL(FROM_BASE64(col), '')就完事——先加WHERE JSON_VALID(col) = 1或WHERE LENGTH(col) % 4 = 0做前置校验更可靠
最常被跳过的一步：没检查 FROM_BASE64() 是否真返回了有效值。它对任何非法输入都沉默返回 NULL，而不是报错，所以 WHERE 条件里一旦用了它，务必搭配 IS NOT NULL 判断，否则查不到数据还找不到原因。
