web crypto api是浏览器原生异步加密标准，支持aes-gcm（加密）、rsa-oaep/ecdsa（签名）等算法，需https环境，密钥动态生成、内存持有，严禁明文导出，iv必须唯一，且须服务端协同校验。
Web Crypto API 是浏览器原生支持的加密标准，所有操作都基于 Promise 异步执行，天然适配现代 JavaScript 流程。它不暴露密钥、不依赖第三方库，且强制运行在 HTTPS 或 localhost 安全上下文中，是处理客户端敏感数据（如密码、身份凭证、私有消息）最可靠的方式。
选择合适算法：对称加密 vs 非对称签名
加密和签名目的不同，需分开设计：
- 加密敏感数据（如用户输入的身份证号、银行卡号）：优先用 AES-GCM——对称加密，速度快，支持认证加密（防篡改），但密钥必须安全保管；
- 签名关键操作（如登录请求、交易确认）：用 RSA-OAEP + RSASSA-PKCS1-v1_5 或更优的 ECDSA——非对称机制，私钥本地签名，公钥供服务端验签，解决身份可信与完整性验证问题。
生成并管理密钥：避免硬编码与明文导出
密钥绝不能写死或以字符串形式存在代码中。正确做法是动态生成、内存持有、按需使用：
- AES 密钥生成示例：
const key = await crypto.subtle.generateKey("AES-GCM", true, ["encrypt", "decrypt"]) - RSA 密钥对生成（2048 位起）：
const { publicKey, privateKey } = await crypto.subtle.generateKey({ name: "RSA-OAEP", modulusLength: 2048, publicExponent: new Uint8Array([1, 0, 1]), hash: "SHA-256" }, true, ["encrypt", "decrypt", "sign", "verify"]) - 禁止调用 exportKey("jwk") 后把私钥存 localStorage 或发送到服务器；若需持久化，应结合 PBKDF2 派生密钥 + 用户密码保护，且仅导出公钥或加密后的密钥材料。
执行加密与签名：严格遵循异步链与参数规范
每一步都返回 Promise，不可跳过 await 或忽略错误；参数缺失或复用会导致安全失效：
- AES-GCM 加密必须每次生成唯一 IV（推荐 12 字节）：
const iv = crypto.getRandomValues(new Uint8Array(12));
const encrypted = await crypto.subtle.encrypt({ name: "AES-GCM", iv }, key, encoder.encode("data")); - RSA-OAEP 加密只接受公钥，且数据长度受限（≤ 模长 − 2 × 哈希长度 − 2），大文本应先 AES 加密再用 RSA 封装 AES 密钥（混合加密）；
- 签名前必须先哈希原始数据（Web Crypto 自动完成）：
const signature = await crypto.subtle.sign("RSASSA-PKCS1-v1_5", privateKey, encoder.encode("payload"));
验签时用同一算法和公钥：
const isValid = await crypto.subtle.verify("RSASSA-PKCS1-v1_5", publicKey, signature, encoder.encode("payload"));
实际落地注意事项
不是写完 Promise 就算完成，还需关注环境、兼容与流程闭环：
- 确保页面运行在 HTTPS 或 localhost，HTTP 页面会直接抛 SecurityError；
- IE 不支持，Edge 17+、Chrome 37+、Firefox 34+ 可用，必要时加运行时检测：
if (!window.crypto?.subtle) throw new Error("Web Crypto not supported"); - 签名结果和服务端验签逻辑必须完全一致（算法名、哈希方式、编码格式），建议统一用 base64url 编码传输 signature 和 publicKey；
- 前端加密 ≠ 免责盾牌：仍需服务端二次校验、防重放、限流等配合，Web Crypto 解决的是“传输前本地防护”这一环。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
