应避免多级 find 链式调用，改用分层函数封装、dataclass 建模、选择器外置配置，并将动态渲染交由 playwright 等工具处理，实现解析逻辑与页面结构解耦。
为什么直接嵌套 BeautifulSoup 查找会让代码越来越难改
多级解析不是指“爬得多”，而是指从列表页 → 详情页 → 子字段（如发布时间、作者、标签）逐层提取。一旦用 find().find().find() 连写三层以上，任意一级结构微调（比如 class 名加了前缀、父容器换了标签），整条链就崩，报 AttributeError: 'NoneType' object has no attribute 'find'。
更麻烦的是：这种写法把「页面结构」和「业务逻辑」死绑在一起，想换个网站复用？得重写所有查找路径。
- 避免用
soup.find('div', class_='list').find('a').get('href')这类长链式调用 - 把每层提取逻辑封装成独立函数，输入 HTML 片段，输出结构化字典
- 每层函数内部用
select_one()+try/except容错，不抛错，只返回None或默认值
用 dataclass 定义层级数据模型，而不是用字典硬编码
很多人用 {'title': ..., 'author': ..., 'pub_time': ...} 手动拼字典，结果新增字段时要改七八处，字段校验全靠注释——这根本不是结构，是字符串拼接。
用 @dataclass 明确声明每层的数据契约，配合 Optional 和 default_factory 处理缺失字段，既可读又可被 IDE 自动补全、类型检查：
立即学习“Python免费学习笔记（深入）”；
from dataclasses import dataclass, field from typing import Optional, List <p>@dataclass class Article: title: str url: str author: Optional[str] = None pub_time: Optional[str] = None</p><p>@dataclass class ListPage: articles: List[Article] = field(default_factory=list) next_page_url: Optional[str] = None
后续解析函数的返回类型就能写成 def parse_article(html: str) -> Article:，类型即文档。
把选择器配置抽到 JSON/YAML，别写死在 Python 里
当你要支持多个目标站点（比如同时抓知乎专栏和 CSDN 博客），每个站的 class 名、结构都不同，但解析流程一致——这时硬编码 find('h1', class_='post-title') 就成了维护噩梦。
把选择器按层级拆开，存成配置：
{
"list": {
"items": "article.post",
"url": "a.title-link::attr(href)",
"next": "a.next-page::attr(href)"
},
"detail": {
"title": "h1.entry-title",
"author": ".author-name",
"pub_time": "time.published::attr(datetime)"
}
}然后写一个通用解析器：
def parse_with_selectors(html: str, selectors: dict, target: str) -> Optional[str]:
soup = BeautifulSoup(html, 'html.parser')
sel = selectors.get(target)
if not sel:
return None
el = soup.select_one(sel)
if not el:
return None
# 自动处理 attr 提取、text 提取、默认空字符串
if '::attr(' in sel:
attr_name = sel.split('::attr(')[1].rstrip(')')
return el.get(attr_name)
return el.get_text(strip=True)这样换站点只需换配置文件，不用碰核心逻辑。
遇到动态渲染或反爬跳转，别在解析层硬扛
如果目标页用了 JavaScript 渲染内容，或者跳转依赖 meta refresh / window.location，还在 BeautifulSoup 里加各种正则匹配 URL、模拟跳转逻辑——这就越走越偏了。
多级解析的前提是「HTML 已就绪」。该交给浏览器的就交给 Playwright 或 Selenium，让它负责加载、等待、跳转，最后把最终 HTML 交给你的解析函数：
- 用
page.content()拿到渲染后 HTML，再传给parse_list_page() - 不要在解析函数里调用
driver.get()或做等待 —— 职责必须隔离 - 如果某一层始终拿不到数据，优先查是不是没等元素出现，而不是怀疑选择器写错了
真正容易被忽略的点：很多人把「解析」和「获取」混在一起，导致调试时分不清是网络问题、渲染问题，还是选择器写错了。分清楚谁负责加载、谁负责提取，出问题才好定位。
