在后台导出几万行记录时，点击下载后浏览器长时间没有反应，究竟是查询慢，还是服务端先把全部内容攒在内存里才开始发送？本文用一个逐行生成 CSV 的最小服务观察首包与响应体的关系，并检查参数错误时能否在下载开始前得到明确的状态码。读完后，可以用浏览器网络面板或 curl 检查响应头、逐块返回的内容和非法参数的处理结果；还可以判断何时适合按需生成数据，何时应改用已有文件下载或后台异步导出。示例只展示响应机制，不把开发服务器当作正式导出服务。文章目录点击导出后为何一直等不到文件核心概念与工作机制最小示例验证结果常见误区与适用边界总结点击导出后为何一直等不到文件一个常见写法是先构造完整 CSV 字符串，再把整个字符串交给响应对象。数据量增大时，查询、格式化和内存拼接全部发生在响应返回之前。网络面板里会看到请求持续等待，随后才开始接收文件；服务进程的内存占用也可能随导出量上升。观察位置一次性构造响应时可能看到的现象需要核实的问题浏览器网络面板请求先等待，随后集中接收响应体首包是否被完整构造过程推迟服务端日志视图开始执行后较久才返回时间花在查询、编码还是传输内存监控数据量越大，占用越高是否把完整文件保存在进程内核心概念与工作机制响应体按块生成Flask 可以把生成器作为响应体。视图先返回带有状态码和响应头的Response，随后服务器迭代生成器，把每次yield的内容交给客户端。这样可以避免为了输出整个 CSV 而在 Python 中保留一份完整的结果，但数据库查询、代理缓冲和客户端接收速度仍会影响实际体验。