去年帮一个客户排查文件下载问题时，控件我盯着浏览器下载栏里那个文件名看了半天——“download.aspx”。下载用户点的位置是“季度报表.xlsx”，下到本地却变成了一个aspx页面。错误打开一看，控件里面是下载乱码。这事儿不复杂，位置但挺典型，错误值得说几句。控件
问题出在下载按钮的下载写法上。前端是位置一个<asp:LinkButton>，后端在Click事件里用Response.BinaryWrite把文件流写出去。错误逻辑看着没毛病，控件但下载下来的下载东西就是不对。我让开发把LinkButton换成普通的位置<a href="DownloadHandler.ashx?id=123">，问题立刻消失了。
原因不神秘。LinkButton渲染到页面上是一个<a>标签，但它的href指向的是javascript:__doPostBack(...)。点击它，浏览器发起的是异步POST请求，而不是一次普通的GET导航。服务端Response.BinaryWrite写出来的字节流，被浏览器当成了当前页面的AJAX响应内容去处理。下载行为根本没有被触发，页面倒是收到了一坨二进制数据，浏览器不知道怎么渲染，干脆把它存成了一个文件。文件名自然就是当前页面的名字。
这个坑在WebForms项目里出现频率极高。因为LinkButton、ImageButton、Button这些控件在WebForms里太顺手了，开发者习惯性地用它们处理一切交互，包括文件下载。下载本质上是一次HTTP响应，需要浏览器接管后续行为，而ASP.NET控件的PostBack机制把这次响应截胡了。
有人会说，那我用Response.Redirect跳到一个下载页行不行？行，但多一次请求，而且如果文件大，用户体验会有一个明显的空白等待。更干净的做法是直接输出一个指向.ashx通用处理程序的链接，或者用window.location在前端触发导航。关键是让浏览器知道：这是一次独立的资源请求，不是页面回发的一部分。
还有一种情况更隐蔽。有些项目用了UpdatePanel，开发者以为把下载逻辑放在UpdatePanel外面就没事了，但LinkButton只要在UpdatePanel内部，PostBack就是异步的。下载照样失败。UpdatePanel的异步回发机制和文件下载天然冲突，因为前者期望服务端返回一段可以更新DOM的HTML片段，而后者返回的是文件字节流。
我后来翻了翻那个项目的代码，发现类似的下载按钮有七八个，全是LinkButton。开发者的理由很统一：“方便在后台写权限判断。”这个需求合理，但实现方式不对。权限判断可以在ashx里做，可以从Session或Token里取用户信息，没必要非得绑在控件事件上。
顺带提一个细节。即使把LinkButton换成<a>，如果href写的是javascript:void(0)然后靠JS发XMLHttpRequest去拿文件流，同样会踩坑。因为XHR拿到的是ArrayBuffer，你得自己在前端构造Blob和URL.createObjectURL才能触发下载。多绕了一圈，还得处理内存释放。除非有特殊需求，比如需要在下载前做加密校验，否则没必要走这条路。
说到底，ASP.NET WebForms的控件模型是为页面交互设计的，不是为文件传输设计的。把下载按钮做成服务器控件，等于让一个负责页面生命周期的东西去干HTTP传输层的活。两套机制打架，下载位置出错只是表象，根子上是职责错配。换成ashx或者MVC的FileResult，让下载回归HTTP请求的本质，问题就不会再出现。