多线程爬虫进度可视化需解决线程安全、实时刷新、状态聚合三问题；应使用线程安全共享计数器（如tqdm+threadpoolexecutor），动态url则用双指标模式配合lock保护变量。
多线程爬虫的进度可视化不能靠 print 打印或简单计数器——它必须解决线程安全、实时刷新、状态聚合三个核心问题。
为什么 threading.local() 不适合做全局进度统计
很多人试图用 threading.local() 记录每个线程抓取数量，再汇总显示。但这样无法反映整体完成率：各线程速度不均，本地变量无法跨线程读取，print 频繁刷屏还会拖慢网络请求。
- 真正需要的是一个线程安全的共享计数器，比如
threading.Semaphore或queue.Queue传递完成事件 - 更推荐用
concurrent.futures.ThreadPoolExecutor的as_completed()+ 回调函数更新总进度 - 避免在工作线程里直接操作终端（如
sys.stdout.write），容易因缓冲/竞态导致乱码或丢帧
用 tqdm 配合 ThreadPoolExecutor 实现可靠进度条
tqdm 默认不支持多线程异步更新，但可通过手动控制 update() 和锁机制实现。关键点是把任务总数传入 tqdm，再让每个完成的任务触发一次 pbar.update(1)。
- 初始化时用
pbar = tqdm(total=n_urls, desc="Fetching")，n_urls必须是已知总数（不能边发现边加） - 每个线程完成请求后，调用
pbar.update(1)—— 这个操作本身是线程安全的 - 不要在
with tqdm(...) as pbar:块内启动线程池，否则主线程退出时进度条可能提前关闭 - 示例片段：
pbar = tqdm(total=len(urls), desc="Crawling")<br>def fetch_and_update(url):<br> res = requests.get(url, timeout=5)<br> pbar.update(1)<br> return res<br>with ThreadPoolExecutor(max_workers=10) as executor:<br> list(executor.map(fetch_and_update, urls))
如何处理动态 URL 列表（边爬边发现新链接）
当目标网站结构复杂、URL 需要递归发现时，固定总数不可行，此时应改用“已完成 / 已发现”双指标模式，配合 threading.Lock 保护共享变量。
- 定义两个受锁保护的变量：
total_discovered（已发现链接数）、completed（已成功抓取数） - 每次发现新 URL，先
lock.acquire(); total_discovered += 1; lock.release() - 每完成一次请求，同样更新
completed，并调用pbar.set_postfix(completed=completed, discovered=total_discovered) - 避免在锁内做耗时操作（如发请求），只做计数；也不要在锁内调用
pbar.update()，它内部已有锁 - 注意：
pbar.refresh()可强制重绘，但频繁调用会降低性能，建议每秒最多刷新 2–3 次
真正的难点不在画进度条，而在判断“什么才算完成”——是所有初始 URL 抓完？还是所有发现的 URL 都处理完毕？后者需额外维护待处理队列和终止条件，稍有疏漏就会卡死或漏数据。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
