密码不可跨域明文传递，须用Web Crypto API的PBKDF2在前端加盐派生密钥（iterations≥100000、SHA-256、后端下发盐），导出十六进制凭证供后端校验，全程内存操作并立即清空原始密码。
密码不能跨域明文传递，这是浏览器安全模型的硬性限制
跨域场景下直接用 fetch 或 XMLHttpRequest 向不同源的后端发原始密码，等同于把密码暴露在请求头、URL 参数或请求体中——中间网络节点、代理、CDN 都可能截获。更关键的是，现代浏览器会拦截非 https 下的密码提交，且 CORS 预检失败时连请求都发不出去。
真正可行的做法是：前端不“传密码”，而是把密码在本地完成不可逆处理（如加盐哈希），再把处理结果交给后端校验。后端必须有对应算法和存储的哈希值（不是明文密码）。
前端用 Web Crypto API 做 PBKDF2 密码派生（推荐）
比 SHA-256 等简单哈希更安全，它自带迭代和盐值，能抵抗彩虹表和暴力破解。注意：不能用 crypto.subtle.digest() 直接哈希密码，那没有抗碰撞性保障。
-
crypto.subtle.importKey()导入密码为原始密钥（raw格式，extractable: false） -
crypto.subtle.deriveKey()调用PBKDF2，指定iterations≥ 100000、hash: "SHA-256"、盐值建议用后端下发的 16 字节随机数（避免前端硬编码） - 导出结果用
crypto.subtle.exportKey("hex", derivedKey)得到十六进制字符串，作为“凭证”发送
示例关键片段：
立即学习“前端免费学习笔记（深入）”；
const encoder = new TextEncoder(); const salt = new Uint8Array([/* 后端给的 salt */]); const keyMaterial = await crypto.subtle.importKey( "raw", encoder.encode(password), { name: "PBKDF2" }, false, ["deriveKey"] ); const derivedKey = await crypto.subtle.deriveKey( { name: "PBKDF2", salt, iterations: 100000, hash: "SHA-256" }, keyMaterial, { name: "AES-GCM", length: 256 }, false, ["encrypt"] ); const hex = Array.from(new Uint8Array(await crypto.subtle.exportKey("raw", derivedKey))) .map(b => b.toString(16).padStart(2, "0")) .join("");后端必须同步实现相同 PBKDF2 参数校验
前端算出的哈希值对不上，99% 是后端参数不一致。重点核对：
- 盐值是否完全一致（字节级，不是 base64 编码后再比对）
-
iterations数值是否与前端完全相同（比如前端写 100000，后端写 1e5 就会出错） - 哈希算法名是否严格为
"SHA-256"（Node.js 的pbkdf2默认可能是sha1） - 输出长度是否匹配（例如前端导出 32 字节 AES 密钥，后端却按 64 字节解析）
Node.js 示例（使用 crypto.pbkdf2Sync）：
const key = crypto.pbkdf2Sync( password, saltBuffer, // 必须是 Buffer，不是字符串 100000, 32, // 长度要和前端 deriveKey 的 length 一致 "sha256" );绝对不要用 localStorage / URL / GET 参数传密码或其哈希
哪怕加了哈希，存到 localStorage 也会被 xss 直接读取；拼在 URL 里会被服务器日志、浏览器历史、Referer 泄露；用 GET 发送等于公开广播。
正确姿势只有一条：密码输入后立即在内存中计算派生密钥，得到结果后立刻清空原始密码变量（password = ""），且整个过程不落盘、不记录、不缓存。如果页面存在未修复的 XSS 漏洞，任何前端加密都形同虚设——这时候该修的是 XSS，不是换加密算法。