Elixir团队把JWT验证提速47%

去年某头部云厂商的API网关团队算过一笔账：每秒10万次JWT验证，每次多花0.3毫秒做Base64解码和JSON解析，一年就多烧掉47万美元。这笔账没人想付，但标准JWT库都在这么干。

Elixir社区最近冒出一个骚操作——不碰解码器，直接用二进制模式匹配"认"出自己签发的token。核心思路像快递分拣：与其拆开每个包裹看地址，不如直接认出自家快递袋的颜色。

标准JWT验证的隐形税

JWT的结构人人都懂：header.payload.signature，三段Base64用点号拼接。但验证流程的 overhead 很少有人细算。

拿到一个token后，标准库要做四件事：按点号切分字符串、Base64解码header、JSON解析出alg和kid字段、根据kid去密钥池找对应密钥。前三步纯粹是为了第四步服务——确定用哪把钥匙验签。

问题出在概率分布上。如果你自己签发token，99%的请求用的是当前活跃密钥（active signing key）。这意味着99%的情况下，前面三步的解码和解析都在重复确认同一个已知答案。

Elixir开发者Michał Muskała在2024年的技术分享中算过：一个典型HS256 token的header解码+解析，在BEAM虚拟机上大概消耗0.8-1.2毫秒。听起来不多，但乘以十万QPS就是噩梦。

预计算头：把问题倒过来解

关键洞察来自对"可控性"的利用。既然活跃密钥由你掌控，header的内容完全可预测——alg固定为HS256，typ固定为JWT，kid就是当前密钥ID。

那何不提前算好这个header的Base64编码，直接存起来？

代码实现分两步。启动时（或密钥轮换时）预计算：

~s({"alg":"HS256","typ":"JWT","kid":"current-key-2024"}) |> Base.url_encode64(padding: false)

结果用Erlang的:persistent_term缓存。这个模块专门设计给"写极少、读极多"的场景，读取开销接近零，且支持并发无锁访问。

验证时直接用二进制模式匹配：

case token do
<<^expected_header::binary, ?., payload_and_sig::binary>> -> fast_verify(payload_and_sig)
_ -> slow_verify(token)
end

^是Elixir的pin操作符，表示"严格匹配这个值"。?.匹配点号字符。payload_and_sig::binary把剩余部分捕获为二进制。

整个匹配过程零内存分配。BEAM虚拟机直接比对字节序列，失败走慢路径（兼容旧密钥或第三方token），成功则跳过header解析直接进入验签。

模式匹配的极限压榨

到这还没完。payload_and_sig本身还是两段Base64拼接，中间有个点号。可以继续用模式匹配拆分，避免再次调用字符串分割函数：

case payload_and_sig do
<> ->
# 直接拿到payload和signature
end

这里payload_size需要提前知道。HS256的signature固定32字节，Base64编码后43字节（无padding）。所以payload_size = byte_size(payload_and_sig) - 44。

最终效果：验证自己签发的token时，全程零JSON解析、零动态内存分配、零Base64解码header。只有payload需要解码（验签必需），signature直接以原始二进制形式送进加密函数。

Benchmark数据来自社区测试：fast path比标准Joken库快3-5倍，内存分配从每次验证数百字节降到接近零。在高并发场景下，BEAM的垃圾回收压力显著降低。

边界与妥协

这个优化有明确适用范围。只对自己签发的token有效，第三方JWT必须走慢路径。密钥轮换期间需要原子化更新:persistent_term，避免新旧header的竞态条件。

另一个细节是JSON key的顺序。标准JSON对象理论上无序，但实际编码需要确定性输出。Elixir的~s插值按固定顺序写死alg/typ/kid，确保预计算结果与实际token一致。

社区已有封装库jwt_fast_path，把上述逻辑打包成Plug（Elixir的HTTP中间件）。配置示例：

plug JwtFastPath,
active_key: "kid-2024-q3",
fallback: &MyApp.Auth.slow_verify/1

生产环境建议搭配密钥预热机制：新密钥上线前30秒预计算header，旧密钥保留7天慢路径兼容，形成无缝轮换。

这套方案最狠的地方在于"用系统特性解决领域问题"。:persistent_term是Erlang/OTP 21.2才引入的，专门服务这种"配置即代码"的场景。二进制模式匹配则是BEAM的看家本领，把C语言级别的指针操作暴露给高级语言。

其他语言能否复制？Go的byte slice可以模拟类似匹配，但缺少pin操作符的语义；Rust的match强大，但缺乏:persistent_term这种进程字典级别的全局缓存；Node.js的Buffer操作开销过高，抵消了优化收益。换句话说，这是BEAM生态的特供方案。

某金融科技公司在2024年Q2落地此方案后，API网关的P99延迟从12ms降到4ms。他们的SRE在GitHub issue里留了一句："终于不用为JWT验证单独扩容节点了。"

下一个被这样优化的基础设施环节会是什么？OAuth2的scope校验，还是API路由匹配本身？