前端不该用 bcrypt 做密码加密，因其明文密码易被调试器读取、salt 无法安全保管、JS 实现性能差且可被篡改；应仅用 WebCrypto 做 SHA-256 摘要防传输嗅探，并严格 HTTPS + 后端 bcrypt 处理。
前端不该用 bcrypt 做密码加密。这不是“怎么做”的问题，而是“不该做”的原则性问题——所有在浏览器里执行的密码哈希，都绕不开明文密码短暂暴露、盐值无法安全保管、攻击者可任意调试篡改等根本缺陷。
为什么不能在前端用 bcrypt
bcrypt 的设计前提就是服务端可控环境：稳定 CPU 资源、隔离的执行上下文、可安全生成并保管 salt。而前端：
- 用户输入的密码在调用
bcrypt.hash()前已是 JavaScript 字符串，可被console.log、调试器、内存快照直接读取 - 前端无法安全生成或隐藏
salt——任何硬编码或客户端生成的 salt 都等于没加 - 攻击者可轻松替换你引入的
bcrypt.js，返回固定哈希值或直接透传明文 - WebCrypto API 不支持 bcrypt（无原生
SubtleCrypto.digest()对应算法），所有 JS 实现都是纯计算模拟，性能差且易被逆向
前端该做什么：只做基础防护 + 安全传输
真正该在前端做的，是减少明文在网络中裸奔的时间和范围：
- 用
type="password"输入框 +autocomplete="new-password"减少浏览器自动填充风险 - 提交前用
WebCrypto.subtle.digest('SHA-256', ...)做一次快速摘要（仅防传输层明文嗅探，不是密码哈希） - 必须走 HTTPS，禁用 HTTP 表单提交
- 配合后端实现
CSRF token和短时效一次性表单签名，防止重放
const encoder = new TextEncoder();
const data = encoder.encode(document.getElementById('password').value);
const hashBuffer = await crypto.subtle.digest('SHA-256', data);
const hashArray = Array.from(new Uint8Array(hashBuffer));
const hashHex = hashArray.map(b => b.toString(16).padStart(2, '0')).join('');
// 注意：这只是防中间人看到原始密码，后端仍需用 bcrypt/scrypt/PBKDF2 重新哈希
如果非要跑 bcrypt（比如本地 CLI 工具或 Electron）
仅限完全脱离浏览器 DOM 环境的场景，例如 Node.js 后端、Electron 主进程、或 Deno 脚本。此时可用标准库：
立即学习“Java免费学习笔记（深入）”；
- Node.js：推荐
bcrypt（C++ binding，快）或bcryptjs（纯 JS，慢但跨平台） - Deno：用官方
https://deno.land/std@0.224.0/crypto/bcrypt.ts - Electron 渲染进程？不行——它仍是浏览器环境，同上所述风险全部存在
// Node.js 示例（仅服务端/CLI 场景） import bcrypt from 'bcrypt'; const saltRounds = 12; const plainPassword = 'user_input'; const hash = await bcrypt.hash(plainPassword, saltRounds); // 后端存储 hash，登录时用 bcrypt.compare(plain, hash) 验证
真正容易被忽略的点是：很多人把「前端加了一层 hash」误认为增强了安全性，实际上它既不替代服务端哈希，又给攻击者多送了一个可分析的中间态。密码哈希必须发生在可信、隔离、可控的后端环境中，前端唯一职责是安全地把原始密码交过去——不多也不少。
