requests直接写入二进制文件易致图片头信息缺失，因response.content可能截断且无校验；正确做法是流式下载（iter_content）、比对Content-Length、写后强制fsync，并用PIL.open().load()验证解码。
requests直接写入二进制文件导致图片头信息缺失
很多人用 response.content 一气呵成写入文件，看似简洁，但一旦网络中断、响应截断或服务器返回非完整数据，文件就只剩个空壳或半截数据——Windows 看图器打不开，Linux 下 file image.jpg 会报 “data” 而非 “JPEG image data”。这不是编码问题，是文件根本没写全。
关键点在于：requests.get() 默认会把整个响应体加载进内存再返回 content，如果中途连接断开或超时，content 就是残缺的，但程序不会报错。
- 必须检查
response.status_code == 200，且response.headers.get("content-length")存在并匹配实际写入字节数 - 避免用
response.content，改用流式下载 + 显式校验 - 写入前先创建空文件，写完立刻
os.fsync()强制刷盘（尤其在 Linux/WSL 下）
流式下载时未校验 Content-Length 或 Transfer-Encoding
有些 CDN 或反向代理会省略 Content-Length，改用 Transfer-Encoding: chunked。此时靠 len(response.content) 校验完全失效，你得依赖流式读取结束信号——但更稳妥的做法是：下载后用 Pillow 打开并触发解码。
示例中常见错误写法：
立即学习“Python免费学习笔记（深入）”；
with open("img.jpg", "wb") as f:
f.write(response.content) # ❌ 不校验长度，不处理 chunked正确做法是：
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 优先用
response.iter_content(chunk_size=8192)分块写入 - 记录累计写入字节数，与响应头中的
content-length对比（若存在） - 写完后用
PIL.Image.open()尝试加载，捕获IOError或UnidentifiedImageError
保存后无法打开却无报错：Pillow 的静默失败陷阱
PIL.Image.save() 默认不会校验图像数据是否真正可解码，它只负责按格式封装像素数组。如果你传入的是损坏的原始字节，它照样能“成功”写出一个带 JPEG 头但内部解码失败的文件。
真正可靠的验证方式是：下载后立即用 Pillow 打开并强制解码像素。
- 不要只调用
Image.open(path)，要加.load()或访问.size - 例如：
Image.open("img.jpg").verify()（注意：verify 可能抛出异常，需 try/catch） - 更实用的是：
img = Image.open(io.BytesIO(data)); img.load()—— 这一步才真正触发解码
文件扩展名与 Content-Type 不匹配导致系统误判
很多网站返回的图片 URL 没有后缀（如 https://xxx.com/i/abc123），而响应头里的 Content-Type 是 image/webp。你硬存成 .jpg，系统就按 JPEG 解析，必然失败。
解决方法不是猜后缀，而是信响应头：
- 从
response.headers.get("content-type")提取类型，映射为扩展名（如"image/webp" → ".webp"） - fallback 到
imghdr.what(None, h=response.content[:32])做二进制嗅探（但仅限前 32 字节） - 绝对不要用 URL 路径后缀做唯一依据——
https://i.example.com/123?w=800&h=600这种链接根本没有扩展名
最易被忽略的一点：即使所有步骤都做了，某些网站返回的图片数据本身含不可见控制字符（比如开头多了 BOM 或换行），BytesIO 能绕过，但直接写文件再读就会失败。这时候必须用 response.content.strip(b"\x00\r\n\t") 预清洗。
