HTML无法实现真正笔记加密，因纯前端标签无加密能力；需Web Crypto API配合用户密码派生密钥加密数据，服务端同步解密，缺一环即失效。
HTML 本身不提供“笔记加密”或“锁定此笔记”功能——这是前端界面元素，背后必须依赖 JavaScript 加密逻辑和后端密钥管理，纯 HTML 标签无法实现真实加密。
为什么 <button> 或 <input type="checkbox"> 不能真正锁定笔记
用户点击“锁定此笔记”按钮时，如果只改了按钮文字、加了个锁图标、或把 contenteditable 设为 false，那只是视觉/交互封锁，内容仍可被开发者工具直接读取、复制、甚至通过 innerHTML 提取。真正的加密必须发生在数据层面：输入时用密钥加密文本，存储/传输时保持密文，解锁时用密钥解密。
常见错误现象：
- 按钮点击后仅切换
disabled属性，但 DOM 中明文依然可见 - 用
localStorage存储“已锁定”状态，却把笔记原文以明文存进去 - 声称“AES 加密”，但密钥硬编码在 JS 文件里（等于没密）
如何用 Web Crypto API 实现前端轻量加密入口
现代浏览器支持的 Web Crypto API 是唯一可信赖的客户端加密方案（无需引入第三方库）。它能生成密钥、加密文本、导出密文——但注意：密钥不能存前端，必须由用户输入密码派生（如用 deriveKey + PBKDF2）。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- “锁定”按钮触发前，弹出密码输入框，不接受空密码
- 用
crypto.subtle.importKey()和crypto.subtle.encrypt()对笔记textContent加密，输出 Base64 密文 - 把密文写入
data-encrypted属性或隐藏<textarea>，同时清空可见区域 - 解锁时用同一密码重新派生密钥，调用
decrypt()还原文本 - 避免使用
localStorage存密文+密码组合——攻击者可截获解密流程
form 提交时绕过加密字段的典型陷阱
如果笔记表单含加密字段（比如 <input name="note" data-encrypted="true">），而提交逻辑直接序列化所有 name 值，就会把密文当明文发出去——后端若没对应解密步骤，数据就永远不可读。
关键点：
- 提交前检查
data-encrypted属性，对加密字段跳过默认序列化 - 手动拼装 FormData：
formData.append("note_encrypted", encryptedBase64)+formData.append("note_nonce", nonceHex) - 服务端必须用相同算法（AES-GCM）、相同密钥派生方式、相同 nonce 解密，否则解密失败报
OperationError: The operation failed for an operation-specific reason - 不要在 URL 参数里传密文（长度超限、易被日志记录）
移动端 Safari 和旧版 Chrome 的兼容性断点
Web Crypto API 在 iOS 16.4+ 和 Android Chrome 109+ 才完整支持 AES-GCM；更早版本可能只支持 AES-CBC（需自行填充、无认证，安全性降级）。
判断与降级建议：
- 用
if (window.crypto?.subtle?.encrypt)做基础检测 - 对不支持 GCM 的环境，提示“当前浏览器不支持安全锁定，请升级或换用 Chrome/Firefox”而非静默回退
- 避免用
require('crypto')（Node.js）或msCrypto（IE 遗留），它们不跨平台 - 测试时务必真机连 Safari 开发者工具，模拟器常忽略权限限制
加密不是加个锁图标，也不是阻止右键复制——它是一整条链：用户密码 → 密钥派生 → 文本加密 → 安全传输 → 服务端验证与解密。任何一环松动，入口按钮就只是个安慰剂。
