应避免使用urlretrieve，改用urlopen+手动写文件，并设置timeout、User-Agent、Cookie等；下载后需校验文件完整性，优先用zipfile.is_zipfile()或MD5比对。
urllib.request.urlretrieve 下载中断或返回空文件
用 urlretrieve 下载压缩包时，常见现象是文件大小为 0 字节，或者下载到一半就停住，但不报错。这通常不是代码写错了，而是服务器返回了 302 重定向、需要 User-Agent、或响应头里 Content-Length 缺失导致 urlretrieve 误判结束位置。
- 加
headers={'User-Agent': 'Mozilla/5.0'}再封装成Request对象，用urlopen+ 手动写文件替代urlretrieve - 别依赖
urlretrieve的自动进度回调——它在重定向后可能失效，且对 chunked transfer 编码支持差 - 下载前先
HEAD请求检查Content-Length和Content-Type，确认是application/zip或application/x-tar类型再继续
用 urllib 发起带 Cookie 或登录态的下载请求
很多网站的压缩包链接需要登录后才能访问，直接传 URL 给 urlretrieve 会 403 或跳转到登录页。urllib 本身不维护会话，必须手动管理 cookie。
- 先用浏览器或
curl -v抓出有效请求的Cookie头（比如sessionid=abc123），硬编码进headers是最快验证方式 - 真要模拟登录，得用
HTTPCookieProcessor搭配build_opener，但注意：cookie 不会自动随重定向携带，需设redirect_handler = HTTPRedirectHandler()并确保 opener 支持 - 避免把整个
Set-Cookie响应头原样塞进请求——只取name=value部分，多余属性（如Path=,Expires=）会导致 400
大压缩包下载中如何判断是否卡死或超时
urlopen 默认无读取超时，遇到网络抖动或服务端慢响应，程序可能挂住几分钟不动。尤其在自动化脚本里，不能靠人盯。
- 必须显式传
timeout=30给urlopen（单位秒），这个值是连接 + 读取总时长，不是分开的 - 下载循环里用
response.read(8192)分块读，每次读完立刻检查len(chunk)，连续两次读到 0 且response.isclosed()为False，大概率是服务端断连 - 别用
time.time()自己计时——urllib 的 timeout 机制更可靠，自己计时容易和 socket 层行为错位
下载完成后校验压缩包是否完整可用
下载完的 .zip 或 .tar.gz 文件，光看大小匹配不够——网络传输中偶尔会静默损坏，解压时报 BadZipFile 或 TruncatedHeaderError 才发现白忙活。
立即学习“Python免费学习笔记（深入）”；
- 优先用
zipfile.is_zipfile(path)或tarfile.is_tarfile(path)快速探活，比直接ZipFile.open()更轻量 - 如果服务器提供了
Content-MD5或ETag响应头，下载后算 MD5 对比，比文件大小靠谱得多 - 解压校验别用
subprocess.run(['unzip', '-t'])——跨平台麻烦，且依赖系统命令；用zipfile.ZipFile().testzip()更直接，返回None表示没问题
真正难的不是“怎么下”，而是怎么让下载在各种边界网络条件下稳定收尾：重定向、限速、临时 502、甚至 CDN 返回缓存的 200 但 body 是空 HTML。urllib 能做，但每一步都得亲手兜底，没银弹。
