面试题手册

Scrapy 上线不要只把代码丢到服务器然后执行 scrapy crawl。更稳的做法是先固定依赖、配置、日志和启动入口，再交给 Scrapyd、systemd、Supervisor 或 Docker 管理。小项目用 Scrapyd 发布和调度很快，团队项目更适合 Docker 加 CI/CD；如果任务很多，还要补上队列、监控、告警和回滚。部署的重点不是工具越多越好，而是出问题时能定位、能停止、能恢复。上线前先固定运行环境先确认项目能用同一套命令复现运行结果。依赖写进 requirements.txt 或 pyproject.toml，生产参数放环境变量，不要在服务器上临时安装和手改配置。发布前至少跑一次小范围任务，检查请求、解析、入库和日志路径。pip install scrapyd scrapyd-clientscrapyd-deploy default -p news_crawlercurl http://127.0.0.1:6800/schedule.json -d project=news_crawler -d spider=articleScrapyd 适合轻量管理Scrapyd 能发布项目、启动爬虫、查看任务、取消任务和读取日志，适合单机或少量机器。它的边界也明显：它不是完整调度平台，不负责复杂依赖、资源隔离和跨机器统一排队。生产环境里建议只放内网，不要把 6800 端口暴露到公网。任务参数可以通过 API 传入，但 Token、Cookie、数据库密码不要明文塞进调度参数。Docker 解决环境漂移如果经常出现“本地能跑，服务器不能跑”，Docker 更合适。镜像里固定 Python、系统库、项目依赖和启动命令，服务器只负责拉镜像并注入环境变量。代价是镜像构建、日志采集和资源限制要额外配置，特别是用 Playwright、Selenium、lxml 时要提前处理系统依赖。FROM python:3.11-slimWORKDIR /appCOPY requirements.txt .RUN pip install --no-cache-dir -r requirements.txtCOPY . .CMD ["scrapy", "crawl", "article", "-s", "LOG_LEVEL=INFO"]进程管理和回滚不能省裸机部署可以用 systemd 或 Supervisor。它们能守护进程，但不要无脑自动重启；如果目标站返回大量 403，重启只会制造更多封禁和脏日志。每次发布保留上一个 egg、镜像 tag 或 release 目录，一次只改一个变量，比如只改代码、只改配置或只换代理池。追问Scrapyd 和 Docker 该怎么选？Scrapyd 更像 Scrapy 的轻量运行面板，适合快速发布、启动和停止爬虫。Docker 更强调环境一致，适合多人协作和依赖复杂的项目。两者可以组合：Scrapyd 跑在 Docker 里。坑是 Docker 不会自动解决调度、重试和限速问题。多台机器怎么管理版本？每次发布生成唯一版本号，比如 Git commit、构建编号或镜像 tag。调度记录 spider、参数、版本和机器，异常数据才能追到来源。不要每台机器手工拉代码，时间一长必然版本不一致。小团队可以先脚本同步，但多人发布要接 CI/CD。线上爬虫要自动重启吗？可以，但要限制条件和次数。临时网络失败适合重启，登录态失效、403 激增和代码异常不适合无限重启。告警里要写清失败原因和日志位置。踩坑最多的是把所有异常交给进程管理器，最后越重启封得越快。哪些配置不能写死？代理、数据库密码、Cookie、Token、运行环境和并发阈值都不该写死。它们应该来自环境变量、密钥系统或部署平台配置。非敏感默认值可以留在 settings.py。生产参数一旦写进代码，泄露和回滚都会很麻烦。如何判断部署成功？不要只看进程存在，要看任务被调度、请求成功、Item 入库、错误率正常。发布后可以跑一个测试 URL 或小时间窗口。成功标准最好脚本化，避免每次人工翻日志。Scrapy 常见坑是启动成功但没有数据，这比直接崩溃更隐蔽。