企业官网建设流程全解析

IPTV 直播源这东西，说穿了就是一行行 URL 加频道名的纯文本。运营商机顶盒里跑的是组播地址，网上流传的多半是单播地址，格式绕不开 m3u、m3u8、txt 这几种。麻烦在于这些地址会过期、会限速、会换端口，同一个源在不同时间、不同网络环境下的表现能差出十万八千里。所以我这几年一直用一套叫 IPTV Checker 的直播源自动检测工具来干这件事：几百上千条源一次性丢进去，跑一遍，把能连上的、响应快的、画质高的挑出来排序，剩下的直接扔掉。它不是一个具体软件的名字，更像一类工具的统一叫法，核心就两个字，检测。

这套东西适合谁？家里折腾过组播转单播、在 NAS 上挂过播放服务、手里攒了一大堆 m3u 却不知道哪条还能用的朋友，看完能直接抄作业。纯粹想看直播、不打算动网络配置的朋友，也能从里面搞明白"为什么我这个地方台卡成 PPT，隔壁频道却丝滑"的底层原因。下面我把检测这件事从原理到代码、从网络侧配置到踩坑经验，完整拆一遍。

1. 直播源检测这件事，到底难在哪

1.1 手工测源的三条死路

最开始大家都是手工测。复制一条地址，粘到播放器里，等它转圈，能出画面就留下，黑屏就删掉。一百条源这么搞一遍，半小时过去了，而且测出来的结论基本没用。

第一条死路是样本太少。你测的时候，那台服务器可能正好空闲，等你晚上八点真正想看的时候，它已经在给几千个客户端供流，首包要等三秒，码率掉到 1 Mbps，画面糊成一团马赛克。手工测只能反映"检测那一瞬间"的状态，而直播源的质量是随时间剧烈波动的。

第二条死路是判断标准模糊。播放器能出画面，算通过；三秒后卡住，算不算通过？画面出来了但只有 360p，跟标称的 1080p 差了十万八千里，算不算通过？很多人手里那批源，其实有相当一部分是"能连上但根本没法看"，靠眼睛判断根本区分不出来。

第三条死路是不能规模化。你攒了八百条源，怎么筛？一条条试是不可能的。而直播源的生命周期又特别短，今天能用的一批，两周后可能死掉三成，某些频道甚至一天换一次地址。人工维护的成本会迅速超过看直播本身的收益。

所以自动检测工具解决的其实是三个问题：批量化、量化打分、周期性重跑。这三件事各自都不难，难的是把它们串成一条可以无人值守的流水线。

1.2 一次合格的检测应该采集哪些指标

很多人以为检测就是"能不能连上"，这是最常见的误解。连上只是入场券，真正决定观看体验的是后面一串数字。我按重要性排了一下，这套指标基本覆盖了 95% 的实际场景。

这份表里最容易被忽略的是最后一行。有些服务器在源失效时不是返回 404，而是返回一个 200 的 HTML 页面，里面写着"资源已过期，请重新获取"。你的检测脚本如果只看状态码，就会把这种源判定为可用，然后在播放器里得到一个黑屏，还找不到原因。判断依据很简单：正常视频流的 Content-Type 一般是video/mp2t、application/vnd.apple.mpegurl、video/mp4这类，如果返回text/html，无论状态码是多少，一律判死。

同样容易被忽略的是"连续通过率"。单次检测有随机性，网络抖动、服务器瞬时拥塞都会造成误判。稳妥的做法是同一批源连测三轮，间隔几十秒，只有三轮都通过的才标记为优质源。实测下来，这一招能把误判率压到很低，代价只是检测时间乘以三，对于后台跑的定时任务来说完全可以接受。

2. IPTV Checker 的核心机制拆解

2.1 播放列表解析：m3u、m3u8、txt 的三种形态

所有检测工具的第一道工序都是解析。看起来简单，实际上坑不少，因为直播源的文本格式根本没有统一标准，各家生成器都在自由发挥。

标准 m3u 的写法是这样：

#EXTM3U #EXTINF:-1 tvg-id="cctv1" tvg-name="CCTV-1" tvg-logo="http://example.com/logo.png" group-title="央视",CCTV-1 综合 http://example.com/live/cctv1.m3u8

#EXTINF那一行是元数据，逗号后面的部分是频道显示名，下一行才是真正的播放地址。而实际流传的文件里，你可能遇到只有#EXTINF:-1,频道名的简写版，也可能遇到连#EXTINF都没有、一行一个 URL 的裸地址版，还有些 txt 格式是用"频道名,地址"或者"频道名 空格 地址"分隔的。

解析的时候我的做法是写一套宽松匹配，先按行读，遇到#EXTINF就抓tvg-name、group-title这两个关键字段，抓不到就退回到取逗号后面的文本；遇到http开头的行就当成地址，和上一条元数据配对。如果地址行前面没有元数据，就用 URL 的最后一段当频道名。这套逻辑写下来不到五十行，但能吃掉市面上绝大多数格式变体。

还有一个细节：地址后面常带查询参数，比如?token=abc&expire=1735689600。这些参数是有用的，不能为了去重把它们删掉，因为不同 token 可能就是不同源。去重应该用"域名+路径"作为键，忽略查询串，这样既能识别真正的重复，又不会误杀。

2.2 探测层的三种技术路线与取舍

解析完了就是探。这一步有三条主流路线，各有适用场景，选错了要么慢得离谱，要么结论不准。

第一条是纯 HTTP 探测。用 HTTP 客户端发一个 GET，读几秒的数据，统计字节数和耗时。优点是快、并发高、资源占用低，一台普通设备跑几百并发毫无压力。缺点是它只能告诉你"这条链接在传数据"，无法确认传的是不是可解码的视频。有些源的返回内容其实是错误提示页，字节数看着还行，实际一点用没有。

第二条是 ffprobe 探测。调用 FFmpeg 套件里的ffprobe，让它去解析流，然后输出分辨率、编码、码率、帧率等元信息。优点是结论权威，能直接拿到分辨率，判定"标称高清实为标清"这种问题特别准。缺点是慢，一次探测动辄三五秒，而且每个探测都要起一个进程，并发上去了 CPU 直接吃满。

第三条是混合路线，也是我最后采用并推荐的做法：先用 HTTP 探测做初筛，把明显连不上的、超时的、返回 HTML 的一大批先踢掉，剩下大概 20% 到 30% 的候选源，再交给 ffprobe 做精检。这样既保证了速度，又拿到了准确的分辨率信息。实测一千条源，纯 ffprobe 要跑十几分钟，混合方案两分钟出头就能出结果，而且结论一模一样。

注意：ffprobe 必须显式设置超时参数，否则遇到那种"连上但不发数据"的源，它会一直挂在那里等，整个检测流程就卡死了。

2.3 评分模型：怎么把一堆数字变成一个排序

拿到一堆指标之后，得有个办法把它们合成一个分数，才能排序。我的评分模型是这样设计的，权重可以根据自己的偏好调整：

总分 = 40 × 响应分 + 35 × 画质分 + 25 × 可靠分 响应分 = clamp(1 - TTFB / 3000, 0, 1) 画质分 = clamp(码率 / 12000000, 0, 1) × 0.6 + clamp(宽度 / 1920, 0, 1) × 0.4 可靠分 = 通过轮次 / 总轮次

这套公式背后的逻辑很直白。响应分决定换台体感，权重给 40 是因为它最影响第一印象；画质分决定观看体验，但码率不是越高越好，超过 12 Mbps 之后边际收益很低，所以做了截断；可靠分是长期可用性的保障，权重 25 是因为单次检测的可靠分意义有限，它的价值在于多轮累积。

实际用的时候还有个隐藏技巧：同一个频道往往有多个源，评分排序之后，不要只留第一名，留前三名做成备份组。播放器支持多源自动切换的话，主源挂了能瞬间切到备源，体验会好很多。这个细节后面第 5 章会展开讲。

3. 从零实现一个可落地的自动检测脚本

3.1 环境准备与依赖清单

整个工具链只需要 Python 3.9 以上版本，加上几个库。我不推荐用太重的东西，检测脚本越轻越好，跑在路由器、NAS、甚至老旧笔记本上都行。

python3 -m venv venv source venv/bin/activate pip install aiohttp ffmpeg-python

系统层面还需要装 FFmpeg，因为要用到ffprobe。Debian/Ubuntu 系一条命令搞定，容器环境直接用linuxserver/ffmpeg这类镜像做基础层也行。如果你的 NAS 系统自带应用市场，通常也能直接装。

apt-get update && apt-get install -y ffmpeg ffprobe -version

选aiohttp而不是requests，原因是前者是原生异步，能在单线程里跑几百个并发请求，内存占用却很低。用requests加线程池也能实现，但线程数一多上下文切换开销就上来了，五百并发的时候差距非常明显。

提示：如果检测设备的内存比较紧张，把并发数控制在 200 以内。每个并发连接大约占用几十 KB 到几百 KB 的缓冲区，取决于你读多少数据。不做限制的话，几百并发加上读缓冲能把小内存设备压垮。

3.2 列表清洗、归一化与去重

第一步是把原始列表洗干净。很多网上流传的 m3u 文件里混着空行、注释、重复项，还有格式错乱的条目，直接进检测流程会造成大量无效请求。

import re from urllib.parse import urlparse, urlunparse EXTINF_RE = re.compile(r'#EXTINF:.*?,(.*)$') ATTR_RE = re.compile(r'(\w[\w-]*)="([^"]*)"') def parse_playlist(text): entries = [] pending = None for raw in text.splitlines(): line = raw.strip() if not line: continue if line.startswith('#EXTINF'): name = EXTINF_RE.search(line) attrs = dict(ATTR_RE.findall(line)) pending = { 'name': attrs.get('tvg-name') or (name.group(1).strip() if name else ''), 'group': attrs.get('group-title', '未分组'), } continue if line.startswith('#'): continue if line.startswith(('http://', 'https://', 'rtp://', 'rtsp://')): item = dict(pending or {}) item.setdefault('name', line.rstrip('/').split('/')[-1] or '未知频道') item.setdefault('group', '未分组') item['url'] = line entries.append(item) pending = None return entries def dedup_key(url): p = urlparse(url) return urlunparse((p.scheme, p.netloc, p.path, '', '', ''))

这段代码里有三个值得说的点。第一，元数据可能缺字段，所以每个字段都要有兜底，不然程序会在意料之外的地方崩。第二，除了 http/https，我还把 rtp 和 rtsp 前缀保留下来了，虽然这两类地址不能用 HTTP 方式检测，但它们有自己的处理方式，直接扔掉太浪费。第三，dedup_key只保留协议、主机和路径，丢掉查询串，这样带不同 token 的同一路径会被识别为重复项。

去重之后再按 URL 排序，输出一个干净列表。顺手统计一下分组分布，你会对这批源的结构有个直观认识，比如"央视有 80 条、卫视有 220 条、地方台有 400 条"，后续可以按需要只检测关心的分组，能省下大量时间。

3.3 并发探测核心代码逐段说明

核心探测逻辑用aiohttp写，控制在 80 行以内。关键在于超时配置要拆成三段，不能用一个总的超时糊过去。

import asyncio import time import aiohttp CONNECT_TIMEOUT = 3.0 # 建连超时 READ_TIMEOUT = 2.0 # 单次读取间隔超时 SAMPLE_SECONDS = 3.0 # 采样时长 async def probe(session, sem, entry): url = entry['url'] result = {**entry, 'ok': False, 'ttfb': None, 'bitrate': 0, 'ctype': '', 'status': 0, 'reason': ''} async with sem: start = time.perf_counter() try: timeout = aiohttp.ClientTimeout( connect=CONNECT_TIMEOUT, sock_read=READ_TIMEOUT, total=SAMPLE_SECONDS + CONNECT_TIMEOUT + 2, ) async with session.get(url, timeout=timeout, allow_redirects=True) as resp: result['status'] = resp.status result['ctype'] = resp.headers.get('Content-Type', '') total_bytes = 0 deadline = start + SAMPLE_SECONDS async for chunk in resp.content.iter_chunked(64 * 1024): if result['ttfb'] is None: result['ttfb'] = time.perf_counter() - start total_bytes += len(chunk) if time.perf_counter() >= deadline: break elapsed = max(time.perf_counter() - start, 0.001) result['bitrate'] = int(total_bytes * 8 / elapsed) if resp.status not in (200, 206): result['reason'] = f'HTTP {resp.status}' elif 'text/html' in result['ctype'].lower(): result['reason'] = '返回网页而非视频流' elif result['ttfb'] is None or result['ttfb'] > 2.5: result['reason'] = '首包超时' elif total_bytes < 65536: result['reason'] = '数据量不足' else: result['ok'] = True except asyncio.TimeoutError: result['reason'] = '超时' except aiohttp.ClientError as e: result['reason'] = f'连接错误 {type(e).__name__}' except Exception as e: result['reason'] = f'未知错误 {type(e).__name__}' return result async def run_all(entries, concurrency=150): sem = asyncio.Semaphore(concurrency) connector = aiohttp.TCPConnector( limit=concurrency, limit_per_host=8, ttl_dns_cache=300) async with aiohttp.ClientSession(connector=connector) as session: tasks = [probe(session, sem, e) for e in entries] return await asyncio.gather(*tasks)

这份代码有三个地方是踩过坑才改出来的。

limit_per_host=8这一行非常关键。很多直播源集中托管在少数几个域名下，如果不加单主机限制，150 个并发全砸到同一个域名，对方服务器会直接把你的连接拒掉或者限速，检测结果会大面积误判为不可用。限制到 8 之后，同一批次里那些同域的源会被排队处理，结论反而更真实。

TTFB 的测量位置也有讲究。我是在第一个数据块到达时才记录，而不是等响应头。原因是有些服务器会立刻返回响应头，然后隔两秒才开始发数据，如果按响应头算，就会把这种慢源误判成快源。

ttl_dns_cache=300是为了省 DNS 解析时间。一批一千条源里，域名可能只有几十个，缓存之后能省掉大量重复解析，整体速度提升相当明显。

3.4 用 ffprobe 补全分辨率与编码信息

初筛通过的源，进第二道工序。ffprobe的命令行参数我调过很多次，下面这版是兼顾速度和信息完整度的版本：

ffprobe -hide_banner -v error \ -analyzeduration 1000000 -probesize 500000 \ -select_streams v:0 \ -show_entries stream=codec_name,width,height,avg_frame_rate,bit_rate \ -of json \ -rw_timeout 4000000 \ "http://example.com/live/channel.m3u8"

参数含义逐个说清楚。-analyzeduration和-probesize控制探测深度，默认值偏保守，探测一个流可能要十几秒；把它们压到 1 秒和 500 KB 之后，绝大多数流在一两秒内就能给出结论。-select_streams v:0只取第一条视频流，避免音频流信息干扰。-rw_timeout是读写超时，单位微秒，四百万就是一秒，这个参数必须有，否则挂起的流会让整个进程卡死。

返回的是 JSON，解析之后能拿到width、height、codec_name、avg_frame_rate这些字段。看到 1920x1080 就是真高清，看到 640x360 就是标清，一眼分明。

import json, subprocess def probe_stream(url, timeout=6): cmd = ['ffprobe', '-hide_banner', '-v', 'error', '-analyzeduration', '1000000', '-probesize', '500000', '-select_streams', 'v:0', '-show_entries', 'stream=codec_name,width,height,avg_frame_rate', '-of', 'json', '-rw_timeout', '4000000', url] try: r = subprocess.run(cmd, capture_output=True, text=True, timeout=timeout) if r.returncode != 0: return {} info = json.loads(r.stdout) streams = info.get('streams') or [] return streams[0] if streams else {} except Exception: return {}

subprocess.run外面还包了一层timeout，这是双重保险。ffprobe 自己的超时参数偶尔会失效，进程级超时能兜住极端情况。这两层保护加上之后，我跑的几千次检测里再没出现过卡死。

3.5 结果落库、排序与定时调度

检测完的结果不能只打印到屏幕上，一定要落库，否则没法做趋势分析和多轮比对。用 SQLite 就够了，一个文件，零运维。

CREATE TABLE IF NOT EXISTS probe_result ( url TEXT NOT NULL, name TEXT, grp TEXT, ts INTEGER NOT NULL, ok INTEGER, ttfb REAL, bitrate INTEGER, width INTEGER, height INTEGER, codec TEXT, reason TEXT, PRIMARY KEY (url, ts) ); CREATE INDEX IF NOT EXISTS idx_url_ts ON probe_result(url, ts DESC);

表结构里ts是时间戳，和url一起做主键，这样同一地址在不同批次的检测结果会分开存，方便对比。索引建在(url, ts DESC)上，查询"某条源最近三次检测结果"时速度很快。

调度直接用系统自带的定时任务，不用额外引入调度框架。我的配置是每天凌晨跑一次全量，晚上七点半跑一次重点分组，因为那个时间点正好是晚高峰前，测出来的结果更有参考价值。

30 2 * * * cd /opt/iptv-checker && ./venv/bin/python main.py --all >> logs/daily.log 2>&1 30 19 * * * cd /opt/iptv-checker && ./venv/bin/python main.py --group 央视,卫视 >> logs/peak.log 2>&1

输出的时候，除了生成新的 m3u 文件，我还会同时生成一份精简版，只保留每个频道得分最高的三条地址，按主备顺序排列。播放器读这份精简版，换台和容错都更省心。

4. 本地网络侧的配合：组播、udpxy 与单线复用

4.1 udpxy 与 msd_lite：把组播变成 HTTP 单播

检测工具本身不解决"流从哪来"的问题。如果你家里有一路运营商给的组播信号，想让它被多个设备同时播放，中间需要一个转换环节，把组播转成普通的 HTTP 单播流。这就是 udpxy 之类的工具在做的事。

原理不难理解。组播是一份数据发给一组接收者，局域网上只要有设备加入了那个组播组，就能收到。问题是很多播放设备和软件不支持组播，无线网络对组播的支持也很差。转换工具做的事情就是自己加入组播组，把收到的数据复制一份，通过 HTTP 单播发给每一个请求它的客户端。客户端拿到的是一个形如http://192.168.1.10:4022/rtp/239.x.x.x:1234的地址，跟普通 HTTP 流没区别。

用 udpxy 和用 msd_lite 的区别，主要体现在资源占用上。udpxy 功能全、配置项多，但多路转发时 CPU 占用偏高；msd_lite 更轻量，同样路数下 CPU 占用大概只有前者的三分之一到一半，代价是配置项少一些。跑在性能有限的设备上，我一般优先选后者。

配置里最值得注意的参数是缓冲区大小。默认值在个别场景下会造成花屏，适当调大能明显改善。另外，转换服务本身不消耗流量，它只是把已经收到的数据复制分发，所以转发路数增加时，主要压力在网络和 CPU，而不是在接收端。

4.2 一路流占多少带宽，一台设备能带几台电视

这是问得最多的问题，我直接给一张换算表。前提说明：以下都是估算值，实际会受编码效率、网络质量和设备性能影响。

这张表里最关键的一列是"实际推荐"。为什么理论上千兆能带 100 路，实际只推荐 30 到 50 路？因为千兆网口的 940 Mbps 是理想值，实际有协议开销、有突发流量、有交换机背板的转发压力；更重要的瓶颈通常在 CPU，每复制一份流都要消耗一点处理能力，路数一多就压不住了。而且家里不可能只有 IPTV 在跑，还有下载、备份、视频会议在分带宽。

无线那一行尤其要打折扣。2.4GHz 频段本身可用带宽就小，再加上组播和单播混跑时的重传开销，实际能看的路数往往比表里更少。我的建议是，只要超过三台设备同时看，就走有线，或者至少走 5GHz 频段的独立 SSID。

4.3 单线复用与桥接改动的实操要点

很多人家里装修时只在一面墙留了一根网线，机顶盒和路由器都要接，于是就有了单线复用这个需求。核心原理是让一根网线同时承载两个逻辑网络：一个是上网用的网络，一个是 IPTV 用的网络，靠 VLAN 标签把它们区分开。

实现方式有两种。一种是路由器支持 IPTV 功能，可以在管理界面里指定某个 LAN 口走 IPTV 通道，由路由器自己打标签。另一种是中间加一台支持 802.1Q 的交换机，两端都配置成 trunk 口，一侧接光猫、一侧接墙内网线，到房间那头再用另一台交换机解标签，分别接机顶盒和路由器。

配置要点有三条。第一，两个网络的 VLAN ID 必须两侧一致，各地运营商用的编号不一样，这个必须以本地实际配置为准，不能照搬网上的数字。第二，网吧和 IPTV 的 VLAN 不能都打成 untagged 接同一个口，否则会被识别成同一个网络，直接冲突。第三，trunk 口上的 PVID 要设置正确，设错了会出现"IPTV 能看但上网断了"或者反过来的情况。

至于光猫改桥接之后 IPTV 还能不能用，答案是通常可以，但要看具体接法。IPTV 业务的 VLAN 在二层是透传的，和光猫是不是负责拨号没有直接关系。如果原来是机顶盒接光猫的 IPTV 专用口，改成桥接加单线复用之后，就得把那个口的 VLAN 标签带到新的链路上，机顶盒才能认出自己该加入哪个组播组。改之前建议先拍照记录原始配置，改完不通能马上回退。

4.4 NAS 部署：飞牛与群晖上的容器化选择

检测脚本和转换服务都适合放在 NAS 上跑，因为 NAS 常年开机、网络稳定、有足够的存储保存历史数据。现在主流的家用 NAS 系统对容器支持都不错，部署过程大同小异。

用容器部署的好处是环境隔离干净，不用在宿主机上装一堆依赖，升级和迁移也方便。写一个 compose 文件，把检测脚本和转换服务都定义进去，用同一个自定义网络，剩下的交给系统管理。几个建议：把配置文件和历史数据库挂载到宿主机目录上，这样容器重建数据不丢；给容器设置重启策略，设备和系统重启后服务能自动起来；注意网络模式的选择，组播转发需要能看到局域网的组播流量，用桥接网络时通常会失败，这种情况需要把容器切到主机网络模式。

资源占用方面，检测脚本在检测时段会短暂吃一些 CPU，跑完就回落，日常几乎无感。转换服务在转发多路时的 CPU 占用是持续性的，性能较弱的 NAS 建议控制同时转发的路数，或者干脆只在需要时启动。硬盘方面，如果历史数据保留超过半年，SQLite 文件会涨到几百 MB，定期清理旧记录就能控制住。

5. 常见问题与排查速查

5.1 检测全绿却放不出来：五个高频原因

这是最让人抓狂的情况，检测报告一片绿，实际播放全是黑屏。按我遇到过的频率排序，通常是下面这五个原因。

第一个是分辨率探测拿到了错误结论。有些源在开头几秒会推送一段占位画面，分辨率很低，ffprobe如果只分析前 500 KB，拿到的就是这段占位画面的参数。解决办法是加大probesize或者指定跳过前几秒再分析。

第二个是并发目标被限速。同一批源里如果大量条目指向同一个域名，并发请求会把对方触发限速机制，返回一个内容不完整的响应。现象是检测时数据量看着够，但播放器一解码就报错。把单主机并发压到个位数基本可以避免。

第三个是播放器兼容性问题。检测用的是通用协议解析，播放器可能有自己的格式偏好，比如只接受某几种封装格式，或者对 HLS 分片长度有要求。换一个播放器交叉验证是最快的定位方法。

第四个是本地路由问题。有些源走的是特定网络出口，你的设备如果被策略路由分流到了另一个出口，就会连不上。这种情况下检测脚本和播放器如果在同一台设备上，结论应该一致；如果检测在 NAS 上、播放在手机上，就可能出现差异。排查方法很简单，在出问题的那台设备上重新跑一次检测。

第五个是频道本身的分片鉴权。部分源在拉取具体分片时会附带额外的校验参数，播放列表能拿到，但分片请求会被拒。这种源在检测阶段表现为"能连上但数据量不足"，看到这个原因标记就要多留个心眼。

5.2 结果每次都不一样：波动溯源

同一批源连测两次，结果对不上，这事我遇到过很多次。原因无非三类：服务器侧、线路侧、检测侧。

服务器侧最常见。热门源的并发用户数随时间剧烈变化，晚高峰时段的可用性会明显下降。判断方法是在不同时段各跑一次，看同一批源的成功率曲线，如果曲线和时段强相关，那就是服务器负载问题，不是你的检测有问题。

线路侧的问题通常来自本地网络。家里的下载任务在跑，或者无线信号在波动，都会影响结论。把检测设备改成有线连接，并且确保检测时段没有大流量任务，能排除大部分干扰。

检测侧的问题主要出在超时阈值上。阈值卡得太紧，网络稍微抖一下就被判超时；卡得太松，慢源会被误判为好源。我的经验是阈值不要写死，而是根据你自己的网络基线来定。做法是先测一批已知可靠的源，记录它们的 TTFB 分布，取 95 分位数作为阈值参考，这样定出来的数字才贴合实际。

5.3 报错信息与处理方式对照表

这张表我贴在自己的项目 README 里，出问题先查表，能解决八成以上的故障。

6. 一些踩坑之后才明白的细节

6.1 检测时间点比检测算法更重要

脚本写得再漂亮，如果在错误的时间跑，结论一样没有参考价值。我最初的版本是凌晨两点跑，因为那时候网络空闲、速度快。结果生成的播放列表在晚上八点用起来，一半的源都不能看。

后来我把主要检测任务挪到了晚高峰前，也就是晚上七点半左右。这个时间点服务器已经开始承压，但还没到最拥挤的时候，测出来的结论更接近真实观看体验。同时保留了凌晨的全量检测，用来发现新增的可用源。两套数据分开存，用的时候按场景选。

还有一个细节：不要只测一轮就下结论。同一批源在同一时段连测三轮，间隔一分钟，只有三轮都通过或者通过率高的才进入优质列表。这个改动看起来简单，实际对可用性的提升非常明显。

6.2 多源备份与自动切换的价值

前面提过每个频道保留三条来源，按主备排列。这个设计的价值在实际使用中才体现得出来：主源在晚高峰被挤爆时，播放器会自动切到备源，用户几乎察觉不到。如果没有备份，表现就是突然黑屏几秒钟再恢复，体验差很多。

实现上，就是在生成 m3u 的时候，把同一频道的多个来源按顺序写进去，并给它们相同的频道标识。支持多源切换的播放器会自动处理。检测脚本要做的，就是在排序时保证同一频道的多个来源分散在不同域名下，这样才不会出现"一个域名挂了，三条源全挂"的情况。

顺带说一句题外话。最近搜 IPTV 相关内容时，经常会看到一些完全不相关的工具名混在结果里，比如某些安卓完整性校验工具。它们跟直播源检测没有任何关系，纯属关键词污染，别被带偏。认准自己要解决的问题，比追着热搜词跑有用得多。

最后分享一个我用了很久的小习惯：把每次检测的优质源列表，按日期存档，只保留最近三十天的版本。这样既能看到某个频道来源的演变规律，又不会让存储无限膨胀。有几次某个频道彻底失效，我翻出两周前的存档，发现那时候还有一条备用地址，重新测一下又活了，省去了重新全网搜源的功夫。