应加密xml中指定element节点的textcontent而非字符串匹配；须用dom方法如getelementsbytagname()定位元素，取textcontent加密，保留标签结构，避免格式错乱和解析失败。
XML 加密哪个节点？先定位 Element 而不是字符串匹配
直接对 XML 字符串做正则替换加密，是多数人踩的第一个坑——加密后格式错乱、解析失败、签名失效。XML 是结构化数据，必须用 DOM 或 SAX 操作真实节点。Document.getElementsByTagName() 或 document.getElementById() 才能准确定位到要加密的 Element，再取其 textContent（不是 innerHTML）进行 AES 加密。
常见错误现象：org.xml.sax.SAXParseException: Content is not allowed in trailing section，往往是因为加密后把原始文本替换成 Base64 字符串时，没清理掉换行/空白，或误把父节点整个替换了。
- 使用场景：只加密敏感字段如
<password></password>、<idcard></idcard>、<accountnumber></accountnumber>，保留标签结构和属性不变 - 参数差异：Java 中推荐用
Cipher.getInstance("AES/GCM/NoPadding")（带认证），避免用 ECB；Python 用cryptography.hazmat.primitives.ciphers而非pycrypto（已弃用） - 性能影响：GCM 模式比 CBC 多一次认证计算，但单次加密 Cipher 实例，别每次新建
加密后存哪？用新标签包裹还是覆写 textContent
加密结果不能直接塞进原字段当明文用——比如把 <phone>138****1234</phone> 改成 <phone>U2FsdGVkX1+...</phone>，看似简单，实则埋雷：下游系统可能校验手机号格式、触发正则告警、或被 XSLT 错误解析为非法字符。
正确做法是新增命名空间标记，例如：<phone xmlns:enc="http://www.w3.org/2001/04/xmlenc#" enc:algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc">U2FsdGVkX1+...</phone>，或者统一用 <encrypteddata></encrypteddata> 包裹（符合 W3C XML Encryption 标准）。但实际项目中，更轻量的做法是加后缀标签：<phone_encrypted></phone_encrypted>，并移除原 <phone></phone>。
- 容易踩的坑：加密后未转义特殊字符（如
+、/、=在 Base64 中），导致 XML 解析失败；务必用Base64.getEncoder().encodeToString()（Java）或base64.b64encode().decode()（Python），别手写编码 - 兼容性影响：老系统若用 DOM Level 2 解析，不识别自定义命名空间，建议用后缀方式而非标准
EncryptedData，降低集成成本
AES 密钥怎么传？别硬编码，也别存在 XML 里
密钥管理是 XML 加密中最常被跳过的环节。把密钥写死在代码里、拼在配置文件中、甚至塞进 XML 注释里，等于没加密。AES 是对称算法，加解密必须用同一密钥，但密钥本身不能暴露在传输或存储路径上。
可行方案只有两个：一是用 KMS（如 AWS KMS、阿里云 KMS）动态获取密钥 ID 和加密上下文；二是用主密钥（Master Key）派生会话密钥（Session Key），主密钥存在 HSM 或操作系统密钥库中（如 Java KeyStore、Windows CNG、macOS Keychain）。
- 使用场景：如果只是本地文件加密且无服务端，可用
javax.crypto.KeyGenerator生成随机密钥，再用SecretKeyFactory+ PBKDF2 基于口令派生，但口令必须由用户输入，不能存盘 - 参数差异：GCM 模式必须传入唯一
IV（12 字节），且绝不能复用；IV 可随加密结果一起 Base64 存在同级属性中，如enc:IV="..." - 性能影响：KMS 调用有网络延迟，高频 XML 加密（如每秒百次）需缓存派生密钥，但缓存时间不宜超 5 分钟
解密时怎么还原节点？先校验再替换，别信“看起来像 Base64”
解密逻辑最容易出问题的地方，是凭字符串特征盲目解密。看到字段含 U2FsdGVkX1 就去 AES 解密，结果遇到 Base64 编码的图片 Base64、JWT token、甚至正常含 + 的业务 ID，全崩了。
必须依赖明确的标记：要么检查命名空间属性 enc:Algorithm，要么约定只解密特定后缀标签（如 *_encrypted），并验证解密后内容是否符合原始字段语义（比如解密后是 18 位数字才认定为身份证）。
- 常见错误现象：
BadPaddingException或解密出乱码，90% 是 IV 不匹配、密钥错误、或用了不同填充模式（如加密用 PKCS5，解密用 NoPadding） - 安全提示：解密前必须校验完整性。GCM 自带认证标签，CBC 则需额外加 HMAC；没认证的解密结果不可信，可能已被篡改
- 容易被忽略的点：XML 解析默认不展开实体引用，若加密内容含
<等转义字符，解密后需手动调用StringEscapeUtils.unescapeXml()（Apache Commons）或等效处理，否则字段值仍是转义态
