💔 损坏的文件

情形	会发生什么	怎么处理
抛了异常，用户却什么也没看到	一个笼统的 `try / catch` 把它吞掉，只返回空结果或裸 500。日志里往往也只写了「失败了」。	把哪个文件、第几行、发生了什么返回给用户。实际把损坏文件投进去看看界面，以「用户能否据此采取下一步」来判断。
被截断的文件通过了大小检查	只要小于上限就能通过。没人看另一端，于是 0 字节或几十字节的文件也照样被保存。	同时设置下限。再检查各格式的结尾标记：PDF 应以 `%%EOF` 结束，ZIP 应有 End of Central Directory（`50 4B 05 06`），缺失即可判定被截断。
只看头部就相信了内容	魔术字节正确，并不代表后面没坏。这里的 `header-corrupted` 文件正相反：内容可读，只有开头不对。	不仅在入口校验，在真正读取的环节也要校验。图片就真正解码一次，ZIP 就实际列一次目录，最为可靠。
列数不一致的 CSV 悄悄通过了	多数 CSV 解析器只是按行返回数组，并不检查列数是否一致。缺失的列变成 `null` 后照样入库。	以表头行的列数为基准，逐行比对并带上行号拒绝。若问题出在分隔符或引号，先用 CSV 清理工具整理后再读取更快。

这里模拟的是事故性损坏。刻意构造的攻击输入 —— ZIP 炸弹、极深嵌套的 XML、解压后体积巨大的压缩包 —— 并不包含在内，那些需要在解压前用大小与深度上限拦住。