1. 签名服务概述：数字签名到底是什么
大家好，我是这次课程的主讲。在正式开始写接口、调接口之前，我觉得有必要先把「数字签名」这个概念讲透。你想想看，如果连签名是干什么的都不清楚，后面调试签名服务时遇到问题，你根本不知道从哪下手。
我最早接触数字签名是在做支付网关的时候。当时有个需求：商户回调时，我得确认这个请求真的是商户发来的，而不是黑客伪造的。嗯，那时候我才真正理解——数字签名，说白了就是「你是谁」和「数据有没有被改过」这两件事的合体。
1.1 什么是数字签名
数字签名不是手写签名的电子版。它是一段通过密码学算法生成的、与原始数据绑定的短字符串。你可以把它理解成数据的「指纹 + 印章」。
- 指纹：数据只要改一个比特，签名就完全变了。
- 印章：只有持有私钥的人才能生成这个签名，别人伪造不了。
举个例子。我写了一段消息：转账给张三 100 元。我用我的私钥对这个消息做一次签名，生成一串字符。别人拿到消息和签名后，用我的公钥去验证——如果验证通过，说明消息确实是我发的，而且内容没被篡改过。
核心要点：数字签名 = 私钥签名 + 公钥验签。私钥只有你一个人有，公钥可以公开给任何人。
1.2 签名服务的应用场景
在实际项目中，签名服务最常见的用途有两个：API 鉴权和数据完整性校验。我分别说一下。
1.2.1 API 鉴权
这是最常用的场景。你调用一个开放平台的 API，比如支付宝、支付、云服务商，它们怎么知道请求是你发的？
流程大致是这样的：
- 你拿到一组
AppId和AppSecret（私钥）。 - 你把请求参数按规则排序，拼接成字符串。
- 用
AppSecret对这个字符串做签名。 - 把签名放在请求头或参数里，发给服务端。
- 服务端用你的
AppId查到对应的公钥，验签。
验签通过，说明请求是你发的；验签失败，直接拒绝。我在做开放平台时，每天要处理上亿次这样的签名校验，性能优化是个大课题，后面章节会细讲。
1.2.2 数据完整性校验
有时候你不需要知道谁发的，但必须确保数据没被改过。比如文件下载、日志传输、配置下发。
我记得有一次，客户反馈说配置文件下发后，服务启动报错。查了半天，发现是中间代理节点把配置文件里的一个换行符给改了。从那以后，我坚持所有配置文件下发都带签名，客户端验签通过才加载。
我的习惯：只要数据经过网络传输，不管是不是 HTTPS，我都建议加一层签名校验。HTTPS 防的是链路窃听，但防不了应用层的中间人篡改。
1.3 签名与加密的区别
这个问题我面试时经常问，但能说清楚的人不多。很多人觉得签名就是加密，其实完全两码事。
| 对比维度 | 数字签名 | 数据加密 |
|---|---|---|
| 核心目的 | 身份认证 + 完整性校验 | 数据保密性 |
| 使用密钥 | 私钥签名，公钥验签 | 公钥加密，私钥解密 |
| 数据是否可读 | 原始数据不隐藏，签名附加在数据旁 | 原始数据被加密成密文，不可读 |
| 典型算法 | RSA-SHA256、ECDSA、HMAC-SHA256 | AES、RSA、SM4 |
| 能否防篡改 | 能，签名与数据绑定 | 不能，密文被改后解密会乱码，但无法检测 |
| 能否防抵赖 | 能，私钥唯一持有者无法否认 | 不能，加密不提供身份认证 |
说白了，签名是「证明这封信是你写的，而且信没被拆过」；加密是「把信锁进保险柜，别人看不到内容」。两者可以组合使用，比如先签名再加密，或者先加密再签名，取决于业务需求。
避坑提醒：我曾经见过一个团队，用 RSA 公钥加密数据，然后用私钥解密，以为这就是签名。这是错的。RSA 加密和 RSA 签名虽然算法相似，但填充方式不同，混用会导致严重的安全漏洞。
1.4 签名服务的整体架构
为了让你对签名服务有个全局认识，我画了一张架构图。这张图会贯穿我们整个课程。
这张图展示了签名服务的完整链路：客户端用私钥生成签名，通过网络传输请求和签名，服务端用公钥验签，最后返回结果。整个课程就是围绕这个链路展开的——从签名生成、传输、验签，到异常处理、性能优化、安全加固。
1.5 小结
这一章我们讲了三个核心概念：
- 数字签名：私钥签名、公钥验签，保证身份和完整性。
- 应用场景：API 鉴权是主流，数据完整性校验是刚需。
- 签名 vs 加密：签名不隐藏数据，加密隐藏数据；签名防篡改防抵赖，加密只防窃听。