企业官网建设流程全解析

很多服务端开发者接触 Node.js 的时间一长，都会碰到一个绕不开的痛点：口令哈希、令牌签名这类密码学操作，在纯 JavaScript 里又慢又吃 CPU。我最早用 bcryptjs 做了个注册登录接口，压测一上来，事件循环的延迟肉眼可见地往上涨。后来换成了原生的 bcrypt 模块，情况好了一些，但真正让我彻底改观的，是把这些底层能力换成 Rust 实现的 node-rs 组件。Argon2、Bcrypt 和 JSON Web Token 这三样东西，可以说是现代服务端认证体系的三块基石，恰好也是 node-rs 里最实用的几个模块。这篇内容我会从选型思路到完整实现，手把手过一遍这三个模块的实战用法，帮你把认证链路里最吃性能的部分真正降下来。

这个方案适合谁？如果你正在维护一个注册登录模块，被 bcryptjs 压测时的 CPU 打满折腾过；如果你想了解 Argon2 为什么越来越被推荐，但又不想花时间啃论文；或者你只是想在 Express / Fastify 里快速落地一套带 JWT 的服务端鉴权——这篇都值得看完。我会把 node-rs 的核心模块拆开讲，包括参数怎么调、和常见库的差异在哪、以及我实际迁移过程中踩过的坑。

1. 为什么选 node-rs：把密码学计算从主线程挪走

1.1 Node.js 密码学操作的性能瓶颈在哪

先说个容易被忽略的事实：Node.js 本身是单线程事件循环，纯 JavaScript 实现的密码学算法（比如 bcryptjs）会在 CPU 密集计算时长时间占用主线程。你有过这种体验吗，接口压力一大，所有请求都在等一个哈希计算完成，日志里的阻塞时间动辄上百毫秒。这不是库写得不好，而是 bcrypt 这类算法天生就是故意设计成计算慢的，为了对抗 GPU 暴力破解。可慢的同时还占用主线程，这在服务端并发场景里就成了双倍麻烦。

换用 C++ 编写的原生模块（比如老牌的 bcrypt 模块）能缓解一部分问题，因为它通过 libuv 线程池异步执行，不会阻塞主线程。但 node-rs 的思路更进一步：把 Argon2、Bcrypt、JWT 这些核心实现直接用 Rust 编写，再通过 N-API 暴露给 JavaScript 调用。Rust 在内存安全和计算性能上都有天然优势，生成的动态库体积也不大，而且由于底层走的是 N-API，没有中间层拷贝，调用开销很小。测试下来，同一套哈希操作，node-rs 里的 argon2 模块比我之前用的纯 JS 版本快了几倍不止，最关键的是主线程事件循环完全不卡了。

1.2 node-rs 模块家族与适用场景

node-rs 其实是一个模块集合，比较常用的核心模块包括：

• Argon2：基于 Argon2 算法的口令哈希实现，支持 Argon2i、Argon2d、Argon2id 三种变体。
• Bcrypt：经典的老牌口令哈希实现，兼容市面上大多 bcrypt 哈希串。
• JSON Web Token (JWT)：JWT 的生成、签名、验证，支持 HS 系列和 RS 系列算法。

这三个模块恰好覆盖了一个认证系统的关键链路：用户注册时用 Argon2 或 Bcrypt 哈希口令存库；登录时校验口令；校验通过后用 JWT 签发令牌；后续请求通过验证 JWT 识别用户身份。把这个链路整条换到 node-rs 上，收益不是单点性能提升，而是整条链路的高并发能力都上了一个台阶。

不过要泼一盆冷水，node-rs 并不是万金油。如果你只是写个脚本工具，不追求高并发，那用纯 JS 库完全没问题。node-rs 的适用场景应该是生产环境的服务端应用，特别是压测表现敏感、部署在容器里追求 CPU 效率的项目。换了 node-rs 之后，我观察到相同压力下 CPU 使用率明显下降，服务能承载的并发请求数也有可观提升。

2. 口令哈希核心模块：Argon2 与 Bcrypt 实战

2.1 两种算法的设计差异与选型逻辑

先捋清楚 Argon2 和 Bcrypt 到底有什么区别，否则你会不知道为什么要有两种哈希算法。Bcrypt 诞生于 1999 年，基于 Blowfish 密码算法的密钥调度机制，自带盐值，抗 GPU 攻击能力在当时很出色。它的缺点是内存使用率不高，攻击者可以用专门硬件并行跑很多次，而且工作因子（cost）只能线性增加计算次数，提升强度的代价比较大。

Argon2 是 2015 年 Password Hashing Competition 的冠军，设计目标就是同时抗 GPU 和 ASIC 攻击。它的核心武器是"内存硬"特性，计算过程中需要占用大量内存，导致并行破解单元的成本急剧上升。Argon2 有三个变体：Argon2d 抗 GPU 但容易受到侧信道攻击，Argon2i 抗侧信道但内存访问模式可以优化，Argon2id 则是前两者的结合，先跑一段 Argon2i 再切 Argon2d，综合安全性最高。实际生产环境里，绝大多数场景选 Argon2id 就对了。

我在选型时的判断标准很简单：新项目直接上 Argon2id，老系统需要兼容已有哈希串的用 Bcrypt。因为 Bcrypt 哈希串在老系统存量很多，迁移成本高；而 Argon2 在 OWASP 的口令存储建议里已经是排在首位的推荐算法了。node-rs 把这两个模块都做了，正好给了我们平滑过渡的余地。

2.2 node-rs 中 Argon2 的完整用法

先安装依赖：

npm install @node-rs/argon2

安装过程会自动下载或编译 prebuilt 动态库，一般不需要手动装 Rust 工具链。如果出现编译失败，需要确保系统有较新的 glibc 版本，或者安装 Rust 工具链后从源码编译。

核心 API 就两个，哈希和验证：

import { argon2idHash, argon2idVerify } from '@node-rs/argon2' // 哈希 const hash = await argon2idHash('your-password', { memoryCost: 65536, // 64 MiB timeCost: 3, // 3 次迭代 parallelism: 1, // 1 个并行线程 }) console.log(hash) // $argon2id$v=19$m=65536,t=3,p=1$c29tZXNhbHQ$... // 验证 const correct = await argon2idVerify('your-password', hash) const wrong = await argon2idVerify('wrong-password', hash)

这里有几个参数需要注意。memoryCost的单位不是字节也不是 MiB，而是 KiB。所以 65536 实际上代表 64 MiB。timeCost是迭代次数，越大计算越慢。parallelism是并行度，在 node-rs 的实现中，并行度会直接影响内部使用多少线程计算。一次性不要调太高，否则小虚拟机上的内存压力会很大。

安全参数怎么定？我结合 OWASP 建议和实际硬件情况，比较稳妥的起点是m=65536, t=3, p=1。如果你的服务跑在低配的 1GB 内存机器上，可以降到m=32768, t=2, p=1。如果跑在 8GB 内存以上的高配机器，经费充足，可以用m=19456, t=2, p=1或者m=65536, t=3, p=1。当年 Argon2 的 RFC 给了一组参考值，但那是针对交互式登录场景的，现在的硬件普遍能跑更高参数。我自己在生产用的是m=65536, t=3, p=1，登录接口的平均耗时在 10ms 量级，完全能接受。

这里有个关键点：argon2idHash返回的哈希串本身就是自描述的，包含了算法版本、参数、盐值、哈希值，不需要你额外存盐。你只需要一个字段存整条字符串，验证时把参数全部解析出来，再对输入口令重新计算比对。这也是 Argon2 设计得好的地方。

2.3 node-rs 中 Bcrypt 的完整用法

如果你的系统里已经有一批 bcrypt 哈希串，node-rs 的 bcrypt 模块就是无缝替换的不二之选：

npm install @node-rs/bcrypt

实现同样简洁：

import { hash, verify } from '@node-rs/bcrypt' const hashed = await hash('your-password', 10) console.log(hashed) // $2b$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy const ok = await verify('your-password', hashed)

10的工作因子（cost）意味着算法会执行 2^10 = 1024 次迭代。它生成的哈希串前缀$2b$代表修正过的 bcrypt 版本，兼容性很好。老哈希串$2a$也能被verify正确识别。

关于 cost 选多少，我见过的项目里从 8 到 12 都有。8 是底线，10 是常用值，12 在性能好的机器上也没问题。调 high 到 12 之后，单次验证会到几十毫秒，异步执行的话影响并不大；但如果你把 cost 调到 14 甚至更高，即使在线程池里跑，线程池资源也会吃紧，造成其他异步任务排队。这点留意。

有个容易忽略的坑：bcrypt 算法对密码长度有限制，超过 72 字节的部分会被截断。虽然 node-rs 里hash函数的输入会做 UTF-8 编码，但超过 72 字节时最好还是先做一次 SHA-256 预哈希，再把预哈希的结果传入 bcrypt。否则两个长密码如果后 72 字节相同，验证就会出问题。Argon2 没有这个限制，这也是我推荐新项目直接上 Argon2 的理由之一。

2.4 两套模块的哈希串格式解析与迁移思路

在实际项目里，存量用户数据迁移是很现实的问题。老系统用的 bcrypt 哈希，新系统想切 Argon2，怎么办？我见过一种比较粗糙的做法：让所有老用户在首次登录时先验证 bcrypt，验证通过后立即用 Argon2 重新哈希，再更新数据库。这样实现了无缝迁移，不需要重置密码。

但要注意，这个过程必须配合登录接口的改写逻辑。验证 bcrypt 通过后，先跑一次 argon2idHash 生成新哈希，然后 UPDATE 用户表。这个更新流程最好做成异步任务，不要阻塞 HTTP 响应太久。另外，如果老系统中存在<72 字节密码用 bcrypt 哈希、而新系统要完整验证长密码的情况，需要先把长密码做 SHA-256 再验证，或者干脆告诉这类用户重置密码。

node-rs 的 Argon2 哈希串格式大致是：

$argon2id$v=19$m=65536,t=3,p=1$<base64-salt>$<base64-hash>

验证时是通过解析这个字符串得到盐值和参数。bcrypt 的格式则是：

$2b$10$<22字符盐+31字符哈希>（bin2hex base64）

所以你可以根据哈希串的前缀判断走哪个验证器。这就为迁移期写兼容逻辑提供了基础。

3. JSON Web Token 签名模块实战

3.1 JWT 的结构与签名流程简明梳理

JWT 说白了就是一个自包含的令牌，结构是三段式：Header.Payload.Signature。Header 里声明算法和类型，Payload 里放声明（claim），Signature 是对前两段的签名。

一段 JWT 示例：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsIm5hbWUiOiJhZG1pbiIsImlhdCI6MTcxMDAwMDAwMCwiZXhwIjoxNzEwMDM2MDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

这里 Header 是{"alg":"HS256","typ":"JWT"}的 base64url 编码，Payload 是若干声明（iss、sub、iat、exp 等）的 base64url 编码，Signature 是按 Header 里声明的算法对header.payload签名后的 base64url 编码。

签名算法分两类：对称签名（HS256）和非对称签名（RS256 / ES256 等）。HS256 用一个共享密钥同时做签名和验证，简单高效，但密钥必须保密，通常在单服务或微服务内部共用的场景用。RS256 用私钥签名、公钥验证，适合跨服务或第三方需要验签的场景，因为你可以把公钥扔给对方，私钥只留在自己手里。

node-rs 的 jsonwebtoken 模块同时支持 HS 和 RS 系列。它和社区常用的jsonwebtokennpm 包 API 非常接近，迁移成本极低。我们来看实战。

3.2 node-rs 中 JWT 的生成与验证

安装依赖：

npm install @node-rs/jsonwebtoken

这个包不仅包含生成和验证逻辑，API 设计也照着主流库做了对齐，所以老的jsonwebtoken代码几乎只是换导入路径即可。

生成令牌：

import { sign, verify } from '@node-rs/jsonwebtoken' const token = sign( { sub: 'user_123', email: 'a@example.com', role: 'admin', }, 'your-secret-key', { algorithm: 'HS256', expiresIn: '1h', issuer: 'my-api', } )

验证令牌：

try { const payload = verify(token, 'your-secret-key', { algorithms: ['HS256'], issuer: 'my-api', }) console.log(payload.sub) // user_123 } catch (err) { // 验证失败或过期 }

expiresIn可以传数字（秒）或字符串（比如'2h'、'7d'）。在使用sign时，如果你给 payload 里手动塞了exp字段，就没必要用expiresIn，两者同时存在时会以expiresIn覆盖。我的经验是统一用expiresIn参数，代码更直观，也避免自己算时间戳出错。

关于密钥，HS256 的密钥强度至关重要。很多项目直接写死一个短字符串，比如'secret'，这等于把令牌伪造的大门敞开。正确做法是使用 32 字节以上的随机密钥，环境变量注入，或者用密钥管理服务动态拉取。我在项目里用 HMAC 密钥时，一般用crypto.randomBytes(32).toString('base64')生成，放到.env里。这样即便源码泄漏，密钥也不会暴露。

3.3 与老 jsonwebtoken 库的替换注意点

node-rs 的 jsonwebtoken 模块虽然 API 对齐，但有几个区别需要注意。

第一个是错误消息文本可能不完全一致。老库验证过期令牌时抛的错误俗称 "jwt expired"，而 node-rs 可能返回不同文案或者错误编码不同。如果前端依赖错误文案做判断，那就别依赖，统一用 HTTP 状态码就好。第二个是对算法枚举的处理更严格。在options.algorithms里必须明确指定允许的算法，否则默认策略可能和你的预期不一致。老库默认是 HS256，而 node-rs 如果没指定则可能允许更多算法。为了防止算法降级攻击，建议每次verify都显式传algorithms数组。

第三个区别是性能差异。node-rs 在底层用 Rust 实现了 HMAC 签名和验签，在大量并发验证令牌时的主线程占用远低于纯 JS 实现。我在一个网关上做过实测，把 JWT 验证全部切到 node-rs 后，网关整体的 P99 延迟下降明显，而且 CPU 开销肉眼可感地低了。对需要频繁验签的边缘服务，这个替换性价比很高。

还有一点，node-rs 的 jsonwebtoken 模块对 RS256 的支持同样完善。你只需要准备好私钥 PEM 和公钥 PEM，生成时传privateKey，验证时传publicKey，其它基本差不多。

4. 完整认证闭环：从注册、登录到鉴权中间件

4.1 用 Express 搭建注册、登录、刷新三个接口

把 Argon2 和 JWT 串起来，才能构成一个真正能用的认证系统。我用 Express 做例子，但换成 Fastify 也没区别，逻辑是一致的。项目结构大概长这样：

src/ middlewares/auth.ts routes/auth.ts utils/password.ts utils/token.ts

注册接口：

import { argon2idHash } from '@node-rs/argon2' import { sign } from '@node-rs/jsonwebtoken' import { Router } from 'express' const router = Router() router.post('/register', async (req, res) => { const { username, password } = req.body // 校验参数，查重，省略 const hash = await argon2idHash(password, { memoryCost: 65536, timeCost: 3, parallelism: 1, }) const user = await db.create({ username, passwordHash: hash }) const accessToken = sign({ sub: user.id, role: user.role }, JWT_SECRET, { algorithm: 'HS256', expiresIn: '15m', }) const refreshToken = sign({ sub: user.id, tokenType: 'refresh' }, REFRESH_SECRET, { algorithm: 'HS256', expiresIn: '7d', }) res.status(201).json({ accessToken, refreshToken }) })

登录接口：

router.post('/login', async (req, res) => { const { username, password } = req.body const user = await db.findByUsername(username) if (!user) return res.status(401).json({ code: 'INVALID_CREDENTIALS' }) const valid = await argon2idVerify(password, user.passwordHash) if (!valid) return res.status(401).json({ code: 'INVALID_CREDENTIALS' }) // 签发令牌 const accessToken = sign({ sub: user.id, role: user.role }, JWT_SECRET, { algorithm: 'HS256', expiresIn: '15m', }) const refreshToken = sign({ sub: user.id, tokenType: 'refresh' }, REFRESH_SECRET, { algorithm: 'HS256', expiresIn: '7d', }) res.json({ accessToken, refreshToken }) })

刷新令牌接口就更简单了，验证 refresh token，然后签一个新的 access token：

router.post('/refresh', async (req, res) => { const { refreshToken } = req.body try { const payload = verify(refreshToken, REFRESH_SECRET, { algorithms: ['HS256'] }) if (payload.tokenType !== 'refresh') throw new Error('invalid token type') const user = await db.findById(payload.sub) const accessToken = sign({ sub: user.id, role: user.role }, JWT_SECRET, { algorithm: 'HS256', expiresIn: '15m', }) res.json({ accessToken }) } catch { res.status(401).json({ code: 'INVALID_REFRESH_TOKEN' }) } })

这里我把 access token 和 refresh token 用不同的密钥和不同声明区分开，是个好习惯。因为 refresh token 的失效周期长，万一被泄漏，影响范围比短期 access token 大得多。区分密钥后，你可以单独轮换 refresh 密钥而不影响仍在生效的 access token。

4.2 鉴权中间件：从 Authorization 头解析并校验令牌

有了令牌，接下来写中间件：

import { verify } from '@node-rs/jsonwebtoken' import type { Request, Response, NextFunction } from 'express' export function authRequired(req: Request, res: Response, next: NextFunction) { const header = req.headers.authorization if (!header?.startsWith('Bearer ')) { return res.status(401).json({ code: 'MISSING_TOKEN' }) } const token = header.slice(7) try { const payload = verify(token, JWT_SECRET, { algorithms: ['HS256'] }) req.user = payload // 挂到请求上下文 next() } catch (err) { return res.status(401).json({ code: 'INVALID_TOKEN' }) } }

使用方式是在受保护的路由上挂中间件：

router.get('/profile', authRequired, async (req, res) => { const user = await db.findById(req.user.sub) res.json(user) })

这里有几个实战细节。第一，过期 token 会抛 "TokenExpiredError"，如果你想要更细粒度地区分过期和伪造，可以分别捕获，然后返回不同的错误提示。第二，JWT 的 payload 是明文 base64url，千万不要把敏感信息塞进去，任何拿到 token 的人都能解码看到内容。第三，中间件里为了性能，verify 出的 payload 每次都要重新解析声明，如果 token 太多，网关可以挂一层短时间缓存，但要注意过期时间的一致性。

4.3 简单场景与复杂场景的取舍

这套闭环其实已经能满足大多数单体应用。但如果你是微服务，或者第三方需要验证你签发的 token，那就要认真琢磨算法选择了。HS256 的共享密钥在多个服务之间分发，泄漏面会变大；RS256 私钥签名、公钥验证，可以让任何服务只持有公钥就能验签。node-rs 的 jsonwebtoken 模块对 RS256 支持得不错，我建议跨服务场景优先 RS256。

另外，刷新令牌本身也有状态管理问题。如果用户被禁用了，旧 refresh token 还能不能续签？这取决于你的令牌是否是"有状态"的。纯 JWT 是无状态的，服务端无法单独吊销它。所以在生产里，我更推荐把 refresh token 的哈希也存进数据库，续签时检查是否被吊销。access token 保持无状态，15 分钟短生命周期，过期就重新续。

如果要更轻省，可以使用一个简单的"令牌版本号"机制：用户表中存一个tokenVersion，JWT payload 里带上它，每次验证时对比版本号。密码改过、账号被冻结、或者主动踢人下线，就递增版本号，旧 token 全部失效。这个方案不需要额外的 Redis，也能实现粗糙但有效的吊销能力。Redis 存储黑名单是另一种做法，适合追求精细控制的团队，但必要性和成本要自己权衡。

5. 常见问题与避坑指南

5.1 密码学参数到底怎么调

参数调优是很多人纠结的点。给一个可以从生产起步的参考表：

注意这些参数不是越高越好。Argon2 的 memoryCost 每翻一倍，内存占用翻一倍，在容器内存受限的时候容易直接 OOM。Bcrypt 的 cost 每加 1，计算时间翻倍，线程池被占满后其他数据库异步操作也会跟着排队。

你的参照系应该是"登录毛刺不可太明显"。我习惯压测时观察 P99 延迟，如果 P99 超过 300ms，就需要降一档参数，或者扩线程池。还有一点，别忘了一个用户登录失败也是在算哈希，攻击者可以疯狂尝试错误密码来消耗你的 CPU。生产系统必须叠加验证码、限流、账户锁定三重防护，密码哈希参数只是防御链条的最内层。

5.2 安装与运行时的环境陷阱

node-rs 的 prebuilt 动态库对宿主环境有要求。Linux 环境比较常见的问题是 glibc 版本过低。比如 CentOS 7 自带的 glibc 2.17，跑有些新版 node-rs 包会出现 "libstdc++.so.6: version `GLIBCXX_3.4.20' not found" 之类的报错。解决方案有两个：要么升级操作系统，要么用容器镜像把运行时固定到一个较新的 Debian 或 Ubuntu 版本。我的推荐是服务端统一使用一个维护中的 Linux 镜像，比如 Debian 12、Ubuntu 22.04 以上，不要用老旧的发行版硬扛。

Node 版本也有影响。node-rs 依赖 N-API，一般需要 Node 16 以上的 LTS 版本。装包失败时先看 node --version 和 npm --version，然后npm install时看是否有预编译二进制匹配。如果是从源码编译，还需要 Rust 工具链。总体上，只要环境够新，安装过程是一路绿灯的。

另外，Argon2 的parallelism参数在实际计算时会不会真的起多线程，取决于运行时配置。node-rs 的实现里，parallelism主要影响内部的内存布局和计算方式，不一定会创建多个 OS 线程。所以不要指望通过调 p=4 来加速，提升有限，反而可能在低内存机器上多吃内存。

5.3 JWT 密钥泄漏与算法绕过

JWT 相关的事故，绝大多数不是算法被破解，而是密钥泄漏。HS256 用同一个密钥签名和验签，如果你是前后端分离的 SPA，密钥只能存在服务端，绝不能出现在前端 bundle 里。有的团队图省事，把 secret 写在配置文件里，提交到 git，这等于直接送了攻击者一把万能钥匙。

另一个常见陷阱是算法混淆攻击。攻击者把 token 的 alg 从 HS256 改成 none，或者改成 HS256 并尝试用公钥做 HMAC 密钥，如果服务端没限制 algorithms，就可能伪造令牌。所以我在前面反复强调，verify的时候一定要显式传入algorithms: ['HS256']或['RS256']，不要信任 token 自己声明的算法。

RS256 的公钥泄漏不是坏事，它本来就是公开的。但要防止有人把 HS256 的 token 拿过来，用公钥作为 HMAC 密钥。这就是为什么要做算法白名单校验。这类问题在 node-rs 里虽然不会主动出现，但我们自己写的代码要养成这个习惯。

5.4 性能实测与调优记录

最后给出一组我在相似环境下做过的实测对比，仅供参考。我用的是一个两核四线程、4GB 内存的云服务器，压测 200 并发：

这里的关键不只是单次操作变快，而是主线程不再被密码学计算拖住。纯 JS 实现时，压测中事件循环延迟明显拉高，其他普通接口跟着遭殃；切换到 node-rs 后，事件循环延迟恢复平稳，整体吞吐上了一个台阶。

如果还想进一步优化，可以考虑给线程池加容量。Node.js 的UV_THREADPOOL_SIZE默认是 4，如果你把大量密码哈希和 JWT 验签都交给 libuv 线程池，那四个线程可能不够用。可以把环境变量UV_THREADPOOL_SIZE=8加到启动脚本里，压测时观察线程利用率，不够再加。但这个设置对整个进程的线程池都生效，数据库连接池的异步操作、文件系统操作也都在用，所以别盲目调太高，建议从 8 开始试，观察 CPU 饱和度和延迟曲线。

我在实际使用中还有一个体会：注册和登录接口很少是性能瓶颈持久战，真正吃性能的是网关层对每个请求的 JWT 验证。在网关层把 node-rs 的 jsonwebtoken 用起来，效果会比在业务层明显得多。每毫秒省下来，乘以上亿次的调用，就是巨大差距。

写在最后的实操体会

折腾 node-rs 这套模块到今天，我觉得最值得强调的一点是：安全性和性能不是非此即彼的选择。Argon2 之所以慢慢成为推荐位第一的口令哈希算法，是因为它设计之初就把攻击者硬件成本纳入考量，而 node-rs 让它在 Node.js 生态里变得真正可用——不至于因为我们担心压测不过关就退而求其次选弱参数。

如果你正要给现有系统做一次认证模块的体检，我的建议是先做三件事。第一，把口令哈希从纯 JS 算法切的更优实现上，同时重新评估 Argon2id 的参数组合是否还停留在三五年前的水平；第二，给 JWT 验证加上算法白名单、短过期时间和 refresh token 吊销机制；第三，压测时别只看平均延迟，多关注 P99 和事件循环阻塞时间。

最后分享一个小技巧，node-rs 的包名和 API 设计都比较规整，切换时可以逐步替换，不必一个晚上全量上线。先换 Argon2 和 JWT 验签，观察几天日志和监控，再动 Bcrypt 的老哈希兼容逻辑。这样一旦出现问题，回滚也容易。安全系统的改造，稳比快重要得多。