Azure Function部署后下载外部文件损坏问题排查求助

兄弟我太懂这种本地跑起来顺得一批，一部署到Azure就出妖蛾子的糟心感了！结合我踩过的类似坑，给你列几个排查方向，你可以挨个试试：

先盯紧文件流的处理细节 #

• 检查代码里是不是混用了字符流和字节流：比如下载二进制文件时用了StreamReader/StreamWriter这类处理文本的工具，本地环境可能侥幸没出问题，但Azure的运行时编码配置不一样，直接把二进制转成字符串再写回去肯定会损坏文件。赶紧换成纯字节流操作，比如用byte[]直接读写，或者用FileStream处理。
• 对比本地和部署环境的字节数日志：在代码里加日志，输出下载时响应的Content-Length，以及实际写入文件的字节数。如果部署后写入的字节数比Content-Length小，大概率是流没写完就被中断了——比如异步操作没加await，导致函数提前结束，文件还没写完就被截断了。

排查Azure Function的宿主限制 #

• 检查函数超时时间：本地调试没有超时限制，但Azure消费计划的函数默认超时是5分钟，如果你的文件比较大，可能还没下完函数就被强制终止了。去Azure Portal的函数应用配置里，把超时时间调长试试（消费计划最长只能设10分钟，要是文件更大可能得换高级计划）。
• 留意临时存储的坑：部署后Azure Function用的是临时目录，你是不是把下载的文件写到临时目录后，没等写完就去读？或者临时目录的权限不够导致写入不完整？可以试试把文件写到Azure Blob存储里，跳过临时目录看看会不会好。

对比本地和部署的网络请求差异 #

• 检查请求头的Accept-Encoding：本地环境可能默认没开压缩，但Azure函数的默认请求头可能带了gzip, deflate，如果目标网站返回了压缩后的内容，你没做解压缩直接写入文件，那文件肯定是损坏的。在请求里手动把Accept-Encoding设为identity，或者在代码里加解压缩的逻辑。
• 确认会话有效性：本地登录后的Cookie和部署环境的会话是不是一致？会不会部署后登录的会话权限不够，只能下载部分内容？可以在代码里打日志，输出登录后的Cookie信息，以及下载请求的响应状态码、响应头，和本地的日志对比，看看有没有差异。

最后来个硬核验证 #

把本地下载的正常文件和部署后损坏的文件用二进制对比工具（比如WinHex）打开看看差异：

• 如果是末尾缺失，基本就是超时或者流没写完的问题；
• 如果是开头部分乱码，大概率是编码或者压缩没处理的问题；
• 如果是中间部分有差异，可能是网络传输中丢包或者被篡改了。

备注：内容来源于stack exchange，提问作者f_olivere