PASETO不是“比JWT更难攻破”的替代品，而是通过协议层移除alg:none、算法混淆等选项，从设计上消除常见攻击面，使开发者几乎无法错用；V4是当前生产首选，强制区分local/public模式并默认启用AEAD。
paseto 不是“比 JWT 更难攻破”的替代品——它是通过设计上消除常见攻击面来降低出错概率。JWT 的漏洞（如 alg: none、算法混淆、密钥类型误用）本质是开发者配置错误导致的；而 paseto 从协议层就移除了这些选项。你不需要“更小心地用”，而是“几乎没法错用”。
选对版本和模式：V4 是当前生产首选
Go 生态主流库（如 github.com/o1egl/paseto 和 aidanwoods.dev/go-paseto）都支持 V2–V4，但 V4 是唯一同时提供 local（对称加密）和 public（非对称签名）且默认启用 AEAD（认证加密）的版本。
- V2/V3 已被标记为 legacy，不推荐新项目使用
- V4
local使用AES-GCM，密钥长度固定为 32 字节；public使用Ed25519，私钥 64 字节，公钥 32 字节——不接受其他算法或长度 - 如果你需要服务间通信（如微服务 A → B），用
public模式；若只是 API 与前端交互且密钥可安全共享，local更轻量
初始化时必须显式指定目的（purpose）
paseto 的 token 头部强制包含 purpose 字段（local 或 public），且解析时会校验——这直接堵死了 JWT 中常见的“用 RS256 公钥去验 HS256 签名”类混淆攻击。
- 生成时：
paseto.V4.LocalToken(symmetricKey, payload, nil)中的nil是可选的options，但purpose由函数名决定，不可覆盖 - 解析时：
paseto.V4.VerifyLocal(token, symmetricKey, &payload)—— 如果传入的是publictoken，会直接返回ErrInvalidToken，不会尝试解密 - 别手写 header 或伪造 purpose：库不暴露 header 修改接口，硬编码修改会导致
token parse failed: invalid version or purpose
密钥管理不能靠字符串硬编码
对称密钥（local）和私钥（public）都必须以二进制形式加载，且长度严格校验。任何字符串转字节的松散处理都会失败。
立即学习“go语言免费学习笔记（深入）”；
-
local密钥必须是 32 字节：symmetricKey := []byte("exactly_32_bytes_for_paseto_v4!")—— 少 1 字节就 panic -
public私钥应从 PEM 文件读取并解码：privKey, _ := paseto.ParsePrivateKeyFromPEM(pemBytes)，不是 Base64 解码后直接当 []byte 用 - 环境变量里存密钥？别用
os.Getenv("PASETO_KEY")直接赋值——它返回 string，需先hex.DecodeString()或base64.StdEncoding.DecodeString()，否则长度不对
验证失败时不要忽略错误类型
paseto 的错误是具体且不可绕过的：ErrExpired、ErrInvalidToken、ErrInvalidKey、ErrInvalidPurpose。不像 JWT 库常把所有错误归为 ValidationError，然后靠字符串匹配判断原因。
- 检查过期应明确判断：
if errors.Is(err, paseto.ErrExpired) { /* 返回 401 */ } -
ErrInvalidToken可能是篡改、格式错误或 purpose 不匹配——此时不应记录详细错误给客户端，但服务端日志要保留原始 token 前缀用于审计 - 别用
err != nil一锅端：比如ErrInvalidKey表示密钥加载失败，属于启动期配置错误，需 crash 而非返回 401
真正的难点不在“怎么写”，而在“怎么让团队不绕过它”。paseto 的安全收益来自它的刚性约束——一旦你允许自定义算法、接受任意长度密钥、或在解析时不校验 purpose，你就退回到了 JWT 的风险模型。它不防恶意攻击者，只防疲惫的开发者。
