直接用mybatis拦截器+aes可实现oracle敏感字段透明加解密，但需手动处理raw类型绑定、统一aes填充与编码、固定iv、禁用模糊查询，并升级ojdbc驱动至23.7.0.26.05以上。
直接用 MyBatis 拦截器 + AES 对称加密，就能在 Spring Boot 中实现 Oracle 敏感字段的透明加解密。这不是配置开关或换一个 starter 就能搞定的事——Oracle 的 VARCHAR2 字段长度限制、字符集（AL32UTF8）、RAW 类型兼容性，都会在加解密后暴露问题。必须手动对齐底层行为。
MyBatis 拦截器必须处理 Oracle 的 RAW 类型绑定
Oracle 驱动默认把加密后的字节数组（byte[]）当成 BLOB 或 RAW 处理，而 MyBatis 的默认 TypeHandler 在遇到 byte[] 时可能走错路径，导致插入失败或乱码。你得显式指定字段使用 ByteArrayTypeHandler，否则拦截器里加密完的 byte[] 会被 Oracle JDBC 错误地转成字符串再入库。
- 在 Mapper XML 中为加密字段显式指定
typeHandler="org.apache.ibatis.type.ByteArrayTypeHandler" - 如果用注解方式（
@Select/@Insert），需配合@Options(useGeneratedKeys = false)并确保参数类型是byte[]，不能依赖自动推导 - Oracle 表字段建议定义为
RAW(256)（而非VARCHAR2），避免字符集转换污染二进制数据
AES 加密必须统一填充模式和字符编码
Oracle 不识别 Java 默认的 PKCS#5 填充，也不处理 UTF-8 字节序标记（BOM）。如果你用 AES/CBC/PKCS5Padding 加密字符串再转 byte[]，入库后从 RAW 取出再解密时，若没严格还原相同算法参数，就会抛 javax.crypto.BadPaddingException。
- 固定使用
AES/CBC/NoPadding+ 手动补零（0x00）到 16 字节倍数，避免 Oracle 驱动在传输中截断或填充 - 所有加解密操作前先做
string.getBytes(StandardCharsets.UTF_8)，禁止用String.getBytes()（依赖平台默认编码） - IV 必须固定且可复现（比如用字段名 + 主键哈希生成），不能每次随机——否则 Oracle 查询无法做等值匹配（即使只支持精确查询）
Oracle 查询时不能依赖 LIKE 或函数索引做模糊匹配
加密后的 RAW 值是完全打散的二进制序列，WHERE phone LIKE '%138%' 这种写法在加密字段上永远返回空。别指望 Oracle 函数索引（如基于 UTL_RAW.CAST_TO_VARCHAR2）能安全加速，那等于把密文转明文再查，破坏了加密前提。
- 业务层需要提前约定：加密字段只允许等值查询（
=）和主键关联（IN） - 如果真要模糊搜索手机号前缀，得在插入时额外存一个哈希前缀字段（如
phone_prefix_hash CHAR(8)），用HMAC-SHA256(phone.substring(0,3), salt)计算，查询时比对哈希 - Oracle 12c+ 支持虚拟列，但虚拟列表达式不能调用自定义 Java 函数，所以不能直接放解密逻辑
ShardingSphere 的 encryptor 配置在 Oracle 下要绕开 driver 版本陷阱
ShardingSphere 的 encryptor 模块虽宣称支持 Oracle，但它底层依赖 PreparedStatement.setObject(index, value, Types.VARBINARY)。Oracle 19c 之前的驱动（ojdbc8 19.3 以下）对 Types.VARBINARY 处理不一致，容易触发 ORA-01461: can bind a LONG value only for insert into a LONG column。
- 强制升级 ojdbc 驱动到
ojdbc11-23.7.0.26.05或更高（确认 release note 明确写了 “support VARBINARY binding for encrypted columns”） - ShardingSphere 配置中禁用
query-with-cipher-column: true，改用false，即只加密存储、查询时用明文字段名（如SELECT id, phone_encrypted FROM user），由应用层自行解密 - 不要用 ShardingSphere 的
assistedQueryColumn，它在 Oracle 上生成的 SQL 会多一层TO_CHAR转换，破坏二进制完整性
真正卡住落地的，从来不是“怎么加解密”，而是 Oracle 驱动怎么把 byte[] 原样塞进 RAW、怎么让 MyBatis 不在中间偷偷 toString、以及业务方是否接受放弃模糊查询。这些细节一旦漏掉一个，就会在压测时爆出 ORA-01465: invalid hex number 或解密后全是乱码。
