用 Forge.js 构建高性能三维可视化应用的实战经验

为什么我最近又在折腾 Forge.js？

最近项目里要处理一些 WebCrypto 相关的逻辑，比如生成密钥、签名、验签，还有和后端对接 PKCS#8 格式的私钥。一开始我直接用浏览器原生的 crypto.subtle API，结果发现兼容性问题一堆，尤其在旧版 Edge 和某些国产浏览器里直接报错。后来同事甩给我一个库：Forge.js。我心想，行吧，老古董了，但至少能跑通。

但 Forge.js 本身不是“方案”，它是一套工具集。真正的问题是：**怎么用它？用哪种方式集成？要不要和其他库混搭？** 所以我对比了三种主流用法：纯 Forge.js、Forge + WebCrypto 混合、以及完全不用 Forge 改用其他现代库（比如 elliptic + asn1.js）。折腾了几天，踩了几个坑，今天就聊聊我的真实体验。

纯 Forge.js：简单粗暴，但有点“重”

这是我最开始的选择。Forge.js 从 2010 年左右就开始维护，功能非常全，RSA、ECC、AES、HMAC、X.509、PKCS#7、PKCS#8 全都支持，而且文档虽然老，但例子管用。代码写起来也直白：

const forge = require('node-forge');

// 生成 RSA 密钥对
const keypair = forge.pki.rsa.generateKeyPair({ bits: 2048 });

// 私钥转 PEM（PKCS#8 格式）
const privateKeyPem = forge.pki.privateKeyToPem(keypair.privateKey);

// 签名
const md = forge.md.sha256.create();
md.update('hello world', 'utf8');
const signature = keypair.privateKey.sign(md);

优点很明显：**一行代码搞定签名，不用管底层细节**。尤其在 Node.js 环境里，跑得稳稳的。前端也能用，打包后大概 300KB+，gzip 后 100KB 左右——对现代前端来说不算小，但如果你只做管理后台或者内部工具，完全能接受。

但问题也来了：**太重了**。如果你只需要做 ECC 签名，它却把整个 RSA、X.509 解析器都打包进去了。而且它的 API 风格偏“Java 式”，回调多、链式调用少，写起来有点啰嗦。更烦的是，它的错误信息经常是 “Invalid input” 这种，调试时得靠猜。

我踩过一个坑：用 forge.pki.privateKeyFromPem 解析后端给的 PKCS#8 私钥，结果在某些格式下（比如带加密的）直接崩。后来翻源码才发现，它默认不支持加密的 PKCS#8，得自己加解密逻辑。折腾了半天，最后还是让后端改输出无加密的私钥才搞定。

Forge + WebCrypto 混合：灵活但麻烦

为了解决体积问题，我试过只用 Forge 做格式转换（比如 PEM 转 JWK），再用原生 WebCrypto 做实际运算。思路是这样的：

// 1. 用 Forge 解析 PEM 私钥
const privateKey = forge.pki.privateKeyFromPem(pemString);

// 2. 转成 JWK
const jwk = {
  kty: 'RSA',
  n: forge.util.encode64(privateKey.n.toByteArray()),
  d: forge.util.encode64(privateKey.d.toByteArray()),
  // ...其他字段
};

// 3. 用 WebCrypto 导入
const cryptoKey = await window.crypto.subtle.importKey(
  'jwk',
  jwk,
  { name: 'RSASSA-PKCS1-v1_5', hash: 'SHA-256' },
  false,
  ['sign']
);

// 4. 签名
const signature = await window.crypto.subtle.sign(
  { name: 'RSASSA-PKCS1-v1_5' },
  cryptoKey,
  new TextEncoder().encode('hello world')
);

理论上这方案很美：**体积小（只用 Forge 做解析）、性能好（WebCrypto 是原生加速）**。但实际写起来简直噩梦。JWK 字段映射容易出错，尤其是大数（BigInteger）的字节序处理，Forge 的 toByteArray() 默认是大端，但 WebCrypto 要求无符号大端，中间还得补零对齐。我搞了整整一天，签名结果始终和后端对不上，最后发现是 e（公钥指数）字段漏了，默认应该是 65537，但 Forge 不会自动补。

而且这种混合方案调试成本高。一旦出问题，你得同时查 Forge 的解析逻辑和 WebCrypto 的导入规则，两边文档风格还不一样。**除非你对密码学格式特别熟，否则别轻易尝试**。

完全不用 Forge？试试现代轻量库

其实现在有不少更轻量的替代品。比如只做 ECC 的话，elliptic 库只有 30KB（gzip 后 10KB），配合 asn1.js 解析 DER/PEM，整体体积能压到 50KB 以内。代码也更“现代”：

import EC from 'elliptic';
import { der } from 'asn1.js';

const ec = new EC('p256');

// 从 PEM 私钥恢复（需先 base64 解码 + ASN.1 解析）
const privateKey = ec.keyFromPrivate(derPrivateKeyBytes);

// 签名
const sig = privateKey.sign('hello world', 'hex');

但问题在于：**你需要自己拼装整个流程**。PEM 解析、ASN.1 结构定义、哈希计算、签名格式封装……每一步都可能出错。而且这些库通常只专注一个领域（比如 elliptic 只做椭圆曲线），你要做 RSA 就得换另一个库，生态碎片化严重。

我试过一次，结果发现 asn1.js 的 ASN.1 定义写起来像写编译器，光 PKCS#8 的结构就写了 50 行。最后还是放弃了——**省下的那几十 KB，不值得花三天时间造轮子**。

我的选型逻辑：看场景，别死磕

折腾完这三套方案，我的结论很务实：

• 如果是内部系统、管理后台、Node.js 服务端：直接上纯 Forge.js。别纠结体积，稳定性和开发效率更重要。它虽然老，但经过十年验证，坑基本都填平了。
• 如果是面向公众的轻量级前端应用（比如嵌入第三方页面的小工具）：优先考虑 WebCrypto 原生方案。如果必须处理 PEM/PKCS#8，再引入 Forge 做格式转换，但要做好混合调试的心理准备。
• 千万别为了“现代化”而强行替换。我见过有人为了用 async/await 把 Forge 包一层 Promise，结果代码更乱了。Forge 的同步 API 在密钥生成这种耗时操作里反而容易控制（比如加个 loading）。

另外提醒一点：**Forge.js 在浏览器里要用 UMD 版本**，别直接 import node-forge，否则 Webpack 会把整个 Buffer 模拟层打包进去，体积爆炸。正确的做法是：

<!-- CDN 引入 -->
<script src="https://cdn.jsdelivr.net/npm/node-forge@1.3.1/dist/forge.min.js"></script>
<script>
  // forge 会挂到 window.forge
  const keypair = forge.pki.rsa.generateKeyPair({ bits: 2048 });
</script>

或者用 Webpack 的 externals 配置，避免重复打包。

结尾：没有银弹，只有权衡

Forge.js 不是新技术，但它解决了一个真实问题：**在浏览器里可靠地处理各种密码学格式**。虽然它笨重、API 老旧，但在很多场景下，它仍然是“最不坏”的选择。我现在的项目里，只要涉及非对称加密或证书处理，第一反应还是 “forge 一把梭”，省心。

以上是我踩坑后的总结，有更优的实现方式欢迎评论区交流。比如有没有人用 Forge + Web Workers 做密钥生成优化？或者有更好的 PEM 解析轻量方案？期待你的经验。