网站下载附件这个功能，网站看着简单，下载实则处处是附件坑。我上周刚帮一个朋友排查问题，网站他网站上的下载PDF下载按钮点了没反应，折腾半天发现是附件服务器把`.pdf`文件当成了`text/html`类型输出，浏览器直接给渲染成乱码了。网站这种事，下载技术群里几乎天天有人问。附件

下载附件的网站本质，就是下载服务器告诉浏览器“这个资源你别直接打开，存到本地去”。附件实现方式就那么几种，网站但每种都有各自的下载脾气。最传统的附件是在后端接口里设置响应头`Content-Disposition: attachment; filename="xxx.pdf"`，浏览器收到这个头，就会弹出下载框。这个方法兼容性最好，但有个坑——文件名如果带中文，必须做URL编码，否则老版本浏览器会给你存成一个乱码文件名，用户下载完根本不知道这文件是啥。

还有种常见做法是HTML5的`download`属性，直接写在``标签上：`下载报告`。这个属性简单粗暴，但只对同源URL有效，跨域资源会被浏览器直接忽略这个属性。更气人的是，如果目标链接是动态生成的，比如带了个token参数，某些浏览器也会失灵。我见过有开发图省事，把所有下载链接都加了这个属性，结果用户反馈“点下载直接打开了新标签页”，排查半天才发现是Nginx反代把跨域头给吞了。

真正让人头疼的是大文件下载。你给用户提供个500MB的压缩包，普通方式下载到一半断线，用户就得从头再来。这时候得用`Range`请求，支持断点续传。服务器要处理`Accept-Ranges: bytes`，客户端要能发起分段请求。别指望前端那点代码能搞定，这活必须后端配合。有个做教育产品的朋友跟我说，他们平台上传的教学视频有2个G，最初没做断点续传，用户投诉率飙到30%，后来加了支持，投诉直接降到个位数。你看，这功能不做不行。

还有个容易被忽视的细节是文件完整性校验。下载完的文件是不是损坏了？光靠用户自己试错可不行。正经做法是在下载接口旁边附带一个MD5或SHA256值，前端拿到文件后算一遍哈希，对不上就提示用户重新下载。我见过更讲究的，用`Content-MD5`头直接下发校验值，但支持这头的浏览器不多，实用价值有限。更实际的做法是后端生成文件时就把哈希值存进数据库，下载时通过另一个接口暴露出来。

最后说个安全坑。千万别直接暴露文件在服务器上的绝对路径，比如`/var/www/html/uploads/../../etc/passwd`这种，只要路径参数没做过滤，攻击者能给你把服务器底裤都翻出来。正确姿势是把文件存到Web根目录之外，下载时通过程序去读，再配合权限校验。之前有个小公司，就是因为下载链接直接拼了文件名参数，被黑客遍历目录把客户资料全拖走了，最后赔了违约金还上了新闻。这种教训，一次就够受的。

下载功能做得好不好，用户感知最直接。下载慢、断线、文件损坏，这些体验问题比页面好不好看重要多了。下次写下载功能前，先想清楚文件多大、用户网络环境如何、要不要支持续传。技术选型不是堆功能，是解决实际问题。