为何IIS动态响应末尾会出现UTF-8 BOM？如何排查该问题？

• .NET Framework 内置 HttpWriter 类的已知实现缺陷：部分.NET Framework 早期版本（如4.0及更低版本）存在该问题，当配置 <globalization responseEncoding="utf-8"/> 且开启响应缓冲时，HttpWriter 在最终刷新响应流的逻辑中，错误将UTF-8编码的前导码（BOM）写入到响应流的当前末尾位置，而非响应流起始位置。该逻辑仅作用于走WebForm页面渲染、MVC视图渲染管线的请求，因此手动控制响应流的ASHX类型请求不受影响。
• 托管管道后置编码逻辑冲突：ASP.NET 托管管道在所有业务代码执行完成后、响应输出前的后置处理阶段才尝试写入UTF-8 BOM，此时流指针已经位于已输出内容的末尾，直接写入就会导致BOM出现在响应最后。静态文件走IIS原生处理管线、ASHX由开发者手动控制流写入逻辑，都不会触发该后置写入逻辑，因此不受影响。
• 自带响应处理模块逻辑异常：即使移除了第三方模块，.NET 自带的输出压缩、内容重写等托管模块也可能存在编码处理错误，在压缩/修改响应内容后错误追加BOM到末尾。

• 确认.NET Framework 版本：核实服务器上运行的.NET Framework 版本，查阅官方更新日志确认对应版本是否存在HttpWriter写入BOM位置错误的已知问题，安装对应版本的最新累积更新后复测是否还存在问题。
• 显式禁用BOM输出验证：在Global.asax的Application_BeginRequest事件中添加如下代码，手动指定响应编码不生成BOM：

// 第二个参数设为false表示UTF-8编码不输出BOM
Response.ContentEncoding = new System.Text.UTF8Encoding(false);

修改后复测响应末尾是否还有BOM，若问题消失即可确认是系统自动写入BOM的逻辑导致的问题，该代码也可作为临时修复方案使用。

• 关闭响应缓冲测试：在测试页面级别关闭响应缓冲，WebForm页面添加<%@ Page Buffer="false" %>指令，MVC Action中添加Response.BufferOutput = false;，复测是否还会出现末尾BOM。如果问题消失即可确认是缓冲处理阶段的逻辑错误导致的问题。
• 排查自带托管模块：打开IIS管理器查看当前站点的「模块」列表，逐一禁用.NET 自带的非核心托管模块（如输出压缩模块、动态内容过滤模块等）后复测，定位触发问题的具体模块。
• 最小场景复现验证：新建一个空白的ASP.NET站点，仅保留<globalization responseEncoding="utf-8"/>配置，添加一个只有静态文本的测试页面，确认是否能复现问题。如果空白站点也能复现，即可确认是.NET Framework 版本的原生缺陷，直接通过上述禁用BOM的方案或者安装系统补丁修复即可。

内容的提问来源于stack exchange，提问作者user2864740