返回
创建于
状态
公开
下面给你一张「够用且靠谱」的对比速查表，涵盖常见 JWT 签名算法在性能、体积、部署难度上的差异。你用 JWT_ALGO 选型时，基本按这个来就行。
性能&特性对比（概览）
| 算法 | 签名速度 | 验证速度 | 典型签名长度（Base64URL后） | 密钥/部署 | 兼容性 | 适用场景 |
|---|---|---|---|---|---|---|
| HS256 (HMAC-SHA256) | 🟢 最快 | 🟢 最快 | ≈ 43 字符（32B） | 只需共享 secret（对称）→ 密钥分发要小心 | 广泛 | 内网/同域服务高 QPS；简单、成本低 |
| RS256 (RSA-2048 + SHA256) | 🟡 慢（相对） | 🟢 较快 | ≈ 342 字符（256B） | 私钥签名、公钥验证，易做密钥分发与轮换 | 最通用/标准 | 第三方/多方验证；网关/开放平台 |
| RS512 (RSA-2048 + SHA512) | 🟡≈RS256，略慢 | 🟢≈RS256，略慢 | ≈ 342 字符 | 同 RS256 | 略差（部分老实现只测 RS256） | 很少有必要（哈希改 256→512 对安全提升不明显） |
| ES256 (ECDSA-P256 + SHA256) | 🟢 较快 | 🟡 较慢（相对 RSA） | ≈ ~96 字符（~64–72B DER 编码） | 非对称；密钥小，便于移动端/硬件 | 好（少数旧库兼容坑） | 追求小体积（带宽/存储敏感）、移动端/IoT |
常见性能排序（CPU 无专门硬件加速，Go/OpenSSL 等主流实现下） 吞吐/延迟：HS256 ≫ ES256（sign 更快 / verify 更慢） ≈ RS256（sign 慢 / verify 快）
- RSA：签名 慢、验证 快（e=65537）
- ECDSA：签名 快、验证 慢（相对 RSA）
- HMAC：对称 MAC，签名/验证都非常快
选型建议（结合你的场景）
- 内网微服务 / 极高 QPS / 简单可靠：优先 HS256。 缺点是需要在签发方与验证方安全地共享同一个 secret（可用 KMS/密钥注入+短周期轮换缓解）。
- 对外/多方验证（开放平台、前后端/第三方都要验）：优先 RS256。 私钥仅在签发端；下发公钥或 JWKS，便于轮换与权限隔离。生态与文档最佳。
- 带宽/存储敏感（例如 cookie、Header、移动/IoT）、或更小密钥：可选 ES256。 签名更小、签名速度快，但验证偏慢、历史兼容偶有坑；确保你的库/网关稳定支持。
- RS512：通常不需要。相较 RS256 提升有限，反而增加计算与兼容成本。提高 RSA 密钥位数更实际（如 3072/4096），但也会显著变慢和变大。
大致延迟区间（仅供估算，单核、常见 x86，无硬件加速）
- HS256：约 < 0.05 ms/op（签名/验证都极快）
- RS256（2048位）：签名 ~0.5–1.5 ms，验证 ~0.1–0.4 ms
- ES256（P-256）：签名 ~0.2–0.6 ms，验证 ~0.4–1.0 ms
实际取决于语言/库版本、是否开启 AVX/硬件加速、密钥长度、是否启用 JIT/汇编优化、以及你的运行环境（容器/虚拟化/能耗模式）。
体积影响（JWT 总长度）
-
头/载荷一样时，主要差在签名段：
- HS256：~43 字符
- ES256：~96 字符（DER 可变）
- RS256/RS512（2048位）：~342 字符
-
这直接影响 HTTP Header 体积、Cookie 大小与传输/存储成本。
Go 实战基准（可直接跑）
小结（怎么选）
- 追求极致性能/QPS：
HS256 - 需要非对称、跨服务/第三方：
RS256（首选，生态最佳） - 需要更小签名/移动端友好：
ES256（注意验证成本与兼容性） - 避免：
RS512（除非有合规或明确要求）
如果你把 JWT_ALGO 做成可切换（例如 HS256 / RS256 / ES256），建议同时支持：
kid+ JWKS（便于密钥轮换）- 短有效期 + 刷新机制（降低密钥泄漏风险）
- 针对
ES256提前做兼容性验收（网关/SDK/第三方）