爬虫脚本必须独立于web框架运行，封装为无上下文依赖的模块，通过celery调度、分层反爬、严格校验去重及快照留存保障稳定可靠。
爬虫脚本必须独立于Web框架运行
直接在Django或Flask的视图里调用requests.get()发起爬取，会导致请求阻塞主线程，页面超时、后台任务卡死。真实场景中，爬虫逻辑必须剥离为可单独执行的Python模块，不依赖Web上下文。
实操建议：
- 把爬虫逻辑封装成函数，如
fetch_product_data()，参数只接收URL或ID，返回结构化字典或None - 避免在爬虫代码里导入
django.conf.settings或flask.current_app——这些会引发循环依赖或RuntimeError - 使用
if __name__ == "__main__":包裹测试入口，确保能直接python spider.py运行 - 日志统一写入文件（如
logs/spider.log），而非print()，方便后台任务追踪失败原因
用Celery调度比APScheduler更可靠
APScheduler在多进程部署（如gunicorn启动多个worker）时，每个进程都会启动一套定时器，导致同一任务重复执行。Celery通过消息队列（如Redis）实现任务分发，天然支持分布式和失败重试。
实操建议：
- Celery配置中必须设置
task_serializer='json'，避免pickle引发的安全与兼容问题 - 爬虫任务函数加装饰器
@app.task(bind=True, max_retries=3)，并在异常时调用self.retry(countdown=60) - 不要在任务里直接处理HTML解析——把
BeautifulSoup或lxml解析逻辑放在爬虫函数内部，Celery任务只负责触发和捕获结果 - 限制并发：在Celery配置中设
worker_concurrency = 2，防止目标网站封IP
反爬策略绕过要分层处理
单纯换User-Agent撑不过10分钟。真实站点通常组合检测：请求频率、Cookie状态、JavaScript渲染、Referer头、甚至TLS指纹。必须按需分层应对。
实操建议：
- 基础层：用
requests.Session()复用连接，手动设置headers中User-Agent、Accept-Language、Referer - 进阶层：对需要登录或动态Token的站点，先用
selenium或playwright模拟登录，导出Cookies供requests复用 - 高阶层：识别是否为JS渲染页（检查响应中是否有大量
script且关键数据为空），改用playwright.sync_api.sync_playwright().start()启动无头浏览器 - 别硬刚验证码——遇到
403或cloudflare拦截页，立即记录URL并退出，交由人工审核或第三方打码平台
数据落库前必须做字段校验和去重
爬虫返回的数据常含空值、乱码、重复条目。直接Model.objects.create()会导致数据库报错或脏数据堆积，后续查不出来还找不到源头。
实操建议：
- 定义校验函数
validate_item(item: dict) -> bool，检查必填字段（如item.get("title")非空、item.get("price")为数字） - 用
hashlib.md5(json.dumps(item, sort_keys=True).encode()).hexdigest()生成唯一签名，存入缓存（如Redis）做24小时去重 - 入库用
Model.objects.update_or_create(defaults=..., **lookup_fields)，避免主键冲突或覆盖旧数据 - 所有字符串字段入库前调用
.strip().replace("\u00a0", " ")，清除不间断空格等隐形字符
最麻烦的不是写爬虫，而是目标网站某天突然加了前端加密字段或改了API路径——得留好last_modified时间戳和原始HTML快照，不然问题回溯全靠猜。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
