使用download属性可强制文件下载而非预览，支持自定义文件名，但跨域时受限，需结合服务器Content-Disposition头处理；JavaScript可通过Blob和createObjectURL实现动态内容下载。
想要让用户点击链接直接下载文件，而不是在浏览器里直接打开预览？其实很简单，HTML的
<a>标签提供了一个非常方便的
download属性，它能帮你明确告诉浏览器，这个链接指向的资源应该被下载，而不是在当前页面打开。
直接在
<a>标签中添加
download属性即可。
<!-- 最简单的用法，浏览器会根据链接的URL自动命名文件 --> <a href="/files/document.pdf" download>下载PDF文档</a> <!-- 指定下载的文件名，这非常有用 --> <a href="/files/image.jpg" download="我的照片.jpg">下载我的照片</a> <!-- 即使文件类型浏览器通常会直接打开（如文本文件），download属性也会强制下载 --> <a href="/files/report.txt" download="最新报告.txt">下载文本报告</a>
这个
download属性就像一个信号，告诉浏览器：“嘿，别多管闲事了，直接把这个文件保存到用户硬盘上吧！”它会覆盖浏览器对某些文件类型（比如PDF、图片、纯文本等）默认的“预览”行为。需要注意的是，这个属性在跨域资源上会有一些限制，出于安全考虑，浏览器通常不允许你直接控制跨域资源的下载文件名，甚至可能完全忽略
download属性，这在实际开发中是需要留意的。
为什么我点击PDF链接，它总是在浏览器里打开而不是下载？
这大概是我最常被问到的一个问题了。很多时候，我们期望用户点击一个PDF或图片链接时，文件能直接下载到本地，而不是在浏览器的新标签页里直接打开。这其实是浏览器的一种“智能”表现，或者说，是它默认的处理方式。浏览器会根据文件的MIME类型（比如
application/pdf、
image/jpeg）来判断如何处理这个资源。对于那些它能够直接渲染或显示的文件类型，比如PDF、各种图片格式、纯文本文件，浏览器通常会优先选择在当前窗口或新标签页中直接预览，而不是触发下载。
这背后其实是一种用户体验的考量。想象一下，如果你只是想快速查看一张图片，结果每次点击都强制下载，那得多麻烦？但反过来，当我们的意图就是让用户保存文件时，这种默认行为就显得有些“不解风情”了。
download属性正是为了解决这种意图冲突而生的。它就像一个明确的指令，告诉浏览器：“这次，别管你的默认行为了，听我的，直接下载！”所以，如果你发现你的PDF链接总是在浏览器里打开，那多半就是你忘了给
<a>标签加上这个小小的
download属性。
download
属性在不同浏览器中的兼容性表现如何，有没有什么坑？
关于
download属性的兼容性，总体来说，现代主流浏览器对其支持度都相当不错。Chrome、Firefox、Edge、Opera以及Safari（桌面版）这些我们日常使用的浏览器，基本都能很好地理解和执行这个属性。不过，就像所有Web技术一样，它也不是百分之百完美无缺，总有些小细节或者特定场景需要注意。
最大的一个“坑”可能就是我前面提到的跨域资源问题。当你的链接指向的资源不在你当前页面的同源（Same-Origin）策略下时，
download属性可能会被浏览器忽略，或者你设置的文件名不会生效。浏览器出于安全考虑，不会允许一个页面随意控制另一个域的资源下载行为。在这种情况下，如果你确实需要强制下载跨域资源，并且要自定义文件名，那么你可能需要服务器端的配合，通过设置
Content-DispositionHTTP响应头来处理。比如，在服务器端响应中加入
Content-Disposition: attachment; filename="your-custom-name.pdf"，这会比前端的
download属性拥有更高的优先级和更广泛的兼容性，尤其是在处理跨域下载时。
另外，一些非常老旧的浏览器版本可能不支持
download属性，但考虑到现在浏览器的更新速度和用户普及率，这通常不是一个大问题。移动端浏览器，尤其是某些内嵌Web视图的App，有时也可能会有一些奇怪的表现，但大部分情况下，它都能正常工作。总而言之，
download属性是一个非常实用的前端解决方案，但遇到复杂情况，尤其是涉及跨域时，别忘了服务器端
Content-Disposition这个更强大的武器。
我想让用户下载一个动态生成的内容，比如一张Canvas画出来的图片，或者一段用户输入的数据，该怎么用JavaScript实现？
这确实是一个非常常见的需求，也是
download属性结合JavaScript发挥巨大作用的地方。想象一下，用户在你的Web应用里绘制了一张图，或者编辑了一段文字，你希望他们能直接把这些“生成”出来的内容下载到本地，而不是通过截图或者复制粘贴。这时候，我们就需要JavaScript的帮助了。
核心思路是：将动态生成的内容转换为一个
Blob对象，然后为这个
Blob创建一个临时的URL，最后将这个URL赋值给一个
<a>标签的
href属性，并加上
download属性，最后模拟点击这个链接。
我们来看一个简单的例子，如何下载一个Canvas元素绘制的图片：
// 假设你有一个Canvas元素
const canvas = document.getElementById('myCanvas');
const ctx = canvas.getContext('2d');
// 简单绘制一些内容
ctx.fillStyle = 'lightblue';
ctx.fillRect(0, 0, 200, 100);
ctx.fillStyle = 'darkblue';
ctx.font = '20px Arial';
ctx.fillText('Hello Download!', 20, 50);
// 当用户点击一个按钮时触发下载
document.getElementById('downloadButton').addEventListener('click', () => {
// 将Canvas内容转换为Blob对象
canvas.toBlob((blob) => {
// 创建一个临时的URL指向这个Blob
const url = URL.createObjectURL(blob);
// 创建一个临时的<a>元素
const a = document.createElement('a');
a.href = url;
a.download = 'my_drawing.png'; // 设置下载的文件名
// 模拟点击这个<a>元素来触发下载
document.body.appendChild(a); // 某些浏览器需要将元素添加到DOM中才能触发点击
a.click();
document.body.removeChild(a); // 下载完成后移除临时元素
// 释放URL对象，避免内存泄漏
URL.revokeObjectURL(url);
}, 'image/png'); // 指定MIME类型
});在这个例子中，
canvas.toBlob()方法将Canvas的内容异步地转换成了一个
Blob对象。
URL.createObjectURL(blob)则是一个非常关键的API，它会为这个
Blob创建一个临时的、浏览器内部的URL。这个URL的生命周期与创建它的文档相关联，或者直到你调用
URL.revokeObjectURL()显式释放它。之后，我们动态创建一个
<a>标签，将这个临时URL赋给
href，设置
download属性，然后通过
a.click()模拟用户点击，就完成了动态内容的下载。
这种方法不仅适用于Canvas图片，也可以用于下载由JavaScript在前端生成的任何数据，比如通过
new Blob([yourStringData], {type: 'text/plain'})创建的文本文件，或者JSON数据等等。记住，每次URL.createObjectURL后，最好在不再需要时调用
URL.revokeObjectURL来释放资源，这是一个良好的编程习惯，可以避免潜在的内存泄漏。
