TDE不提供Java手动加解密接口，其本质是数据库存储层自动加解密，应用完全无感；ORA-28374和ORA-28365表明JDBC未启用SSL/TLS导致Oracle Wallet未加载，密钥不可用。
TDE 本身不提供 Java 端的“手动加解密接口”——它根本不是靠你在代码里调用 encrypt() 或 decrypt() 实现的。只要配置正确，Java 应用对加密列的读写完全无感，就像操作普通字段一样。真正在 Java 层“主动加解密”的需求，基本都属于误用场景。
ORA-28374 和 ORA-28365 是什么信号？
这两个错误几乎总意味着：JDBC 连接没走 SSL/TLS，导致 Oracle Wallet 没加载，TDE 密钥不可用。
-
ORA-28374：“找不到已加载的主密钥” -
ORA-28365：“wallet 未打开”
它们不是数据库配置错了，而是 JDBC 驱动压根没触发 Wallet 加载流程。Oracle Wallet 默认只在 SSL 握手阶段被客户端（JDBC）自动加载，不配 TCPS，Wallet 就是死的。
你必须：
立即学习“Java免费学习笔记（深入）”；
- 使用
tcps://协议替换jdbc:oracle:thin:@中的localhost:1521 - 显式指定
javax.net.ssl.trustStore和密码（指向包含 Wallet 根证书的 JKS） - 确保服务端
sqlnet.ora启用了SSL_SERVER_DN_MATCH=ON并配了合法证书 - Wallet 文件（
ewallet.p12）必须由 DBA 提供，且密码已知（用于首次 open）
不满足以上任意一条，SELECT 加密列就会报错，哪怕 SQL 在 SQL*Plus 里能跑通。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
加密列 vs 加密表空间：Java 行为有差异吗？
没有差异。对应用层完全透明，但底层行为不同，影响的是运维和权限：
- 列级加密：只加密指定字段（如
CREDIT_CARD_NO），索引仍可正常使用（等值查询不降速） - 表空间级加密：整个
DATAFILE块加密，所有新创建对象自动受保护，但ALTER TABLE ... MOVE会触发全量重写
Java 程序无需感知区别，但要注意：
- 如果业务用户没有
ENCRYPT ANY TABLE权限，建表时指定ENCRYPTION USING 'AES256'会失败 - 对已有表添加加密列（
ALTER TABLE t ADD (ssn VARCHAR2(11) ENCRYPT)）会锁表并重写全表，大表慎用 - 不支持加密
LOB、LONG、外键列、物化视图日志列
为什么别在 Java 里自己实现 DBMS_CRYPTO 的等效逻辑？
因为你会重复踩三类坑：
- 字符集与填充方式不一致：Oracle 默认用
ZHS16GBK转 RAW，Java 用 UTF-8 + PKCS5Padding，结果必然解不出 - 密钥派生逻辑黑盒：
DBMS_CRYPTO的ENCRYPT函数若传入字符串密钥，内部实际调用的是 PBKDF2 变种，Java 很难逆向复现 - 没有密钥版本管理：Oracle Wallet 支持密钥轮换，而硬编码在 Java 的密钥一旦泄露或过期，全量数据就不可逆
真正需要“Java 控制加解密”的场景，应该用 DBMS_CRYPTO 包（需授权）+ 存储过程封装，而不是在应用层拼 raw hex。
TDE 的核心约束始终是：Wallet 必须由数据库进程管理，密钥绝不落地到应用内存。任何试图绕过 Wallet、把密钥塞进 Java 配置或环境变量的做法，都等于废掉 TDE 的合规价值——等保/PCI DSS 审计第一眼就会卡在这里。
