多数视频站对m3u8校验Referer、User-Agent或动态token，直接requests.get易得403或空响应；需抓包分析请求头、拼接完整TS路径、控制并发、重试机制及ffmpeg转码合成。
为什么直接请求m3u8返回403或空内容
多数视频站对 m3u8 文件做了 Referer、User-Agent 或 token 校验，甚至动态生成带签名的 URL。单纯用 requests.get() 拿不到真实播放列表，或者拿到的是加密/无效路径。
实操建议：
- 先用浏览器开发者工具（Network → Media）确认真实
m3u8请求头，尤其是Referer和User-Agent，复制到代码里模拟 - 检查响应状态码和
Content-Type：正常应为text/plain或application/vnd.apple.mpegurl；若返回403或 HTML 页面，说明被反爬拦截 - 有些站点的
m3u8是 base64 编码或 JS 动态拼接的，得先解析网页源码或执行 JS（用execjs或playwright），不能只靠正则硬扒
解析m3u8后ts地址是相对路径怎么办
m3u8 里常见 xxx.ts、./seg-1.ts 这类相对路径，直接下载会 404。必须拼出完整 URL，但规则不统一：可能基于 m3u8 文件所在目录、父级路径，甚至另有 base-url 字段（#EXT-X-STREAM-INF:BANDWIDTH=...,RESOLUTION=...,CODECS="avc1.64001f,mp4a.40.2",URI="chunklist_b1200000.m3u8"）。
实操建议：
- 用
urllib.parse.urljoin(base_url, ts_path)拼接，其中base_url是原始m3u8的完整 URL（含目录，不含文件名），不是域名 - 遇到嵌套
m3u8（如主播放列表指向多个清晰度子列表），要递归解析，优先选带BANDWIDTH最高或明确标720p的那个 - 某些 CDN 会在 ts 路径末尾加时间戳或 token 参数（如
seg-1.ts?t=171xxxx&sign=abc），这些参数必须原样保留，丢掉就 403
下载ts切片时频繁超时或连接重置
批量并发请求 ts 切片极易触发服务端限流，表现为 ConnectionResetError、TimeoutError 或大量 503 响应。不是代码写错了，而是节奏没控住。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
实操建议：
- 别用
threading硬开 20 个线程 —— 大多数站点只允许 2~5 路并发，建议从max_workers=3开始试 - 每个请求加随机延时（
time.sleep(random.uniform(0.1, 0.5))），比固定 sleep 更抗识别 - 用
requests.Session()复用连接，设置timeout=(3, 10)（连接 3 秒，读取 10 秒），避免卡死 - 务必捕获异常并重试（最多 2 次），跳过失败切片可能导致 ffmpeg 合并报错：
Non-monotonous DTS或黑屏
ffmpeg合并后音画不同步或开头花屏
直接 ffmpeg -i "concat:1.ts|2.ts|..." -c copy out.mp4 看似快，但绝大多数 m3u8 的 ts 切片不是严格 I 帧对齐的，-c copy 会继承原始时间戳缺陷，导致合成后卡顿、跳帧或音频漂移。
实操建议：
- 放弃
-c copy，老实用转码：ffmpeg -f concat -safe 0 -i filelist.txt -c:v libx264 -c:a aac -movflags +faststart out.mp4 -
filelist.txt必须每行写file '1.ts'（带单引号），不能只写文件名；且所有 ts 必须在同一目录下 - 如果原始 ts 是 AES-128 加密的（
m3u8里有#EXT-X-KEY:METHOD=AES-128,URI="key.key"），必须先用 key 解密再合并，否则 ffmpeg 会静音或报Invalid data found when processing input
最麻烦的其实是加密 + 动态 token + 分段鉴权的组合——这时候光靠 Python 和 ffmpeg 不够，得看具体站点怎么验签，往往得逆向 JS 逻辑。真遇到这种，别硬刚，先确认是否合规可抓。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
