fiber 框架本身不内置公钥私钥验证或解密逻辑，所有加解密必须由开发者手动集成 crypto 库（如 go 的 crypto/rsa、crypto/ecdsa 或第三方库如 golang.org/x/crypto/chacha20poly1305），且验证与解密需在中间件或路由处理器中显式调用，不能依赖 fiber 自动处理。
直接说结论：Fiber 框架本身不内置公钥私钥验证或解密逻辑，所有加解密必须由开发者手动集成 crypto 库（如 Go 的 crypto/rsa、crypto/ecdsa 或第三方库如 golang.org/x/crypto/chacha20poly1305），且验证与解密需在中间件或路由处理器中显式调用，不能依赖 Fiber 自动处理。
为什么 Fiber 不提供内置的公钥验证中间件
Fiber 是轻量级 HTTP 框架，设计哲学是“不封装底层加密细节”。它没有像 Express 的 express-jwt 或 Django 的 django.contrib.auth 那样的认证抽象层。所有密钥加载、签名验证、密文解密都得你自己写代码完成。
-
fiber.App不认识-----BEGIN PUBLIC KEY-----这类 PEM 字符串 - 没有
ctx.VerifyRSASignature()或ctx.DecryptWithPrivateKey()这类方法 - 你传给
ctx.Body()的密文，Fiber 只当普通字节流，不会自动调用rsa.DecryptPKCS1v15
公钥验证（如 JWT 签名验签）典型步骤
常见于 API 认证场景：客户端带 Authorization: Bearer <jwt></jwt>，服务端用公钥验证签名有效性。
- 用
ioutil.ReadFile或os.ReadFile读取公钥文件，再用jwt.ParseRS256（需github.com/golang-jwt/jwt/v5）配合func(token *jwt.Token) (interface{}, error)回调加载*rsa.PublicKey - 务必检查
token.Valid == true且err == nil，二者缺一不可；仅检查err可能漏掉签名过期但格式合法的 token - 若公钥来自环境变量（如 base64 编码的 PEM），需先
base64.StdEncoding.DecodeString，再pem.Decode，最后x509.ParsePKIXPublicKey - 别在每次请求都重复解析 PEM——应启动时一次性解析并缓存
*rsa.PublicKey实例
私钥解密（如接收加密的 payload）实操要点
适用于客户端用服务端公钥加密敏感字段（如身份证号），服务端用私钥解密的场景。
- 私钥文件必须是 PEM 格式且以
-----BEGIN RSA PRIVATE KEY-----或-----BEGIN PRIVATE KEY-----开头；PKCS#8 格式（后者）更通用，Go 原生支持，PKCS#1 需额外转换 - 解密前必须校验密文长度：2048 位 RSA 私钥最多解密 256 字节密文（PKCS#1 v1.5）或 214 字节（OAEP）；超长会 panic 或返回
crypto/rsa: decryption error - 推荐用
rsa.DecryptOAEP而非DecryptPKCS1v15，前者抗选择密文攻击，且错误更明确（如crypto/rsa: verification error） - 密文通常 Base64 编码传输，解密前先
base64.StdEncoding.DecodeString(ctx.FormValue("encrypted_data"))，再传入DecryptOAEP
容易被忽略的关键细节
最常出问题的地方不在算法调用本身，而在密钥生命周期和上下文传递：
- 私钥绝对不能硬编码在源码里，也不能通过
os.Getenv("PRIVATE_KEY")直接传字符串——PEM 解析失败时错误信息极难定位；应从文件或安全存储（如 HashiCorp Vault）加载，并做strings.TrimSpace清理换行 - Fiber 的
ctx.Context不保存密钥实例，每次请求都重新加载会严重拖慢性能；必须用全局变量或依赖注入容器（如uber-go/fx）缓存已解析的*rsa.PrivateKey - 验签和解密失败时，不要返回详细错误（如
"invalid signature: key mismatch"），避免泄露密钥存在性或格式信息；统一返回401 Unauthorized或400 Bad Request
