download属性通过指示浏览器直接下载文件而非打开实现强制下载，使用时需在标签添加download属性，可指定下载文件名。若跨域或服务器未正确配置content-disposition头，则可能失效，此时需服务器端配合设置content-disposition: attachment以确保强制下载。
HTML5的download属性是一个非常方便的小工具，它主要用于指示浏览器，当用户点击一个标签时，不是导航到链接的资源，而是直接将其下载下来。这在很多场景下都非常有用，比如你希望用户下载一份PDF报告而不是在浏览器里直接打开它。它能强制文件下载，但这个“强制”在某些特定情况下，其实是需要服务器端配合的。
解决方案
要使用download属性来强制文件下载，你只需要在你的标签上添加这个属性即可。最基础的用法是这样的：
下载我的文档
当用户点击这个链接时，浏览器会尝试下载your-document.pdf这个文件，而不是在新的标签页中打开它。
立即学习“前端免费学习笔记（深入）”；
如果你想让下载的文件有一个特定的文件名，即使原始文件名不同，你也可以给download属性一个值：
下载2023年度报告
这样，用户下载到的文件就会被命名为“2023年度报告.pdf”，而不是“original-report.pdf”。这在处理从数据库导出或经过复杂命名规则生成的文件时特别有用，你可以给用户一个更友好的文件名。
在我看来，这个属性的出现极大地简化了前端控制下载行为的逻辑。以前我们可能需要一些JavaScript技巧，甚至依赖服务器端的Content-Disposition头，但现在，一个简单的HTML属性就能搞定大部分情况。
为什么download属性有时会“失效”？
说实话，我刚开始用download属性的时候，觉得它简直是万能的。但用着用着，总会遇到一些它不按预期工作的情况。这通常不是属性本身的问题，而是涉及到一些浏览器安全策略或服务器配置。
一个最常见的“失效”场景是跨域下载。如果你尝试下载一个位于不同域名下的文件，比如你的网站是www.example.com，而文件在cdn.another-domain.com，那么download属性可能就无法强制下载了。浏览器出于安全考虑，通常会阻止这种行为，因为它可能被滥用。在这种情况下，浏览器会优先遵循服务器的Content-Disposition头。如果服务器返回的是inline，浏览器就会尝试打开而不是下载。
另一个我遇到过的情况是，一些非常老的浏览器版本可能对download属性的支持不完善。虽然现在主流浏览器（Chrome, Firefox, Safari, Edge）都支持得很好，但如果你需要兼容特别老的IE版本，那可能就需要额外的JavaScript或服务器端方案。
最后，文件本身的MIME类型也可能影响。虽然download属性旨在覆盖默认行为，但如果服务器没有发送正确的Content-Type头，或者文件本身有问题，也可能导致下载失败。例如，一个本应是PDF的文件，服务器却返回了text/html的MIME类型，浏览器可能会迷惑。
强制文件下载的终极武器：服务器端的Content-Disposition头
尽管download属性很方便，但它毕竟是前端的“请求”或“建议”。真正能做到“强制”下载，尤其是在跨域或需要严格控制下载行为的场景下，还得靠服务器端的配合。这就像是，前端说“请下载”，而服务器说“好的，我强制你下载”。
服务器通过设置HTTP响应头中的Content-Disposition字段，来告诉浏览器如何处理返回的文件。这个字段有两个主要的值：
-
inline: 浏览器应该尝试在当前页面或新标签页中显示文件（例如图片、PDF）。 -
attachment: 浏览器应该将文件作为附件下载，而不是显示它。
所以，如果你想确保文件总是被下载，无论用户点击的是什么链接，无论文件是否跨域，服务器端应该设置如下响应头：
Content-Disposition: attachment; filename="你想要的文件名.pdf" Content-Type: application/pdf
这里的filename参数是可选的，但强烈建议加上，它可以确保用户下载到的文件有一个预期的名称。Content-Type也很重要，它告诉浏览器文件的实际类型。
在我看来，这是最可靠的强制下载方式。特别是当你处理用户上传的文件，或者需要对文件下载进行权限控制、日志记录时，服务器端控制是必不可少的。前端的download属性更多的是一种便利性功能，而服务器端的Content-Disposition才是真正的“强制执行者”。
动态生成内容或大文件下载的策略
有时候，我们并不想下载一个预先存在的文件，而是希望用户下载一些在浏览器中动态生成的内容，比如一个从Canvas导出的图片，或者一个由JavaScript组装的文本文件。在这种情况下，download属性依然是你的好帮手，但你需要结合JavaScript来使用它。
核心思路是：
- 在客户端生成数据：这可以是Blob对象（Binary Large Object），它代表了不可变的原始数据。
-
创建URL：使用
URL.createObjectURL()方法从Blob创建一个临时的URL。这个URL是一个特殊的本地URL，它指向浏览器内存中的数据。 -
应用
download属性：将这个临时URL赋值给标签的href属性，并加上download属性。
这是一个简单的JavaScript示例，用于下载一个动态生成的文本文件：
function downloadTextFile() {
const textContent = "这是我动态生成的一些文本内容。\n它可以是任何字符串。";
const blob = new Blob([textContent], { type: "text/plain" });
const url = URL.createObjectURL(blob);
const a = document.createElement('a');
a.href = url;
a.download = "my_dynamic_file.txt"; // 设置下载的文件名
document.body.appendChild(a); // 需要将a标签添加到DOM中才能触发点击
a.click(); // 模拟点击
document.body.removeChild(a); // 清理，移除a标签
URL.revokeObjectURL(url); // 释放URL对象，回收内存
}
// 假设你有一个按钮来触发这个函数
// 对于大文件下载，情况就复杂一些了。虽然download属性和服务器端的Content-Disposition能处理下载，但如果文件非常大（比如几个GB），用户体验会变得很重要。这时候，服务器端通常会采用流式传输（streaming）的方式来发送文件，而不是一次性将整个文件加载到内存中。这有助于减少服务器的内存消耗，并允许浏览器在文件完全下载之前就开始处理它（例如显示下载进度）。
从前端的角度看，大文件下载的用户体验优化主要体现在：
-
下载进度条：浏览器通常会自带下载进度显示，但如果文件是通过AJAX请求下载的（例如，为了在下载前进行一些验证），你可以监听XHR的
progress事件来显示自定义进度。 -
断点续传：这是一个高级功能，通常需要服务器端支持HTTP的
Range头。它允许用户在下载中断后从中断的地方继续下载，而不是重新开始。
我个人觉得，对于大多数应用场景，理解download属性的基本用法和服务器端Content-Disposition头的原理就足够应对90%的下载需求了。至于动态生成内容和超大文件，那是更深层次的优化和工程问题，但其核心思想依然是围绕着这两个基础机制展开的。
