4. 踩坑三：加密后字段长度变化导致数据库报错
这个坑我踩得特别深。当时一个用户表，手机号字段设计的是 varchar(20)，想着存个加密结果绰绰有余。结果一上线，批量插入就报错：Data too long for column 'phone'。嗯，说白了，加密后的数据变胖了，数据库装不下。
加密后长度为什么会变长？
我习惯这样跟团队解释：对称加密（比如 AES）是按固定块大小处理的。AES-128-CBC 每次加密 16 字节，输出也是 16 字节的倍数。如果你明文字段只有 11 字节，加密后变成 16 字节——这就多了 5 字节。更麻烦的是，二进制的密文不能直接存到普通 varchar 里，得用 Base64 或 Hex 编码转成可见字符。Base64 编码会让长度再膨胀 33%。
举个例子：
- 明文手机号
13800138000（11 字节） - AES-CBC 加密输出 16 字节（补齐到 16 的倍数）
- Base64 编码后变为 24 字符（每 3 字节转 4 字符，末尾补 =）
- 长度从 11 涨到 24，翻了一倍多
你想想看，如果原来字段只有 varchar(20)，肯定炸了。
数据库报错典型场景
我在项目中遇到过三种常见报错，列出来大家对照：
| 场景 | 原字段定义 | 加密后实际长度 | 报错信息 |
|---|---|---|---|
| 手机号加密 | varchar(20) | 24 (Base64) | Data too long for column |
| 身份证号加密 | varchar(18) | 44 (Hex) | String data, right truncation |
| 银行卡号加密 | varchar(30) | 64 (Base64) | ER_WARN_DATA_OUT_OF_RANGE |
说白了，都是同一类问题：字段定义偏小，加密后内容超标。
如何精确计算加密后字段长度？
这一步非常关键，我建议你在设计表结构之前就做个预计算。下面给个通用公式：
Base64 编码后长度公式
base64_len = ceil(加密输出字节数 / 3) * 4Hex 编码后长度公式
hex_len = 加密输出字节数 * 2加密输出字节数取决于算法和明文长度。以 AES-128-CBC 为例：
加密输出字节数 = (明文长度 + 16 - 1) 向下取整到 16 的倍数
// 或直接用： (明文长度 / 16) 向上取整 * 16
我习惯写个小脚本来算，避免心算出错：
function encryptedFieldLength(plainLen, blockSize = 16) {
const padLen = Math.ceil(plainLen / blockSize) * blockSize;
const base64Len = Math.ceil(padLen / 3) * 4;
const hexLen = padLen * 2;
return { padLen, base64Len, hexLen };
}
// 手机号 11 字节
console.log(encryptedFieldLength(11));
// 输出: { padLen: 16, base64Len: 24, hexLen: 32 }
常见算法与推荐字段类型
为了让你一眼看清，我整理了下面这张对照表。这是我每次新建加密表都要拿出来参考的。
| 加密算法 | 输出字节数（最长） | 推荐编码 | 推荐字段类型 & 长度 |
|---|---|---|---|
| AES-128-CBC | (plain_len + 16) 对齐到 16 | Base64 | varchar(128) 或 varbinary(128) |
| AES-256-GCM | (plain_len + 28) 对齐到 16 + 12 | Base64 | varchar(256) 或 varbinary(256) |
| SM4-CBC | (plain_len + 16) 对齐到 16 | Base64 | varchar(128) 或 varbinary(128) |
| RSA-OAEP (2048) | 256 | Base64 | varchar(512) 或 varbinary(512) |
这里多说一句：如果数据库支持二进制类型（比如 MySQL 的 VARBINARY 或 BLOB），我强烈建议用二进制存密文，省掉 Base64 编解码，既省空间又省 CPU。但是要注意，二进制字段的索引、查询可能会受限，需要根据场景权衡。
避坑指南
我曾经在一个金融项目里，因为没算清楚长度，导致信用卡号加密后写入报错，影响了整批数据导入。后来总结了几条实操经验：
- 字段长度留余量：计算出的理论长度 × 1.5，凑整到 10 的倍数。比如计算出来 24，我就写
varchar(50)。 - 统一使用二进制类型：如果团队对 Base64 不熟，直接用
varbinary(256)或blob，避免编码坑。 - 开发环境验证：写一个自动化测试，遍历所有加密字段，插入最大长度数据，确认不报错。
- 注意字符集影响：使用
utf8mb4时，每个字符最多 4 字节，但 Base64 字符串是 ASCII，实际占 1 字节。这点容易混淆，但通常不会导致算错。
varchar(n) 存储的是字符数，不是字节数。如果你的密文是 Base64 字符串，n 必须 ≥ 字符数，不是字节数。而 varbinary(n) 的 n 是字节数，别搞混。
一张图看懂完整应对流程
下面这张流程图，概括了从选加密算法到字段落地的全过程。我每次给新同学讲加密设计，都先画这个图。
这个流程，说白了就是先确定算法，再算输出字节数，接着选编码，最后得出字段长度。每走一步，你都要问自己：最大明文长度是多少？会不会填加固定的 IV 或 tag？把这些都算进去，基本就不会踩坑了。
个人实战总结
我在好几个项目里都用过这张表，现在每次设计加密表，直接复制过来改字段名就行。我的建议是：永远把字段长度往上提两档——比如按 Base64 算出来是 40，我就写 varchar(100)。多出来的空间几乎不影响性能，但能避免后期扩容的麻烦。
最后说一句：别忘了测试。我曾经就是因为少测了一个特殊字符（中文姓名含生僻字），上线后才发现长度不够。嗯，这个教训挺贵的，希望你不用再付学费。