优先从Content-Disposition响应头提取filename，缺失则回退解析URL路径；需解码UTF-8编码、过滤Windows非法字符；推荐用SHA256前8位+原始名防重；下载后校验文件头确保为真实音频。
requests 下载音频时文件名丢失怎么办
直接用 requests.get(url) 拿到二进制内容后，open('audio.mp3', 'wb') 这样硬写死文件名，根本没法区分不同音频。关键是要从响应头或 URL 中提取真实文件名。
优先看 Content-Disposition 响应头：
content_disposition = response.headers.get('Content-Disposition')
if content_disposition and 'filename=' in content_disposition:
filename = content_disposition.split('filename=')[-1].strip('"\'')如果没这个头，就退回到 URL 路径末尾：os.path.basename(urlparse(url).path)，但要注意 URL 可能带参数（如 ?t=123），得先用 urlparse(url).path 截掉查询参数。
- 别直接用
url.split('/')[-1]—— 遇到/api/download?id=456就变成id=456，不是音频名 - 响应头里的 filename 有时是 UTF-8 编码的，需用
email.utils.unquote或手动解码 - Windows 下文件名含
:、*、?会报错，下载前务必过滤非法字符
批量重命名逻辑怎么设计才不冲突
按原始名保存容易重复（比如多个链接都叫 download.mp3），但全用时间戳又难识别。稳妥做法是「基础名 + 序号」或「哈希前缀 + 原始名」。
推荐用音频内容的 SHA256 前 8 位打头：
import hashlib
hash_prefix = hashlib.sha256(content).hexdigest()[:8]
safe_name = f"{hash_prefix}_{clean_filename}"这样相同音频不会重复下载，不同音频即使原始名一样也能区分。
- 别只依赖 URL 参数做重命名依据——参数可能动态变化，实际音频却相同
- 如果业务上要求按序号命名（如
001_标题.mp3），必须先获取全部 URL 列表再统一编号，不能边请求边编号（网络延迟会导致顺序错乱） - 重命名前先
os.path.exists()检查，但注意并发下载时存在竞态条件，简单场景加个time.sleep(0.1)足够，高并发要用文件锁
遇到 403 或 Referer 限制怎么绕过
很多音频接口校验 Referer 或 User-Agent，直接 requests 默认请求头会被拒，返回 403 Forbidden 或空响应。
提示词大师-python版
下载
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
必须显式传入合法请求头：
headers = {
'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36',
'Referer': 'https://example.com/listen/'
}
response = requests.get(url, headers=headers, timeout=10)Referer 值要和目标网站实际页面一致，抓包看浏览器发的是什么就填什么。
- 有些站点还校验
Cookie或X-Requested-With，F12 Network 面板里点开一个成功请求，复制 Request Headers 全部内容最保险 - 别在循环里反复新建
Session()对象——复用 session 能自动携带 Cookie，也更省资源 - 频繁请求触发反爬？加
time.sleep(1)比伪装 UA 更有效；真要提速，用concurrent.futures.ThreadPoolExecutor控制并发数（建议 ≤3）
如何判断下载的是真音频而不是 HTML 错误页
常见陷阱：URL 看似是 mp3，但服务端出错时返回的是 HTML（比如 502 页面或登录跳转），结果下了一堆“音频”实为网页源码，双击打不开。
立即学习“Python免费学习笔记（深入）”；
靠文件头（magic bytes）验证最可靠：
if content[:4] in [b'\xff\xf3', b'\xff\xf2', b'ID3']: # MP3 header
pass
elif content[:4] == b'RIFF' and content[8:12] == b'WAVE': # WAV
pass
else:
raise ValueError("Not a valid audio file")也可以检查 response.headers.get('Content-Type') 是否含 audio/，但不可靠——很多服务器根本不设对。
- 别只检查扩展名！
.mp3后缀完全可伪造 - 用
mutagen库解析元数据虽准，但太重，仅需校验有效性时用 magic bytes 足够 - 下载后立即用
ffprobe -v error -show_entries format=duration -of default=nw=1验证是否可播放，适合关键任务
真正麻烦的不是下载动作本身，而是每个音频来源都有自己的脾气：有的靠 Referer，有的要 Cookie，有的返回假文件头，有的重定向链套三层。留好日志，把 response.status_code、response.url、len(content) 都记下来，出问题时一眼能看出卡在哪一环。
