多策略抓取
BFS、DFS 与 Big Site First 并存，系统不是单条 happy path。
类图先把应用层、领域层和基础设施层的职责边界钉死
CrawlerService、CrawlTask、值对象、领域服务和基础设施适配器被明确拆开，说明 CrawlFlow 不是从接口一路写到数据库的脚本堆砌，而是一份认真做过分层设计的课程项目。
- 任务编排、核心规则、HTTP/PDF/解析实现分别落在不同层次。
- 领域对象承担状态与规则，不让控制器吞掉业务语义。
- 这张图回答的是：系统为什么可以持续演进，而不只是一次性跑通。
一次抓取任务从创建、启动到结果回传，被完整串成时序链路
前端发起任务，后端编排队列、执行抓取、持久化结果，再通过 EventBus 和 WebSocket 回推到界面。重点不是单次请求成功，而是任务生命周期怎样形成闭环。
- 任务创建与任务启动被拆成两个明确阶段，利于演示和调试。
- 结果入库与实时日志并行推进，界面不是黑盒等待。
- 它证明这套系统已经考虑了运行中的可见性。
持久化层不是附属品，而是专门为任务与结果建模的一部分
任务、结果、PDF 相关内容和状态信息有明确数据结构，说明 CrawlFlow 的落点不是临时内存结果，而是可查询、可导出、可复盘的持久化工作流。
- 任务状态与抓取结果分开建模，方便生命周期管理。
- 结果导出、历史查看和统计面板都有明确数据来源。
- 这张图把课程设计推进到了系统留痕。
仓储、DAO 与数据库访问被隔离开，持久化实现有清楚的工程边界
Repository 接口、DAO 层、数据库模型和具体实现各自承担不同责任，说明这套后端不只是能写入 MySQL，而是已经考虑了替换实现与测试隔离。
- 应用服务依赖仓储接口，而不是直接绑死 ORM 细节。
- DAO 与数据模型的分离提升了可测试性与可维护性。
- 对于作品集场景，这比直接展示表结构更能体现工程意识。
元数据提取被拆成可讲清楚的解析流程，而不是一段黑箱抓取逻辑
标题、作者、摘要、关键词与发布时间的提取路径被显式画出。它说明 CrawlFlow 不只是在抓 HTML，而是在把页面内容转成结构化结果。
- 解析链路服务于后续结果表、导出和搜索展示。
- 异常与空值分支被考虑进活动图里，体现了鲁棒性。
- 这是把课程功能翻译成工程能力的关键一层。
HTTP 客户端的请求生命周期单独建模，为动态回退与错误处理留出位置
请求发起、响应返回、错误处理与后续解析之间有明确顺序，这为 Hybrid HTTP / Playwright 回退、性能日志与异常观测提供了稳定挂点。
- 抓取成功与抓取失败都能回到统一的服务编排中。
- 客户端不是简单 requests 调用，而是整条获取链路的基础设施核心。
- 这张图承接了后面的实时日志与调试可见性。
robots.txt 检查让系统具备怎么抓和哪些不该抓的边界意识
CrawlFlow 把爬取纪律单独抽出来处理，说明它不是粗暴扫站，而是把 allow / deny / delay 等约束纳入真正的运行流程。
- 规则判断先于队列推进，避免后续链路被无效 URL 污染。
- 这也是系统可持续运行、可解释的重要前提。
- 对课设项目来说，这种约束意识本身就是加分项。
实时日志链路把领域事件、文件记录与前端观测串成同一个可见面
业务层和基础设施层的事件通过 EventBus 进入日志处理器，再同步到文件与 WebSocket，前端控制台因此能看到任务推进、技术日志和异常切片。
- 日志不是附带输出，而是系统设计的一部分。
- 同一条事件同时服务于调试、演示和运行监控。
- 它让 CrawlFlow 具备了作品集里很稀缺的运行可解释性。
