登录实测约 232ms,其中 bcrypt 约 72ms、网络往返约 80ms 是不可省的计算/物理成本, 剩下的都是我们自己的开销。这次把能省的两处省掉(实测约 40ms,占登录耗时约 19%): 1. 去掉「数据库连接检查」的冗余预检 原来每次登录先 await db.select().from(users).limit(1) 只为"测连接", 紧接着又会真的查用户,连不上一样会报错 —— 纯粹多一次数据库往返。 现在把那次真实查询包进 try,只有它失败才回报 503「数据库服务暂时不可用」, 错误码与文案完全不变。 2. 缓存「这个账号有没有开 2FA」 登录每次都查 userIdentities 找 TOTP,但绝大多数账号根本没开 2FA。 新增 server/utils/totp-cache.ts: · 查到**没有** TOTP → 缓存 10 分钟,后续登录直接跳过查询 · 查到**有** TOTP → **不缓存**(安全优先:绝不能因为缓存而让刚开 2FA 的人被跳过验证) 开启/关闭 2FA 的接口必须调用 invalidateTotpCache(userId),已在 server/api/user/2fa/{enable,disable}.post.ts 接上 —— 否则会有最长 10 分钟的验证空窗。 该缓存不参与密码校验,最坏情况只是多查一次库。 3. lastLogin / lastLoginIp 的 UPDATE 不再阻塞响应 登录时间与登录 IP 是审计信息,晚写几十毫秒、甚至这次写失败, 都不影响用户能否登录。改为不 await(保留 .catch,避免 unhandledRejection)。 4. 安全修复:微信登录不再把 session_key 打进日志 server/api/auth/wechat/login.post.ts 原来打印整个 jscode2session 响应前 500 字, 而该响应含 { session_key, openid, unionid }。 session_key 是敏感凭据(可解密用户数据、配合其他接口换取手机号), 长期落在服务端日志里等于凭据落盘。 现在只打印:顶层键名、errcode/errmsg、以及 openid/session_key/unionid 的 存在性与长度(不打印值);仅在"响应根本不是对象"时才打印截断原文 (那种情况它不可能是合法凭据,且是排查被代理拦成 HTML 的唯一线索)。 已验证: - 缓存逻辑用假 db 真跑过 5 个场景(命中缓存省下查询、失效后立刻重查、 有 2FA 不缓存、多用户互不干扰、只失效指定用户) - 4 个改动文件的相对 import 路径均存在;totp-cache 的导出与两处 import 对得上 - login.post.ts 抽走 TOTP 查询后已清理不再使用的 userIdentities / and 导入 - 文件编码 UTF-8 无 BOM、无乱码、括号平衡
站长要求全站一致(小程序端已单独提交)。本次只改**用户可见文案与默认值**: - 服务端默认值/兜底:system-settings-defaults、admin/system-settings(GET/POST)、 site-config.get、utils/siteUtils —— 原来是 'VoiceHub' / '校园广播站点歌系统' - 用户可见通知文案:MeoW 绑定验证码与标题、MeoW 测试通知、微信订阅测试通知 - 2FA 应用名(authenticator.keyuri)、WebAuthn rpName(出现在系统密钥弹窗里) - 网页版界面:首页副标题、后台侧栏品牌名、登录/注册/找回/改密标题与文案、 年度回顾(IntroSlide / ShareCard / 页面标题)、用户教程、通知发送预览、 API 密钥与数据库导入说明、酷狗 sidecar 说明、打印页脚与歌单卡片页脚、Logo alt **刻意不动**:localStorage/sessionStorage 的 `voicehub_*` 键、`voicehub:` 前缀的 STORAGE_KEY 与缓存/Redis 前缀、`window.voiceHubPlayer` 之类代码标识、MeoW 的 User-Agent、以及上游项目链接 `github.com/laoshuikaixue/VoiceHub`(那是对原项目的署名)。 注意:站点名**数据**(systemSettings.siteTitle)仍是你后台里设置的「宝一外校园点歌」, 代码只保证默认值与文案一致;要让全站显示完整名称,请在后台「站点配置 → 站点标题」 改成「宝一外校园点歌系统」。