PHP响应触发Edge调试器十六进制视图问题求助

• 检查请求头的Accept编码设置
  前端fetch请求如果携带Accept-Encoding: gzip, deflate，但PHP或IIS的压缩模块出现异常，可能导致返回的压缩内容被浏览器以十六进制形式解析。可以临时在fetch中去掉编码请求头测试，或者用curl发起不带编码的请求，观察返回是否恢复正常。

• 验证PHP输出缓冲区状态
  异常发生前如果代码调用了ob_start('ob_gzhandler')这类压缩输出函数，或是第三方库偷偷开启了输出压缩，当脚本异常中断时，缓冲区的压缩数据未正常收尾，就会呈现乱码/十六进制。可以在API入口处临时添加ob_end_clean()关闭缓冲区，再触发异常查看返回情况。

• 排查IIS动态压缩模块状态
  即便未手动修改配置，IIS的动态压缩模块（Dynamic Compression）可能因服务器资源不足、模块崩溃自动重启，导致压缩逻辑异常。可通过IIS管理器的“压缩”功能项临时禁用动态压缩测试；或用命令行appcmd set config /section:urlCompression /doDynamicCompression:False临时关闭，验证是否解决问题。

• 检查PHP错误输出的编码一致性
  确认PHP的default_charset设置（即便没改php.ini，也可能被.htaccess、.user.ini或代码里的ini_set()修改），若charset设置和响应头的Content-Type不一致，可能引发浏览器解析错误。可在异常触发的脚本里强制输出header('Content-Type: text/html; charset=utf-8')，再抛出异常查看返回。

• 排查服务器端临时文件/缓存问题
  IIS或PHP的临时缓存目录（比如PHP的upload_tmp_dir、IIS的压缩缓存目录）可能出现权限问题或文件损坏，导致压缩输出异常。可清理这些目录的临时文件，重启IIS和PHP-FPM（若使用FastCGI模式）后再测试。

• 验证FastCGI进程状态
  若PHP通过FastCGI运行，FastCGI进程池可能因异常崩溃后重启，导致进程配置加载异常。可在IIS的“FastCGI设置”中找到PHP的进程池，手动回收进程，再触发异常查看返回是否正常。

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