HTML无法实现真正加密下载，所谓“加密链接”只是前端伪安全；必须由服务端生成带签名、时效和权限校验的临时URL，并在后端验证后返回文件。
HTML 本身不能创建“备用密钥”或对文件做加密，它只是静态标记语言；所谓“加密下载链接”实际是前端不可靠的障眼法，真要防下载得靠服务端控制。
为什么 <a href="xxx.enc"></a> 不等于“加密下载”
浏览器点击链接后，会直接向服务器发起 GET 请求，拿到什么内容就下载什么内容。哪怕你把文件后缀改成 .enc、.locked 或用 Base64 编码路径，只要 URL 可被构造，文件就能被直取。
常见错误现象：
– 用户右键“另存为”，照样拿到文件
– 抓包工具（如 DevTools 的 Network 面板）里一眼看到原始请求 URL
– 把链接发给别人，对方无需任何密钥也能下载
根本原因：HTML 没有执行密钥解密的能力，也不参与加解密流程；所有“前端加密”都是伪安全。
立即学习“前端免费学习笔记（深入）”；
真正可控的下载方式：服务端动态签发临时链接
想实现“带密钥/时效/权限”的下载，必须由后端生成一次性的、带签名的 URL，例如：/download?file=report.pdf&sig=abc123&exp=1718923200。浏览器只负责发起请求，验证和放行全在服务端。
实操建议：
- 用服务端语言（如 Node.js 的
crypto.sign、Python 的hmac、PHP 的hash_hmac）对文件名 + 过期时间生成签名 - URL 中不传原始路径，只传逻辑标识（如
id=234），后端查数据库映射真实路径 - 响应时设置
Content-Disposition: attachment; filename="xxx.pdf"，强制下载而非预览 - 别把密钥硬编码在前端 JS 里——那和写在 HTML 里没区别
如果非要前端“伪装”一下：只做轻量混淆，别信“加密”
某些场景下只需要防止随手点开、屏蔽爬虫初级扫描，可以做最低限度的混淆，但必须明确：这不防人，只防手滑。
可用做法：
- 用 JS 动态拼接
href，比如把"down/123"拆成"do" + "wn/1" + "23"，避免被静态扫描抓到 - 绑定点击事件，用
fetch()请求后端接口获取真实 URL，再用window.open()或<a download></a>触发下载 - 禁用右键：
oncontextmenu="return false"（仅 UI 层，完全可绕过） - 不要用 Base64 编码 URL 路径——
atob("aHR0cHM6Ly9leGFtcGxlLmNvbS9maWxlLnBkZg==")一解就开
容易被忽略的关键点
很多人卡在“怎么让下载链接带参数又不暴露逻辑”，结果把 key=xxx 直接塞进 URL —— 这等于把密钥贴在快递单上。真正的隔离在于：URL 参数只是令牌（token），不是密钥；验证动作必须发生在服务端，且每次请求都要校验签名、时效、IP、用户身份等维度。
另外，download 属性只对同源 URL 生效；跨域链接即使写了 download="xxx.pdf"，浏览器也会忽略，退化为普通跳转。
