不建议在生产环境用 C++ 手写 AES 实现，哪怕只是“简单”的版本；应使用 OpenSSL、Crypto++ 或 libsodium 等经验证的库，因其已妥善处理密钥调度、侧信道防护、PKCS#7 填充、CBC/CTR 模式及 GF(2⁸) 有限域运算（如 SubBytes 求逆与 MixColumns 矩阵乘），手写极易因忽略模约简、符号扩展或轮函数顺序导致不可逆加密或解密失败。
直接说结论：不建议在生产环境用 C++ 手写 AES 实现，哪怕只是“简单”的版本。标准库（如 OpenSSL、Crypto++）或现代封装（如 libsodium）已解决密钥调度、侧信道防护、填充、模式选择等关键问题；手写极易出错，且一个 AES-128 的完整轮函数涉及 10 轮 SubBytes、ShiftRows、MixColumns、AddRoundKey，位运算和字节混淆只是冰山一角。
为什么 SubBytes 不能只靠查表或简单异或
新手常误以为 S-box 就是固定字节映射，直接硬编码一个 256 元素数组完事。但真实 SubBytes 是 GF(2⁸) 上的可逆仿射变换：先做有限域求逆（0 映射为 0），再矩阵乘 + 异或常量。漏掉求逆步骤会导致加密不可逆；而手动实现 GF(2⁸) 乘法若没处理好模约简（0x11b），0x02 * 0x80 这类运算就会溢出错。
- 务必用已验证的 S-box 表（如 AES 标准附录 C），不要自己“推导”
- 如果真要手算求逆，必须显式做
mod x⁸ + x⁴ + x³ + x + 1，对应代码中& 0xFF不够，得用条件异或 - 查表实现时，确保数组类型是
uint8_t[256]，避免符号扩展导致负索引访问
MixColumns 的矩阵乘法必须按字节分组，不是整数乘
这一轮把每列 4 字节视为 GF(2⁸) 上的向量，左乘固定矩阵。常见错误是当成普通 4×4 整数矩阵乘，结果完全偏离标准。例如第一行计算：0x02 * s0 ⊕ 0x03 * s1 ⊕ 0x01 * s2 ⊕ 0x01 * s3，其中 * 是 GF(2⁸) 乘法，⊕ 是异或（即加法）。
-
0x02 * x等价于x 后判断最高位：若原 <code>x & 0x80为真，则再异或0x1b -
0x03 * x应拆成(0x02 * x) ^ x，而非x*3 - 切勿对整个
uint32_t列做移位——AES 操作单位永远是单字节，跨字节移位会破坏列结构
ECB 模式下，padding 不填满 16 字节就解密失败
原始 AES 块大小固定为 128 位（16 字节），输入长度不是倍数时必须填充。PKCS#7 是最常用方案：补 n 字节，每个值都等于 n。但手写容易忽略边界情况：
立即学习“C++免费学习笔记（深入）”；
- 明文刚好 16 字节时，仍需补 16 个
0x10，否则解密端无法区分“末尾是真实数据还是填充” - 解密后必须校验填充字节是否合法：所有填充字节值相等，且等于填充长度，且长度在 1–16 之间
- 用
std::vector<uint8_t></uint8_t>存储明文时，别用.data()直接传给加密函数——它不保证结尾有 \0，而填充逻辑依赖精确字节数
真正难的不是位运算本身，而是每一轮输出必须严格满足 AES 的数学约束；一个字节的 S-box 错、一次 MixColumns 的模约简漏、一行 padding 验证松懈，都会让密文在另一端彻底无法还原。开源实现里连 const 修饰符、constexpr 查表、__m128i 向量化都有讲究——手写不如读懂现有轻量库源码（比如 tiny-AES-c 的 C 版本），再按需封装。
