php下载文件打不开，大概率因bom头或空行导致响应体开头混入非法字节（如ef bb bf），破坏pdf、zip等格式二进制结构；需用headers_sent()检测输出时机，并用xxd验证脚本开头字节。
PHP下载文件打不开，大概率是因为脚本在readfile()或fpassthru()之前已输出了不可见内容——最常见的是BOM头或空行。
为什么BOM头会让下载文件损坏
BOM头（0xEF 0xBB 0xBF）是三个字节的隐藏标记，PHP不会跳过它，而是原样当作响应体开头内容发送。浏览器收到的文件流实际是：0xEF 0xBB 0xBF + 原始文件二进制数据。PDF、ZIP、Excel等格式对文件头极其敏感，多出这三个字节就会直接报“文件已损坏”或“无法打开”。
- 不是乱码，是二进制结构被篡改
- 用十六进制编辑器（如 HxD、xxd）打开下载下来的文件，开头若看到
ef bb bf，就坐实了BOM问题 - 即使
header('Content-Type: application/octet-stream')设得再准也无效——内容本身已污染
怎么快速确认是不是BOM或空行导致的
别猜，直接验证：
- 在下载脚本最顶部插入：
if (headers_sent($file, $line)) { die("headers already sent at $file:$line"); }，看是否立即中断 - 用命令行检查文件开头字节：
head -c 3 your_script.php | xxd，输出00000000: efbb bf就是BOM - 临时把整个脚本改成只输出一行：
<?php echo 'TEST'; exit;，如果这时下载的文件能打开（哪怕内容不对），说明原逻辑里有前置输出 - 检查所有
include/require的配置文件、函数库——BOM可能藏在任意一个被引入的文件里
批量清除BOM的PHP脚本要避开哪些坑
网上流传的BOM清除脚本容易误伤，关键点在于：
- 只处理
.php、.inc等文本文件，别对.jpg、.pdf执行substr($content, 3)，会直接毁掉二进制文件 -
file_get_contents()读取大文件时可能内存溢出，建议加大小判断：if (filesize($f) > 10 * 1024 * 1024) continue; - 写回文件前必须用
fopen($f, 'wb')（b模式），否则Windows下换行符可能被悄悄转换 - 务必先备份：
copy($f, $f . '.bak');，清除失败还能还原
比删BOM更可靠的长期方案
靠事后清理不如源头阻断：
- 编辑器统一设为“UTF-8 无 BOM”保存（VS Code：右下角编码 → “Save with Encoding” → “UTF-8”；Notepad++：“编码”菜单 → “转为 UTF-8 无 BOM 格式”）
- Git 提交前加钩子检查：
git grep -l $'\xEF\xBB\xBF' -- '*.php'，匹配到就拒绝提交 - CI流程中加入BOM扫描步骤，比上线后用户反馈再修快十倍
- 纯逻辑PHP文件干脆去掉
?>结尾标签——从语法上杜绝末尾空行风险
真正麻烦的不是BOM本身，而是它总躲在你看不见的地方：某个十年前写的config.php、某次用记事本改过的lang/zh_CN.php、甚至Composer自动拉取的第三方包里。排查时别只盯主脚本，得当成一场全项目编码卫生检查来打。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
