必须用标准XMLSignature而非手算哈希，因其内置Canonicalization可消除XML序列化差异，确保语义一致；需统一规范化方法、严格校验Reference URI与DigestValue、嵌入完整X.509证书、保持编码与Content-Type全程一致。
XML 数字签名用 XMLSignature 还是手算哈希？
必须用标准 XMLSignature（如 Java 的 javax.xml.crypto.dsig、.NET 的 SignedXml、Python 的 lxml.etree.Signature），不能自己对 XML 字符串做 sha256 后存进字段。原因很简单：XML 有多种合法序列化形式（换行、缩进、属性顺序、命名空间声明位置），同一逻辑文档可能生成不同字节流。手算哈希只校验“字符串是否被改”，不校验“语义是否一致”。XMLSignature 内置 Canonicalization（规范化）步骤，把 XML 先转成唯一字节序列再签名，这才是防篡改的起点。
常见错误现象：Signature validation failed: signature digest mismatch —— 往往是服务端和客户端用了不同 CanonicalizationMethod（比如一个用 InclusiveC14N，一个用 InclusiveC14NWithComments），或解析时自动格式化了 XML 导致字节变化。
- Java 默认用
CanonicalizationMethod.INCLUSIVE，.NET 默认用XmlDsigC14NTransformUrl（即 Inclusive C14N），两者兼容；但若 Java 改成EXCLUSIVE，.NET 就必须同步改 - Python 的
lxml默认用exclusive_c14n，和主流不一致，需显式传c14n_method="inclusive" - 签名前务必关闭 XML 解析器的自动空白处理（如 Java 的
DocumentBuilderFactory.setIgnoringElementContentWhitespace(true)会导致签名失效）
上传时验证签名必须检查 Reference 的 URI 和 DigestValue
很多人只验签名值本身（SignatureValue），却忽略 Reference 节点里指向的被签名内容是否真实存在、是否被替换。XML 签名可以只签某个子元素（如 URI="#payment"），也可以签整个文档（URI=""）。如果上传的 XML 被恶意替换了未签名的部分（比如改了外层 <request></request> 的时间戳），而验证逻辑没检查 Reference 是否覆盖关键字段，那就完全失效。
实操建议：
- 强制要求所有关键业务字段（如
amount、account_id、timestamp）必须落在某个带ID属性的元素内，且该元素被Reference显式引用（URI="#order"） - 验证时用
validate()方法后，立刻调用getValidity()（Java）或检查signedXml.CheckSignature()返回值，再手动遍历SignedInfo/Reference，确认每个URI对应的节点确实存在且未被移除 - 禁止接受
Reference中URI为空但Transforms包含XPath的情况——XPath 可被构造绕过，风险高
KeyInfo 里放证书还是只放公钥？
必须放完整 X.509 证书（X509Data/X509Certificate），而不是只放 KeyValue/RSAKeyValue。原因：公钥本身无法溯源，攻击者可替换签名并填入自己的公钥，只要服务端不校验证书链就验得过。而证书包含颁发者、有效期、用途扩展项（Key Usage = digitalSignature），还能走 OCSP 或 CRL 检查吊销状态。
容易踩的坑：
- 客户端签名时用了自签名证书，但服务端验证逻辑没配置信任该根证书 →
SignatureException: Certificate not trusted - 证书里
Subject Alternative Name是域名，但服务端校验时只比对CommonName→ 实际已不推荐 CN 校验，应以 SAN 为准 - 上传的 XML 里
KeyInfo被删掉，但验证代码没检查KeyInfo是否存在就直接取公钥 → 签名变成“无源之水”，完全不可信
HTTP 上传时 Content-Type 和编码要和签名时严格一致
XML 签名绑定的是字节流，不是逻辑结构。如果签名时用 UTF-8 编码生成 SignatureValue，但上传时服务端用 ISO-8859-1 解析，哪怕只是多了一个 BOM 或换行符，DigestValue 就对不上。同样，Content-Type 声明的字符集必须和实际 payload 一致，否则某些框架（如 Spring MVC）会二次转码。
实操要点：
- 签名前明确设置 XML 声明编码：，且生成字节流时用
StandardCharsets.UTF_8写出 - HTTP 请求头必须带
Content-Type: application/xml; charset=UTF-8，不能只写application/xml - 服务端接收时禁用自动字符集探测（如 Tomcat 的
URIEncoding不影响 body，但某些 XML 解析器会读Content-Type头来决定解码方式） - 调试时用
curl -v或 Wireshark 抓包，对比上传的原始字节和签名时计算摘要用的字节是否完全一致
最麻烦的其实是规范化和编码这两个环节——它们不报错，但会让签名无声失效。上线前一定拿原始字节做一次 sha256sum 对账。
