Base64字符串合法性校验需同时满足字符集限定（A–Z、a–z、0–9、+、/）、长度为4的倍数、填充符“=”仅出现在末尾且数量不超过两个（即XX==、XXX=或无填充），推荐正则：^[A-Za-z0-9+/]{4}*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$。
Base64 字符串的合法性校验不能只靠“是否能解码”来判断，必须结合其编码规则进行正则匹配。核心是：字符集限定 + 长度可被 4 整除 + 填充符（=）位置合规。
字符集与基本结构校验
标准 Base64 编码仅允许以下 64 个字符：A–Z、a–z、0–9、+、/，末尾最多两个 = 作为填充。因此正则需严格限定字符范围，并排除空格、换行、下划线等常见干扰字符。
- 基础正则：
^[A-Za-z0-9+/]*={0,2}$ - 但该表达式未限制填充位置——
=只能出现在末尾，且不能单独出现或中间出现 - 更准确写法：
^[A-Za-z0-9+/]{4}*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$
长度必须是 4 的倍数
Base64 编码后字符串长度恒为 4 的整数倍。这是硬性约束，可在正则外先做长度检查，也可融入正则逻辑（如上面的 {4}* 已隐含该要求）。
- 推荐先快速过滤：
if (str.length % 4 !== 0) return false; - 再进入正则匹配，提升效率并避免误判（例如
"abc="长度为 4 但内容非法）
填充符 = 的位置与数量必须合规
填充只在原始数据字节数模 3 余 1 或 2 时出现：余 1 补两个 =，余 2 补一个 =。因此合法填充只有三种结尾形式：XXXX（无填充）、XXX=、XX==。
- 错误示例：
AB=C（=在中间）、ABC=（长度 4 但应为AB==或ABC=？需看原始字节——但ABC=实际对应 2 字节输入，合法）、A===（三连=必非法） - 精准正则（推荐）：
^[A-Za-z0-9+/]{4}*$|^[A-Za-z0-9+/]{4}*([A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)$ - 更简洁写法（等价）：
^[A-Za-z0-9+/]{4}*(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$
注意 URL 安全变种（Base64URL）
若字符串来自 JWT、浏览器 API 等场景，可能使用 Base64URL 编码：用 - 替代 +，_ 替代 /，且通常省略填充（= 可选）。
- Base64URL 合法正则：
^[A-Za-z0-9_-]{4}*(?:[A-Za-z0-9_-]{2}==|[A-Za-z0-9_-]{3}=)?$ - 若允许无填充（常见实践），可改为：
^[A-Za-z0-9_-]{4}*(?:[A-Za-z0-9_-]{2}==|[A-Za-z0-9_-]{3}=)?（末尾=?表示 0 或 1 个=，但实际应最多两个；更稳妥仍保留原逻辑） - 统一处理建议：先识别是否含
-或_，再切换校验模式
