IPTV直播源管理系统：从采集检测到分类分发的全流程实践

1. 从一堆乱麻到井然有序：IPTV直播源管理到底在管什么

手里攒了几十个m3u文件，每个文件里躺着几百条频道地址，打开播放器能刷出来一半，另一半要么卡成幻灯片，要么直接黑屏。更头疼的是，今天能看的频道明天就失效了，你得挨个去试，试完还得手动替换。这套流程如果纯靠人肉维护，不出三天就得崩溃。

IPTV直播源管理系统要解决的就是这个问题。它的核心任务可以拆成三件事：把散落在各处的m3u源统一收拢进来，对每一条频道地址做可用性检测和分类，把筛选后的结果以标准格式分发给不同的播放端。听起来简单，但真要做到“全端稳定播放”，中间涉及的坑远比想象中多。

这套东西适合谁用？如果你家里有智能电视、手机、电脑多个设备都想看直播，又不想每个设备单独维护一份频道列表，那这套系统就是为你准备的。如果你只是偶尔在电脑上用播放器看两个频道，那手动维护一个m3u文件就够了，没必要上这套工程化的方案。另外，做这套系统需要你有一点基本的动手能力，至少能看懂配置文件、会跑几条命令行指令，不需要你写代码，但需要你理解数据是怎么流动的。

我前后折腾过好几轮，从最开始用Excel表格手动记录频道地址，到后来写脚本自动检测，再到最后搭出一套完整的采集、检测、分类、分发流水线，踩过的坑基本覆盖了所有常见问题。下面就把这套东西拆开来讲，从整体设计思路到每个环节的具体操作，再到遇到问题怎么排查，尽量说透。

2. 整体架构设计：为什么这么搭，不那么搭

2.1 核心模块的拆分逻辑

一套完整的直播源管理系统，不管用什么技术栈实现，本质上都包含四个核心模块：采集层、检测层、分类层、分发层。这四个模块的职责边界必须清晰，否则后期维护会非常痛苦。

采集层的任务很简单：从各种渠道获取m3u文件或频道地址列表。渠道可能包括公开的源分享、自己抓取的地址、朋友发给你的文件等等。采集层不关心地址能不能用，它只负责把原始数据拿回来，存到一个统一的“原始池”里。这个池子可以是一个文本文件，也可以是一个数据库表，甚至就是一个文件夹里的一堆m3u文件。

检测层是整套系统里最耗资源的部分。它需要逐条去请求每个频道地址，判断这个地址是否还能正常返回视频流。检测的方式有很多种，最简单的就是发一个HTTP请求看返回状态码，但这种方法误判率很高，因为很多地址返回200但实际拉不到流。更可靠的方式是尝试拉取一小段流数据，看能不能解出视频帧。检测层还需要记录每个地址的响应时间、码率、分辨率等信息，这些数据在后续分类时会派上大用场。

分类层根据检测结果对频道进行分组。分组的维度可以很灵活：按响应速度分（快、中、慢），按画质分（高清、标清、流畅），按频道类型分（央视、卫视、地方、其他），按稳定性分（长期稳定、偶尔可用、不稳定）。分类的目的是让分发层能够针对不同播放端的特点，输出不同的频道列表。比如电视端优先给高清稳定的源，手机端可以接受码率低一些但连接速度快的源。

分发层负责把分类后的频道列表以标准m3u格式输出，并且要适配不同播放端的特殊需求。有些播放器要求m3u里必须包含tvg-id和tvg-logo字段，有些播放器对频道名称的编码有要求，还有些播放器需要额外的EPG信息。分发层要能根据目标播放端的类型，生成对应的m3u文件。

2.2 为什么选择“检测后分类”而不是“分类后检测”

这是一个很容易搞反的顺序。我一开始也是先按频道名称分类，然后对每一类分别检测。后来发现这样做有两个大问题：第一，同一个频道往往有多个备用地址，如果先分类再检测，你得在每个类别里重复检测逻辑；第二，分类的依据应该是检测结果，而不是频道名称，因为同一个频道名称下的不同地址，质量可能天差地别。

正确的做法是先把所有地址扔进检测层，拿到每一条地址的完整质量数据，然后再根据这些数据做分类。这样分类的粒度可以做到“地址级”而不是“频道级”，同一个频道如果有三个地址，检测后可能一个分到高清组，一个分到备用组，一个直接淘汰。这种精细度是“先分类后检测”做不到的。

2.3 数据流转的完整链路

整个系统的数据流转可以这样描述：采集层从多个来源获取原始m3u文件，解析后提取出频道名称和地址，存入原始地址池。检测层从原始池中逐条读取地址，发起检测请求，将检测结果（可用性、响应时间、码率、分辨率等）写回数据库。分类层根据检测结果中的各项指标，给每条地址打上标签，比如“高清-快速-稳定”、“标清-慢速-不稳定”等。分发层根据预设的规则，从数据库中筛选出符合条件的地址，按频道名称去重后生成m3u文件，输出到指定的目录或接口。

这个链路里有一个关键设计：原始地址池和检测结果表是分开的。原始池只存地址本身和来源信息，检测结果表存每次检测的详细数据。这样做的好处是，你可以对同一条地址做多次检测，记录它的历史表现，从而判断它是“一直稳定”还是“偶尔可用”。如果只存最新一次检测结果，就丢失了历史信息，分类时只能看当下状态，无法评估长期稳定性。

2.4 技术选型的考量

实现这套系统可以用各种语言和工具组合。如果只是自己用，Python加SQLite是最省事的选择，脚本跑起来快，数据库不用额外部署。如果需要多人协作或者频道量特别大（超过几万条），可以考虑用Node.js加PostgreSQL，或者Go加MySQL。但说实话，对于个人或小团队使用，Python加SQLite完全够用，没必要过度设计。

检测环节有一个关键选择：是用同步请求还是异步请求。同步请求写起来简单，但速度慢，检测几千条地址可能要跑几个小时。异步请求（比如用aiohttp或httpx的异步模式）可以把检测时间压缩到几分钟，但代码复杂度会上升。我的建议是，如果地址数量在5000条以内，用异步请求，并发数控制在50到100之间，再高容易触发目标服务器的限流。如果超过5000条，可以考虑分批检测，或者用多进程加异步的混合模式。

存储方面，SQLite对于个人使用场景完全足够，单表存几十万条记录毫无压力。唯一需要注意的是，SQLite的并发写入能力较弱，如果检测层是多进程同时写数据库，可能会遇到锁表问题。解决办法是让检测层把结果先写到临时文件，再由一个单独的进程批量导入数据库。

3. 核心细节拆解：每个环节的实操要点

3.1 m3u文件的解析与标准化

m3u文件看起来简单，但实际拿到的文件格式五花八门。标准格式是每两行一组，第一行以#EXTINF:开头，包含频道时长、属性标签和频道名称，第二行是频道地址。但实际遇到的变种包括：属性标签的顺序不固定、频道名称里包含逗号、地址行前面有多余空格、文件编码不是UTF-8等等。

解析时首先要做的是统一编码。用Python的chardet库检测文件编码，然后统一转成UTF-8。这一步不做的话，后面处理中文频道名称时会遇到各种乱码问题。其次是处理属性标签的顺序问题，不要假设tvg-id一定在tvg-name前面，正确的做法是用正则表达式提取所有key="value"形式的属性，存到一个字典里，然后按需取用。

频道名称的提取也有讲究。#EXTINF:行最后一个逗号之后的内容才是频道名称，但有些文件里频道名称本身包含逗号，这时候就不能简单地按逗号分割。更可靠的方式是用正则匹配#EXTINF:.*?,(.*)$，取最后一个逗号之后的部分。如果频道名称里确实有逗号，那也只能接受这个结果，因为m3u格式本身没有对这种情况做转义处理。

解析完成后，每条记录应该包含这些字段：频道名称、频道地址、tvg-id、tvg-name、tvg-logo、分组名称。如果原始文件里没有某些字段，就留空，不要自己编造。这些字段在后续分类和分发时都会用到。

3.2 地址检测的三种策略与选择依据

检测一条直播地址是否可用，有三种常见策略，各有优缺点。

第一种是HTTP状态码检测。直接发一个HEAD或GET请求，看返回状态码是不是200。这种方法速度最快，但误判率最高。很多直播地址返回200，但实际拉流时返回的是错误页面或者空内容。这种策略只适合做初步筛选，把明显失效的地址（返回404、403、500等）剔除掉。

第二种是流数据拉取检测。用ffprobe或类似工具尝试拉取地址的前几秒流数据，看能不能正常解出视频信息。这种方法的准确率很高，基本能反映实际播放效果，但速度慢，每条地址可能需要3到10秒。如果地址数量多，检测时间会很长。

第三种是混合检测。先用HTTP状态码快速筛一遍，把明显失效的剔除，剩下的再用流数据拉取做精确检测。这种策略兼顾了速度和准确率，是我目前采用的方式。具体做法是：第一轮用异步HTTP请求，并发100，超时设5秒，把返回非200的地址直接标记为失效。第二轮对剩下的地址用ffprobe逐个检测，超时设10秒，记录响应时间、码率、分辨率。两轮下来，准确率能到95%以上。

检测时的超时设置很关键。超时太短，很多正常但响应慢的地址会被误判为失效；超时太长，检测时间会拖得很久。我的经验值是：HTTP检测超时5秒，流检测超时10秒。如果某个地址在10秒内还没返回流数据，基本可以判定为不可用或极不稳定。

3.3 分类维度的设计与标签体系

分类的目的是让分发层能够快速筛选出适合特定播放端的地址。我设计的标签体系包含四个维度：画质、速度、稳定性、来源。

画质维度根据检测到的分辨率来划分：1080p及以上标为“高清”，720p标为“标清”，576p及以下标为“流畅”。如果检测不到分辨率信息，标为“未知”。

速度维度根据响应时间来划分：响应时间小于1秒标为“快速”，1到3秒标为“中速”，3秒以上标为“慢速”。

稳定性维度需要结合历史检测数据来判断。如果一条地址在最近7天的检测中，可用率超过90%，标为“稳定”；可用率在50%到90%之间，标为“一般”；低于50%，标为“不稳定”。对于新加入的地址，还没有历史数据，可以先标为“待观察”，等积累了几次检测记录后再调整。

来源维度记录地址是从哪个m3u文件或哪个渠道采集来的。这个维度在排查问题时很有用，如果某个来源的地址大面积失效，可以快速定位到源头。

这四个维度的标签组合起来，就能精确描述一条地址的质量。比如“高清-快速-稳定-来源A”就是一条优质地址，优先分发给电视端。“标清-中速-一般-来源B”可以分发给手机端作为备用。

3.4 分发层的适配策略

不同播放端对m3u文件的要求不一样，分发层需要做针对性适配。

电视端（比如Kodi、TiviMate）通常要求m3u文件包含完整的tvg-id和tvg-logo字段，否则频道列表里显示不出台标和节目单。分发层在生成电视端m3u时，要确保这两个字段不为空。如果原始数据里没有tvg-logo，可以留空，但tvg-id最好能补上，可以用频道名称的拼音或哈希值生成一个唯一ID。

手机端（比如VLC、MX Player）对m3u格式的要求比较宽松，有没有tvg-id都能播。但手机端更在意连接速度，所以分发层给手机端生成的列表应该优先包含“快速”标签的地址，画质可以适当降低。

电脑端（比如PotPlayer）对m3u的兼容性最好，基本什么格式都能播。但电脑端通常屏幕大，对画质要求高，所以分发层给电脑端生成的列表应该优先包含“高清”标签的地址。

分发层还需要考虑一个实际问题：同一个频道如果有多个可用地址，应该怎么处理。我的做法是，在m3u文件里为同一个频道名称保留最多三个地址，按质量排序，播放器如果第一个地址播不了，会自动尝试第二个。但要注意，不是所有播放器都支持这种“多地址备用”的写法，有些播放器只会读第一个地址。所以更稳妥的做法是，针对不同播放端生成不同的列表，电视端只放最优地址，手机端可以放两到三个备用地址。

3.5 定时任务的编排与执行频率

整套系统需要定时运行，才能保持频道列表的时效性。我设置的定时任务包括：采集任务每6小时跑一次，检测任务每12小时跑一次，分类和分发任务在检测完成后立即执行。

采集频率为什么是6小时？因为大部分公开源的更新频率大概就是几个小时一次，跑太勤没必要，跑太慢会错过新地址。检测频率为什么是12小时？因为直播地址的失效速度没有想象中那么快，大部分地址能存活几天甚至几周，12小时检测一次足够及时发现失效地址。如果发现某个来源的地址失效特别快，可以单独提高那个来源的检测频率。

定时任务的编排可以用crontab，也可以用Python的APScheduler库。crontab更简单，但不够灵活，比如你想在检测完成后自动触发分发，crontab就不太好实现。APScheduler可以在代码里定义任务依赖关系，检测任务完成后自动触发分发任务，更适合这套系统的需求。

4. 实操过程：从零搭一套可用的系统

4.1 环境准备与依赖安装

先准备一台常开的机器，可以是家里的旧电脑、树莓派或者云服务器。系统用Linux（Ubuntu或Debian都行），Windows也可以但命令行操作会麻烦一些。Python版本建议3.9以上，因为要用到一些异步特性。

需要安装的核心依赖包括：aiohttp用于异步HTTP检测，ffmpeg用于流数据拉取检测，sqlite3用于数据存储，apscheduler用于定时任务编排。安装命令如下：

sudo apt update sudo apt install -y ffmpeg python3-pip pip3 install aiohttp apscheduler chardet

ffmpeg的安装不能省，流检测环节完全依赖它。安装完成后用ffprobe -version验证一下，能输出版本信息就说明装好了。

4.2 数据库表结构设计

用SQLite建三张表：raw_sources存原始地址，check_results存检测结果，channel_tags存分类标签。

CREATE TABLE raw_sources ( id INTEGER PRIMARY KEY AUTOINCREMENT, channel_name TEXT NOT NULL, url TEXT NOT NULL, tvg_id TEXT, tvg_name TEXT, tvg_logo TEXT, group_name TEXT, source_file TEXT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE check_results ( id INTEGER PRIMARY KEY AUTOINCREMENT, source_id INTEGER NOT NULL, check_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP, http_status INTEGER, is_available INTEGER, response_time REAL, resolution TEXT, bitrate TEXT, error_msg TEXT, FOREIGN KEY (source_id) REFERENCES raw_sources(id) ); CREATE TABLE channel_tags ( id INTEGER PRIMARY KEY AUTOINCREMENT, source_id INTEGER NOT NULL, quality_tag TEXT, speed_tag TEXT, stability_tag TEXT, source_tag TEXT, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (source_id) REFERENCES raw_sources(id) );

raw_sources表里的url字段要加唯一索引，避免同一条地址被重复插入。check_results表会随着检测次数增加而快速增长，建议定期清理30天前的记录，或者只保留每条地址最近10次的检测结果。

4.3 采集脚本的编写要点

采集脚本的核心逻辑是：遍历指定目录下的所有m3u文件，解析出频道名称和地址，去重后插入raw_sources表。解析时要注意前面提到的编码问题和属性标签顺序问题。

import chardet import re import sqlite3 import os def parse_m3u(filepath): with open(filepath, 'rb') as f: raw = f.read() encoding = chardet.detect(raw)['encoding'] or 'utf-8' content = raw.decode(encoding, errors='ignore') channels = [] lines = content.splitlines() i = 0 while i < len(lines): line = lines[i].strip() if line.startswith('#EXTINF:'): match = re.match(r'#EXTINF:.*?,(.*)$', line) channel_name = match.group(1).strip() if match else '未知频道' attrs = dict(re.findall(r'(\S+?)="(.*?)"', line)) if i + 1 < len(lines): url = lines[i + 1].strip() if url and not url.startswith('#'): channels.append({ 'channel_name': channel_name, 'url': url, 'tvg_id': attrs.get('tvg-id', ''), 'tvg_name': attrs.get('tvg-name', ''), 'tvg_logo': attrs.get('tvg-logo', ''), 'group_name': attrs.get('group-title', ''), 'source_file': os.path.basename(filepath) }) i += 2 else: i += 1 return channels

这段代码里有一个细节：attrs的提取用了re.findall，能正确处理属性顺序不固定的情况。channel_name的提取用了.*?,(.*)$，取最后一个逗号之后的内容，能处理频道名称里包含逗号的情况。

4.4 检测脚本的异步实现

检测脚本分两轮：第一轮异步HTTP检测，第二轮ffprobe流检测。第一轮用aiohttp，并发数设100，超时5秒。

import aiohttp import asyncio async def check_http(session, url, timeout=5): try: async with session.head(url, timeout=timeout, allow_redirects=True) as resp: return resp.status except Exception as e: return None async def batch_check_http(urls, concurrency=100): semaphore = asyncio.Semaphore(concurrency) async def check_with_sem(session, url): async with semaphore: return await check_http(session, url) async with aiohttp.ClientSession() as session: tasks = [check_with_sem(session, url) for url in urls] return await asyncio.gather(*tasks)

第二轮用ffprobe，通过subprocess调用，超时10秒。ffprobe的输出里包含分辨率、码率等信息，用正则提取出来。

import subprocess import re def check_stream(url, timeout=10): cmd = [ 'ffprobe', '-v', 'quiet', '-print_format', 'json', '-show_streams', '-timeout', str(timeout * 1000000), url ] try: result = subprocess.run(cmd, capture_output=True, text=True, timeout=timeout + 2) if result.returncode != 0: return {'available': False, 'error': result.stderr[:200]} import json info = json.loads(result.stdout) video_stream = None for stream in info.get('streams', []): if stream.get('codec_type') == 'video': video_stream = stream break if not video_stream: return {'available': False, 'error': '无视频流'} width = video_stream.get('width', 0) height = video_stream.get('height', 0) bitrate = video_stream.get('bit_rate', '0') return { 'available': True, 'resolution': f'{width}x{height}', 'bitrate': bitrate, 'error': None } except subprocess.TimeoutExpired: return {'available': False, 'error': '超时'} except Exception as e: return {'available': False, 'error': str(e)[:200]}

这里有一个实操心得：ffprobe的-timeout参数单位是微秒，所以timeout * 1000000。另外，ffprobe在拉流失败时返回的错误信息可能很长，截取前200个字符就够了，存到数据库里方便排查。

4.5 分类与分发的实现

分类脚本从check_results表里读取每条地址的最新检测结果，结合历史可用率，生成标签写入channel_tags表。历史可用率的计算方式是：统计最近7天内该地址的检测记录，可用次数除以总检测次数。

def calculate_stability(source_id, conn): cursor = conn.execute( '''SELECT COUNT(*) as total, SUM(is_available) as available FROM check_results WHERE source_id = ? AND check_time > datetime('now', '-7 days')''', (source_id,) ) row = cursor.fetchone() if row[0] == 0: return '待观察' rate = row[1] / row[0] if rate >= 0.9: return '稳定' elif rate >= 0.5: return '一般' else: return '不稳定'

分发脚本根据目标播放端的类型，从channel_tags表里筛选符合条件的地址，按频道名称去重后生成m3u文件。电视端的筛选条件是quality_tag = '高清' AND stability_tag = '稳定'，手机端的筛选条件是speed_tag = '快速'，电脑端的筛选条件是quality_tag = '高清'。

生成m3u文件时，要注意频道名称的编码。如果播放器要求UTF-8，就用UTF-8写入；如果要求GBK，就转成GBK。大部分现代播放器都支持UTF-8，所以默认用UTF-8就行。

4.6 定时任务的配置

用APScheduler配置定时任务，采集任务每6小时一次，检测任务每12小时一次，分发任务在检测完成后触发。

from apscheduler.schedulers.blocking import BlockingScheduler scheduler = BlockingScheduler() scheduler.add_job(collect_task, 'interval', hours=6, id='collect') scheduler.add_job(check_task, 'interval', hours=12, id='check') scheduler.add_job(distribute_task, 'cron', hour='*/12', minute=30, id='distribute') scheduler.start()

分发任务的时间设在检测任务之后30分钟，给检测留出足够的执行时间。如果检测任务跑得比较久，可以适当延长这个间隔。

5. 常见问题与排查技巧实录

5.1 检测结果与实际播放效果不一致

这是最常见的问题。检测时显示可用，但实际播放时卡顿或黑屏。原因通常有三个：一是检测时只拉了前几秒流，实际播放到后面才出问题；二是检测时的网络环境和播放时的网络环境不同；三是播放器对某些编码格式支持不好。

解决办法：检测时尽量多拉几秒流，比如拉10秒而不是3秒。如果条件允许，检测机和播放机在同一个网络环境下。对于编码格式问题，可以在检测时记录视频编码格式，分发时避开那些冷门编码。

5.2 频道名称重复导致去重错误

同一个频道可能有多个不同名称的写法，比如“CCTV-1”和“CCTV1”和“央视一套”。如果按名称去重，这三个会被当成不同频道，导致列表里出现重复内容。

解决办法：建立一个频道名称映射表，把常见的别名映射到标准名称。这个映射表可以手动维护，也可以用模糊匹配自动生成。模糊匹配的规则可以用编辑距离，相似度超过80%的就认为是同一个频道。

5.3 数据库写入冲突

如果检测脚本是多进程运行，多个进程同时写SQLite会报“database is locked”错误。解决办法是让检测进程把结果写到临时文件，再由一个单独的进程批量导入数据库。或者改用PostgreSQL，但那样部署会复杂一些。

5.4 ffprobe检测速度太慢

ffprobe每条地址要花3到10秒，如果地址有几千条，检测一轮要几个小时。解决办法是提高并发数，但ffprobe本身是同步的，不能直接用异步。可以用多进程加异步的方式，比如开10个进程，每个进程内用异步HTTP做第一轮筛选，剩下的再用ffprobe检测。或者用asyncio.create_subprocess_exec把ffprobe也异步化，但代码会复杂一些。

5.5 分发出去的m3u文件播放器不识别

最常见的原因是文件编码不对，或者m3u头部的#EXTM3U标签缺失。有些播放器还要求文件以UTF-8 BOM开头。解决办法是生成m3u时确保第一行是#EXTM3U，编码用UTF-8，如果播放器要求BOM就加上BOM。

5.6 常见问题速查表

5.7 几个踩坑后总结的实操心得

第一个心得：不要追求100%的可用率。直播源本身就不稳定，能做到80%的可用率已经很好用了。把精力花在提高检测准确率和分类精细度上，比追求完美可用率更实际。

第二个心得：保留原始数据。检测结果和分类标签都是基于原始地址生成的，如果原始地址丢了，这些数据就没意义了。所以raw_sources表里的数据不要轻易删除，即使地址已经失效，也保留着，万一以后又活了呢。

第三个心得：分发列表不要太大。一个m3u文件里放几百个频道就够了，放太多播放器加载会慢，而且用户也看不过来。按分组输出多个m3u文件，比如“央视.m3u”、“卫视.m3u”、“地方.m3u”，用户按需加载。

第四个心得：定期清理检测记录。check_results表增长很快，如果不清理，几个月后数据库会变得很大，查询速度也会下降。建议只保留最近30天的记录，或者每条地址只保留最近10次检测结果。

6. 系统扩展与长期维护的思路

6.1 增加EPG节目单支持

如果播放器支持EPG（电子节目单），可以在分发层增加EPG文件的生成。EPG数据可以从公开的XMLTV格式节目单获取，解析后按频道ID匹配，生成对应的XML文件。分发时把m3u和XML一起输出，播放器就能显示节目单了。

EPG的匹配关键是tvg-id要一致。如果原始m3u里没有tvg-id，需要根据频道名称生成一个稳定的ID，并且确保EPG文件里也用同样的ID。这个ID生成规则一旦确定就不要改，否则匹配会失效。

6.2 多用户分发与权限控制

如果这套系统要给多个人用，可以增加一个简单的Web接口，每个用户有自己的频道列表配置。用户登录后可以看到自己订阅的频道分组，系统根据用户的配置生成个性化的m3u文件。权限控制可以用最简单的token机制，每个用户一个token，访问接口时带上token即可。

Web接口可以用Flask或FastAPI快速搭建，不需要太复杂的前端，一个简单的页面展示频道列表和下载链接就够了。如果不想搭Web，也可以直接把生成的m3u文件放到一个共享目录里，每个用户自己取。

6.3 自动化更新与告警

系统跑久了，难免会遇到问题，比如某个来源突然失效、检测任务卡死、磁盘空间不足等。可以增加一个简单的告警机制，比如检测任务连续失败3次就发一封邮件通知，或者用Webhook推送到某个消息平台。

告警的阈值要设置合理，太敏感会天天报警，太迟钝会错过问题。我的经验是：检测任务失败率超过50%时告警，单个来源可用率低于20%时告警，磁盘使用率超过90%时告警。这几个阈值在实际使用中比较平衡。

6.4 性能优化的几个方向

如果频道数量增长到几万条，系统性能会成为瓶颈。优化方向有几个：一是把SQLite换成PostgreSQL，提升并发读写能力；二是把检测任务分布到多台机器上，用消息队列协调；三是把ffprobe检测换成更轻量的流探测工具，比如用curl拉取一小段数据然后判断内容类型。

不过对于大多数个人使用场景，几千条地址用Python加SQLite完全够用，没必要过早优化。等真正遇到性能问题了再动手也不迟。

6.5 长期维护的节奏

这套系统搭好之后，日常维护的工作量其实很小。每天花几分钟看一下检测任务的日志，确认没有大面积失效。每周花十几分钟检查一下分类标签的分布，看看是不是有新的优质来源需要加入。每个月花半小时清理一下数据库，删掉过期的检测记录。

真正需要花时间的是发现新的优质来源。公开的源质量参差不齐，需要不断筛选和测试。可以建一个“候选池”，把新发现的来源先放进去观察一段时间，稳定后再正式加入主库。这个观察期建议至少一周，太短了判断不准。

我在实际使用中发现，一套调好的系统跑上几个月之后，频道列表的可用率能稳定在85%以上，日常观看基本不会遇到问题。偶尔遇到某个频道失效，等下一次检测周期自动更新就好了，不需要手动干预。这种“搭好之后基本不用管”的状态，才是这套系统最大的价值。