TraceCloud 学习中心

XPath 教程：爬虫如何用 XPath 定位网页元素

Thu, 11 Jun 2026 22:23:10 GMT

为什么爬虫要学 XPath？

CSS 选择器你会了，但遇到这类情况就不够用了：

要选"父节点下第二个 li 里的链接"
要选"所有带 href 属性且包含 /detail/ 的 a 标签"
要选"当前节点的爷爷节点里的 span 文本"

这些用 CSS 选择器能做到吗？能，但会很绕，甚至做不到。

XPath 就是来解决这个问题的——它能精准定位 DOM 树里任意位置的元素，不依赖层级关系的 CSS 类名，而是用路径表达式一层层找过去。

CSS 选择器是"猜"，XPath 是"指"。

学完这篇，你能做到：

用路径表达式选任意节点
用谓语精确找到第 N 个元素或特定属性
用轴（axis）向上找父节点、向下找子孙节点
在 Python 的 lxml 库里写 XPath 表达式

XPath 是什么？和 CSS 选择器有什么区别？

XPath 全称是 XML Path Language，最初是用来在 XML 文档里定位节点的语言。后来被广泛引入了 HTML 解析领域，因为它本质上是一套"在树状结构里找节点"的语法。

简单对比：

	CSS 选择器	XPath
起源	为样式设计	为 XML 解析设计
选父节点	`ul > li`	`//li/parent::ul`
选第 N 个	`:nth-child(2)`	`//li[2]`
选属性	`a[href]`	`//a[@href]`
选文本	不直接支持	`//span/text()`
选祖先	不支持	`//span/ancestor::div`
上手难度	低	中

CSS 选择器适合简单快速的定位，XPath 适合复杂精准的定位。两者不是替代关系，而是互补关系——爬虫老手通常两个都会，需要哪个用哪个。

XPath 基础语法：节点选取怎么写？

XPath 用"路径表达式"来描述节点位置，就像文件系统里的路径。

最基本的五种表达式

表达式	含义	示例
`nodename`	选取该名字的所有子节点	`div` → 所有 div
`/`	从根节点选取（绝对路径）	`/html/body`
`//`	从匹配位置的当前节点往下选（相对路径）	`//div//a`
`.`	当前节点
`..`	当前节点的父节点
`@`	选取属性	`@href`

看一个 HTML 结构：

对应 XPath：

//ul                   → 选取所有 ul
//body/div              → 选取 body 下的 div
//div//a               → 选取 div 内任意层级的所有 a
//a/@href              → 选取所有 a 标签的 href 属性值
//li[1]                → 选取第一个 li

谓语怎么用？如何精确找到第 N 个元素或特定属性？

谓语就是写在方括号里的条件 [条件]，可以精确筛选节点。

按索引定位：第一个、第二个、最后一个

//li[1]                → 第一个 li（XPath 从 1 开始，不是 0）
//li[last()]           → 最后一个 li
//li[last()-1]         → 倒数第二个 li
//li[position() < 3]   → 前两个 li

按属性值定位：class、href、id

//div[@class="container"]          → class 等于 container 的 div
//a[@href="/movie/1"]             → href 等于指定值的 a
//div[@id]                         → 有 id 属性的所有 div
//div[not(@id)]                   → 没有 id 属性的所有 div

按文本内容定位

//span[text()="下一页"]              → 文本等于"下一页"的 span
//span[contains(text(),"价格")]      → 文本包含"价格"的 span
//a[contains(@href,"/detail")]       → href 包含 "/detail" 的 a

组合条件：多个谓语叠加

//li[@class="movie-item"][1]         → class 为 movie-item 的第一个 li
//div[@id="main"]//a[@href][2]       → id 为 main 的 div 下，第二个带 href 的 a

XPath 轴怎么用？父子兄弟节点定位

轴（Axis）是 XPath 独有的能力——可以往当前节点的上方或下方任意方向查找，这是 CSS 选择器做不到的。

语法：//轴::节点测试[谓语]

常用轴

轴	含义	示例
`parent::`	父节点	`//span/parent::div`
`child::`	子节点（默认，可省略）	`//div/child::a`
`descendant::`	所有后代节点	`//div/descendant::span`
`ancestor::`	所有祖先节点	`//span/ancestor::div`
`following-sibling::`	后续兄弟节点	`//h2/following-sibling::p`
`preceding-sibling::`	前置兄弟节点	`//td/preceding-sibling::th`
`self::`	当前节点自身	`//span[self::span[@class="price"]]`

实战例子

找到当前节点的父节点：

//span[@class="price"]/parent::div

找到所有兄弟节点：

//li[@class="active"]/following-sibling::li

找到爷爷节点里的某个属性：

//span/ancestor::div[@id="article"]//h1

选中当前节点的文本再往父节点走：

//text()[.="登录"]/parent::button

Python 爬虫里怎么用 XPath？lxml + etree 示例

Python 里用 XPath，主要通过 lxml 库解析 HTML 并提取数据：

from lxml import etree

html = """

  
    
      
        肖申克的救赎
        9.7
      
      
        霸王别姬
        9.6
      
    
  

"""

selector = etree.HTML(html)

# 选所有电影标题
titles = selector.xpath('//span[@class="title"]/text()')
print(titles)  # ['肖申克的救赎', '霸王别姬']

# 选第一部电影的分数
score = selector.xpath('//li[1]//span[@class="score"]/text()')
print(score)  # ['9.7']

# 选包含"救赎"的标题
title = selector.xpath('//span[contains(text(),"救赎")]/text()')
print(title)  # ['肖申克的救赎']

# 获取 href 属性
links = selector.xpath('//a/@href')
print(links)  # ['/movie/1', '/movie/2']

# 选中所有 a 的文本和对应 href
for a in selector.xpath('//a'):
    text = a.xpath('text()')[0] if a.xpath('text()') else ''
    href = a.xpath('@href')[0] if a.xpath('@href') else ''
    print(text, href)

常用 lxml + XPath 方法

方法	作用
`selector.xpath('//xpath')`	返回列表，所有匹配结果
`selector.xpath('//xpath')[0]`	取第一个匹配结果
`selector.xpath('string(//xpath)')`	取拼接后的完整文本
`selector.xpath('//xpath/@href')`	取属性值列表
`selector.xpath('count(//li)')`	统计匹配数量

XPath 和 CSS 选择器怎么选？哪个更好用？

场景	推荐	原因
页面结构简单，类名清晰	CSS 选择器	写起来更短，更直观
需要定位第 N 个元素	XPath	CSS `:nth-child` 语法繁琐
需要取文本内容	XPath	CSS 无法直接取文本
需要向上找父节点/祖先	XPath	CSS 不支持向上查找
需要定位带特定属性的元素	两者皆可	CSS `a[href]` 和 XPath `//a[@href]` 等价
需要统计节点数量	XPath	`count()` 函数比 CSS 方便

建议： 先用 CSS 选择器搞定简单的，遇到复杂定位再上 XPath。两种工具配合使用，爬虫老手都是这样干的。

XPath 常见报错与处理

1. 空列表：匹配不到元素

results = selector.xpath('//div[@class="movie"]//a/text()')
# results = []  ← 空列表

检查：

类名拼写是否正确（大小写敏感）
页面是否是动态加载（需要用 Selenium/Playwright 先生成 HTML）
用浏览器开发者工具复制实际 XPath 检查

2. 下标越界

title = selector.xpath('//li[1]//span/text()')[0]
# IndexError: list index out of range

XPath 从 1 开始，不是 0。如果页面结构不确定，先判断：

titles = selector.xpath('//li//span/text()')
if titles:
    print(titles[0])

3. 属性名拼错

//img[@src]       ✅ 正确
//img[@scr]       ❌ 错误（scr 是常见拼写错误）

4. 文本含空格或换行导致匹配失败

   价格

//span[text()="价格"]              ❌ 失败（文本有空格）
//span[contains(text(),"价格")]     ✅ 成功

XPath 优化技巧：写得更精准、更稳定

技巧 1：用 @class 代替没有语义的 div

//div/div/div/span                ❌ 脆弱，层级一改就失效
//div[@class="movie-card"]//span  ✅ 语义稳定，不依赖具体层级

技巧 2：用 contains() 处理动态生成的类名

有些页面类名是动态生成的，比如 class="item-83271"：

//li[contains(@class,"item-")]//a   → 只要 class 里含 "item-" 就能匹配

技巧 3：用 string() 取完整文本（避免空白节点干扰）

string(//div[@class="content"])   → 拼接所有子节点文本，自动去除空白
text()                              → 只取当前节点直接文本，可能遗漏子节点内容

技巧 4：用 normalize-space() 处理首尾空格

//span[normalize-space(text())="价格"]   → 自动去除首尾空格再匹配

技巧 5：避免使用 @id 做定位（ID 常动态生成）

//div[@id="product-price"]        ❌ ID 常动态变化，维护成本高
//span[contains(@class,"price")]  ✅ 用类名或属性值组合更稳定

常见问题

XPath 和 CSS 选择器哪个更快？

在 lxml 里，CSS 选择器会被转成 XPath 执行，速度差异可以忽略。选你能写得更准的，而不是更快的。

页面是 JavaScript 动态生成的，能用 XPath 吗？

能，但要先拿到渲染后的 HTML。用 Selenium 或 Playwright 打开页面，等内容加载完成，再提取 HTML 给 lxml 解析：

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page()
    page.goto("https://example.com")
    page.wait_for_selector(".movie-item")  # 等内容加载完成
    html = page.content()
    browser.close()

from lxml import etree
selector = etree.HTML(html)
titles = selector.xpath('//span[@class="title"]/text()')

为什么 XPath 在浏览器开发者工具里能选中，但 lxml 解析不出来？

浏览器里的 XPath 基于渲染后的 DOM，有可能有隐藏的命名空间（namespace）导致解析失败。解决方法是使用 etree.HTML() 而不是 etree.XML()，或者用 lxml.html.fromstring() 解析：

from lxml import html
selector = html.fromstring(html_source)

XPath 能处理 JSON 数据吗？

XPath 只处理 XML/HTML，不能直接处理 JSON。如果目标数据在 API 返回的 JSON 里，requests + json() 更直接，不需要 XPath。

XPath 中的通配符怎么用？

//*                    → 选取所有元素
//div/*                → 选取 div 下所有直接子元素
//li[@class="item-*"]  → class 以 "item-" 开头的所有 li

XPath 支持逻辑运算吗？

支持，用 and、or、not()：

//div[@class="main" and @id="content"]   → 同时满足两个条件
//div[@class="main" or @class="sidebar"] → 满足任一条件
//div[not(@class="hidden")]               → 不包含某类名

总结

XPath 的核心能力就三点：

路径表达式 — 精准定位树中任意节点
谓语 — 用条件过滤，找到第 N 个或满足特定属性的元素
轴 — 往上找父/祖先，往下找子孙，不用受 CSS 只能"向下找"的限制

CSS 选择器和 XPath 不是谁替代谁，而是各有优势。CSS 快而直观，XPath 强而精准。

学完这篇，你应该能应对爬虫里 80% 的元素定位场景。剩下 20% 的极端情况（比如跨 iframe、Shadow DOM），后面再单独研究。

FAQ

Q：XPath 从 1 开始数还是从 0 开始？

A：XPath 从 1 开始数，和编程语言的数组下标从 0 开始不同。//li[1] 选的是第一个 li，不是第二个。

Q：CSS 选择器和 XPath 能同时用吗？

A：能。Python 的 lxml 库支持用 CSS 选择器写法，自动转成 XPath 执行。写复杂的节点定位时，XPath 更强大；写简单的样式类名定位时，CSS 选择器更直观。

Q：为什么 //div 能匹配所有 div，但 //div[@class="container"] 却匹配不到？

A：检查页面 HTML 源码里实际的 class 属性值。有些页面类名是动态的，比如 class="container-abc123"，需要用 contains() 模糊匹配，而不是精确匹配。

Q：XPath 能跨 iframe 查找元素吗？

A：不能直接跨 iframe。用 XPath 只能查到当前文档树的节点。如果目标元素在 iframe 里，需要先切换到那个 iframe 的 document，再继续用 XPath 查找。

Q：XPath 的 // 和 / 有什么区别？

A：/ 是从根节点开始的绝对路径，// 是从当前节点开始往下任意层级的相对路径。爬虫里最常用的是 //，因为往往不知道根节点是什么，直接从文档任意位置往下找更实用。

Q：XPath 能统计某个元素出现了多少次吗？

A：能。用 count() 函数：selector.xpath('count(//div[@class="item"]')，返回匹配到的 div 数量（浮点数），转为整数的用法是 int(selector.xpath('count(//li)')。

Python Parsel 教程：用 CSS、XPath 提取网页数据

Thu, 11 Jun 2026 12:44:38 GMT

安装 Parsel

pip install parsel

如果示例还要发送 HTTP 请求，再安装 requests：

pip install requests

从 Selector 开始

Selector 用来包装待解析的文本。调用 .css() 或 .xpath() 后，会得到一个 SelectorList，它可以继续调用选择器方法，也可以直接遍历。

from parsel import Selector

html = """

  
    
      Python 爬虫入门
      学习网页请求与数据提取。
      开始阅读
    
  

"""

selector = Selector(text=html)

后面的 CSS、XPath 和正则示例都使用这个 selector。

用 CSS 选择器提取数据

CSS 语法短，页面结构不复杂时很好读。

如果你对类选择器、属性选择器和后代选择器还不熟，可以先看 CSS 选择器入门：从改样式到爬虫数据定位。

# 提取文本
title = selector.css("h1::text").get()
print(title)  # Python 爬虫入门

# 提取属性
link = selector.css("a::attr(href)").get()
print(link)  # /start

# 提取全部匹配结果
paragraphs = selector.css("p::text").getall()
print(paragraphs)  # ['学习网页请求与数据提取。']

::text 和 ::attr(name) 是 Parsel/Scrapy 扩展的伪元素：

::text 获取当前元素的直接文本节点
::attr(href) 获取元素的 href 属性

它们不是浏览器原生 CSS 语法。在浏览器控制台测试定位规则时，先测试 h1、a 这部分，回到 Parsel 后再补上 ::text 或 ::attr()。

还有一个容易忽略的细节：::text 只取直接文本节点。遇到下面这种结构：

价格 299 元

如果想取出元素内部的全部文本，可以使用 XPath：

texts = selector.css("p.desc").xpath(".//text()").getall()
description = "".join(texts).strip()

用 XPath 提取数据

XPath 更适合按属性、层级关系或文本条件筛选节点。

# 提取文本
title = selector.xpath("//h1/text()").get()

# 提取属性
link = selector.xpath("//a/@href").get()

# 按 class 属性筛选
summary = selector.xpath('//p[@class="summary"]/text()').get()

CSS 和 XPath 可以混用。例如先用 CSS 找到文章卡片，再用 XPath 提取卡片中的全部文本。

循环内要使用相对 XPath

这可能是 Parsel 新手最容易踩的坑。

for item in selector.css("div.item"):
    # 正确：从当前 item 内部继续查找
    name = item.xpath(".//span[@class='name']/text()").get()

这里的 .// 表示“从当前节点向下查找”。如果写成 //span，查询会回到整份文档，每次循环都可能拿到同一批结果。

`.get()` 和 `.getall()` 有什么区别

两者的区别不复杂：

first = selector.css("li::text").get()
items = selector.css("li::text").getall()

.get() 返回第一个匹配值；没有匹配时返回 None
.getall() 返回所有匹配值；没有匹配时返回空列表 []

可以给 .get() 设置默认值，避免字段缺失后调用字符串方法时报错：

price = selector.css(".price::text").get(default="").strip()

旧代码中常见的 .extract() 和 .extract_first() 仍可使用，但新代码更建议写 .getall() 和 .get()。

用正则表达式做二次提取

正则适合处理已经定位好的短文本，不建议直接拿它解析整页 HTML。

from parsel import Selector

price_html = "价格：¥128.00"
price_selector = Selector(text=price_html)

price = price_selector.css("span.price::text").re_first(r"\d+(?:\.\d+)?")
print(price)  # 128.00

.re() 返回所有匹配结果，.re_first() 只返回第一个结果。调用正则后得到的是字符串，不再是可以继续调用 .css() 或 .xpath() 的选择器。

提取列表页数据

列表页不要分别提取全部标题和全部链接后再 zip()。只要某条记录缺少一个字段，数据就可能错位。更稳妥的写法是先遍历每个卡片，再在卡片内部取字段。

from parsel import Selector

html = """

  
    机械键盘
    299
  
  
    无线鼠标
    159
  

"""

selector = Selector(text=html)
products = []

for item in selector.css("div.item"):
    name = item.css("a.name::text").get(default="").strip()
    link = item.css("a.name::attr(href)").get(default="")
    price = item.css("span.price::text").get(default="").strip()

    if not name or not link:
        continue

    products.append({
        "name": name,
        "link": link,
        "price": price,
    })

print(products)

这个写法有两个好处：字段属于哪条记录一目了然，个别卡片缺字段时也不会影响后面的数据。

Parsel 配合 requests

下面是一个更接近实际项目的例子：请求新闻列表，检查响应，再提取标题和链接。

from urllib.parse import urljoin

import requests
from parsel import Selector


def scrape_news(url: str) -> list[dict[str, str]]:
    headers = {
        "User-Agent": (
            "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
            "AppleWebKit/537.36 (KHTML, like Gecko) "
            "Chrome/124.0 Safari/537.36"
        )
    }

    try:
        response = requests.get(url, headers=headers, timeout=(5, 15))
        response.raise_for_status()
    except requests.RequestException as exc:
        print(f"请求失败：{exc}")
        return []

    selector = Selector(text=response.text)
    news_list = []

    for article in selector.css("article.news-item"):
        title = article.css("h2 a::text").get(default="").strip()
        href = article.css("h2 a::attr(href)").get(default="")
        date = article.css("time::attr(datetime)").get(default="")
        summary = " ".join(
            text.strip()
            for text in article.css("p.summary").xpath(".//text()").getall()
            if text.strip()
        )

        if not title or not href:
            continue

        news_list.append({
            "title": title,
            "link": urljoin(response.url, href),
            "date": date,
            "summary": summary,
        })

    return news_list


if __name__ == "__main__":
    for news in scrape_news("https://example.com/news"):
        print(news["title"], "->", news["link"])

这里统一捕获了 RequestException。需要区分连接失败、超时和 HTTP 状态码异常时，可以继续看 Python 爬虫 requests 异常处理完全指南。

示例中有几个值得保留的习惯：

请求必须设置超时，避免程序一直等下去
使用 raise_for_status() 处理 4xx、5xx 响应
在每个卡片内部提取字段，避免列表错位
使用 urljoin() 把相对链接补成绝对链接
对可能缺失的字段设置默认值

解析 XML 和命名空间

解析 XML 时显式设置 type="xml"：

from parsel import Selector

xml_data = """

  商品 A50
  商品 B0

"""

selector = Selector(text=xml_data, type="xml")

for item in selector.xpath("//item"):
    item_id = item.xpath("@id").get(default="")
    name = item.xpath("name/text()").get(default="")
    stock = item.xpath("stock/text()").get(default="")
    print(item_id, name, stock)

带命名空间的 XML 不能总靠普通标签名匹配。数据结构简单、也不需要区分同名命名空间时，可以先移除命名空间：

selector = Selector(text=xml_with_namespace, type="xml")
selector.remove_namespaces()
items = selector.xpath("//item").getall()

如果文档里存在多个同名标签，移除命名空间可能让它们混在一起。这时应保留命名空间，并在 XPath 中注册、使用对应前缀。

为什么选择器明明正确，却取不到数据

遇到空结果时，先别急着换 CSS 或 XPath。按下面的顺序检查，通常更快。

1. 响应里根本没有目标内容

先检查服务端返回的原始 HTML：

print(response.status_code)
print(response.url)
print(response.text[:1000])

浏览器里看得到、response.text 里没有，常见原因是页面由 JavaScript 渲染。Parsel 不会执行 JavaScript，需要找到页面背后的数据接口，或者使用 Playwright 等浏览器自动化工具拿到渲染后的 HTML。

2. 请求被重定向或返回了验证页

登录页、验证码页和风控提示也可能返回 200。只看状态码不够，还要检查最终 URL、页面标题和正文片段。

3. 页面编码判断错误

如果内容存在但中文乱码，可以先检查响应头和 response.apparent_encoding，确认后再指定编码：

response.encoding = "gb18030"
selector = Selector(text=response.text)

不要见到中文站点就固定写 gbk。编码应根据响应头、页面声明或实际字节内容判断。

4. XPath 查询范围写错

在子节点中继续查询时，优先检查有没有把 .// 写成 //。后者会从整份文档开始匹配。

5. 文本藏在子标签里

p::text 取不到

文字重点

中的全部内容。需要改用 .//text()，再把文本片段清洗、拼接。

CSS 还是 XPath

没有必要二选一。

页面结构简单时，CSS 通常更短：

selector.css("article.news-item h2 a::text").getall()

需要按文本、父子关系或复杂条件筛选时，XPath 更顺手：

selector.xpath('//article[contains(@class, "news-item")]//a/text()').getall()

实际项目里常见的做法是：CSS 负责定位重复卡片，XPath 处理卡片内部不规则的文本结构。哪种写法更清楚，就用哪种。

常用方法速查

需求	写法
创建 HTML 解析器	`Selector(text=html)`
创建 XML 解析器	`Selector(text=xml, type="xml")`
CSS 选择节点	`.css("div.item")`
XPath 选择节点	`.xpath("//div")`
获取第一个结果	`.get()`
获取全部结果	`.getall()`
获取文本	`.css("h1::text")`
获取属性	`.css("a::attr(href)")`
正则提取首个结果	`.re_first(pattern)`
正则提取全部结果	`.re(pattern)`
移除 XML 命名空间	`.remove_namespaces()`

Python urljoin 教程：URL 路径拼接与相对路径处理完整指南

Mon, 01 Jun 2026 15:44:07 GMT

为什么爬虫要处理 URL 路径拼接？

写爬虫时，你会经常遇到这类问题：

从页面 HTML 里拿到相对路径 /img/logo.png，不知道怎样拼成完整 URL
用 urljoin 拼出来结果和想的不一样，不知道哪里出了问题
base URL 带了查询参数 ?x=1&b=2 和锚点 #hash，担心会被一起带进结果里

如果直接用字符串拼接：

base = "https://example.com/a/b/c?x=1&b=2#hash"
result = base + "/img/logo.png"
# ❌ https://example.com/a/b/c?x=1&b=2#hash/img/logo.png

这显然不对。正确做法是使用 Python 标准库的 urljoin，它按 URL 结构规则来处理路径拼接，不是简单的字符串连接。

学完这篇，你能够：

理解 URL 各组成部分（scheme、netloc、path、query、fragment）
掌握 urljoin 的路径拼接规则（相对路径、./、../、绝对路径）
区分 urljoin 和字符串拼接的本质差异
在爬虫里正确拼接相对路径，提取完整资源 URL
避开 urljoin 的常见误区

URL 结构：urljoin 到底在处理什么？

urljoin 拼的不是字符串，而是 URL 结构。

先把 base URL 拆解成 5 个组成部分：

组成部分	含义	示例值
scheme	协议	`https`
netloc	域名	`example.com`
path	路径	`/a/b/c`
query	查询参数	`x=1&b=2`
fragment	锚点	`hash`

from urllib.parse import urlparse

base = "https://example.com/a/b/c?x=1&b=2#hash"
parsed = urlparse(base)

print(parsed.scheme)    # https
print(parsed.netloc)    # example.com
print(parsed.path)      # /a/b/c
print(parsed.query)     # x=1&b=2
print(parsed.fragment)  # hash

关键提醒：

urljoin 只处理 path，base URL 的 query（? 后面的部分）和 fragment（# 后面的部分）会被直接丢弃。

也就是说，无论 base 带了多么复杂的查询参数，拼接结果都不会包含它们。只有 path 会被用来参与路径计算。

urljoin 基础：相对路径怎么拼？

相对路径：以「当前目录」为基准

from urllib.parse import urljoin

base = "https://example.com/a/b/c?x=1&b=2#hash"

result = urljoin(base, "img/1.jpg")
print(result)
# https://example.com/a/b/img/1.jpg

为什么会是这个结果？

base 的 path 是 /a/b/c
c 被识别为文件名，而非目录
当前目录 = /a/b/
拼接 img/1.jpg → /a/b/img/1.jpg

这就是 urljoin 的核心规则：以 base path 的「当前目录」为基准，往下拼接相对路径。

./：明确表示"当前目录"

print(urljoin(base, "./path"))
# https://example.com/a/b/path

./ 的效果和上面一样，只是更明确地告诉你：以当前目录为起点。

../：向上回退一层目录

print(urljoin(base, "../css/main.css"))
# https://example.com/a/css/main.css

计算过程：

当前目录 = /a/b/
.. 退一层 → /a/
再拼上 css/main.css → /a/css/main.css

有几个 ..，就退几层目录。

# 退两层
print(urljoin(base, "../../css/main.css"))
# https://example.com/css/main.css

urljoin 进阶：绝对路径怎么处理？

/ 开头：从网站根目录算

print(urljoin(base, "/static/app.js"))
# https://example.com/static/app.js

关键区别：

相对路径（无 / 开头）：以 base 的当前目录为基准
绝对路径（有 / 开头）：从域名根目录开始，忽略 base 的路径

完整 URL：直接覆盖

# 第二个参数是完整 URL，直接返回它
print(urljoin(base, "https://other.com/path"))
# https://other.com/path

urljoin vs 字符串拼接：本质区别在哪里？

对比项	字符串拼接	urljoin
处理方式	字符连接	URL 结构解析
遇到 `/` 时的行为	产生双斜杠 `//`	自动规整
处理 `../`	当普通字符	正确回退目录
处理 query/fragment	原样保留	丢弃（除非相对路径本身含）
跨协议/域名	全部拼接	正确替换

字符串拼接的坑：

base = "https://example.com/a/b/"
path = "/img/logo.png"

print(base + path)
# ❌ https://example.com/a/b//img/logo.png（双斜杠）

print(base + path.lstrip('/'))
# ⚠️ 可以，但你自己处理了，urljoin 更安全

urljoin 的优势：

from urllib.parse import urljoin

base = "https://example.com/a/b/"
path = "/img/logo.png"

print(urljoin(base, path))
# ✅ https://example.com/img/logo.png（自动处理）

实战：爬虫里怎么用 urljoin 拼接图片链接？

场景：从 HTML 里提取相对路径，拼接完整 URL

from urllib.parse import urljoin
from lxml import etree
import requests

# 目标页面
url = "https://example.com/article/python-intro"
html = requests.get(url, headers={"User-Agent": "Mozilla/5.0"}).text

selector = etree.HTML(html)

# 提取所有图片的 src（相对路径）
img_srcs = selector.xpath('//img[@src]/@src')

for src in img_srcs:
    full_url = urljoin(url, src)
    print(full_url)

运行结果示例：

https://example.com/article/python-intro
https://example.com/article/img/cover.jpg          # 相对路径 → 完整 URL
https://example.com/static/logo.png               # / 开头 → 根目录
https://other.com/banner.png                      # 完整 URL → 直接保留

场景：批量拼接资源 URL 并下载

from urllib.parse import urljoin
from lxml import etree
import requests

def download_resources(page_url, css_selector):
    """下载页面指定选择器对应的所有资源"""
    html = requests.get(page_url, headers={"User-Agent": "Mozilla/5.0"}).text
    selector = etree.HTML(html)
    resources = selector.xpath(f'{css_selector}/@href | {css_selector}/@src')
    
    for resource in resources:
        # 拼接完整 URL
        resource_url = urljoin(page_url, resource)
        # 下载（省略异常处理）
        r = requests.get(resource_url)
        filename = resource_url.split('/')[-1]
        with open(filename, 'wb') as f:
            f.write(r.content)
        print(f"Downloaded: {resource_url}")

场景：拼接分页 URL

from urllib.parse import urljoin

base = "https://example.com/list/page1"
page_count = 5

for i in range(1, page_count + 1):
    # 方法 1：用 urljoin 拼接
    page_url = urljoin(base, f"page{i}")
    print(page_url)
    # https://example.com/list/page1 → https://example.com/list/page2 → ...

# 方法 2：用 format 直接生成（更直观）
for i in range(1, page_count + 1):
    print(f"https://example.com/list/page{i}")

urljoin 常见报错与处理

报错 1：拼接结果包含了旧的 query 参数

from urllib.parse import urljoin

base = "https://example.com/a/b?keyword=python"
result = urljoin(base, "img/logo.png")

print(result)
# https://example.com/a/img/logo.png
# ✅ query 参数被正确丢弃了（这不是报错，是 urljoin 的标准行为）

如果你的本意是要保留 query 参数，需要手动处理：

from urllib.parse import urlparse, urlunparse

base = "https://example.com/a/b?keyword=python"
new_path = "img/logo.png"

parsed = urlparse(base)
new_url = urlunparse((
    parsed.scheme,
    parsed.netloc,
    new_path,
    '',  # params（很少用）
    parsed.query,  # 保留 query
    ''   # fragment
))
print(new_url)
# https://example.com/img/logo.png?keyword=python

报错 2：相对路径带空格导致拼接失败

# 相对路径里带空格，必须编码
src = "/img/my photo.jpg"
# ❌ urljoin 会把空格当成路径分隔符，导致奇怪结果

from urllib.parse import quote
safe_src = quote(src, safe='/')
full_url = urljoin(base, safe_src)
# ✅ https://example.com/img/my%20photo.jpg

报错 3：base URL 末尾有 / 跟没有，结果不一样

from urllib.parse import urljoin

base_with_slash = "https://example.com/a/b/"
base_no_slash = "https://example.com/a/b"

print(urljoin(base_with_slash, "c"))
# https://example.com/a/b/c

print(urljoin(base_no_slash, "c"))
# https://example.com/a/c  ← 注意这里！b 被当成文件名替换了

处理方法：

# 保证 base URL 末尾有 /
import urllib.parse

def ensure_trailing_slash(url):
    parsed = urllib.parse.urlparse(url)
    if not parsed.path.endswith('/'):
        return url.rstrip('/') + '/'
    return url

base = ensure_trailing_slash("https://example.com/a/b")
print(urljoin(base, "c"))
# https://example.com/a/b/c  ✅

报错 4：协议相对 URL（//开头）

print(urljoin("https://example.com/", "//cdn.com/logo.png"))
# ✅ https://cdn.com/logo.png（自动补全 https:）

这其实是 urljoin 的正常行为，但有时会引发问题，需要注意。

urljoin 与 urlparse、urlunparse 的关系

urllib.parse 模块里三个函数配合使用：

from urllib.parse import urljoin, urlparse, urlunparse

url = "https://example.com/a/b/c?x=1#section"

# 1. 解析：拆解 URL 结构
parsed = urlparse(url)
print(parsed)
# ParseResult(scheme='https', netloc='example.com', path='/a/b/c', query='x=1', fragment='section')

# 2. 修改：替换某个组成部分
modified = parsed._replace(path="/new/path")
print(urlunparse(modified))
# https://example.com/new/path?x=1#section

# 3. 拼接：用 urljoin
result = urljoin(url, "../css/style.css")
print(result)
# https://example.com/a/css/style.css

三者的分工：

函数	作用	场景
`urlparse`	拆分 URL 结构	分析、修改 URL 某部分
`urljoin`	拼接相对路径	爬虫提取资源、生成完整 URL
`urlunparse`	组合成新 URL	修改后重新组装

常见问题

urljoin 和 os.path.join 有什么区别？

os.path.join 是文件系统路径拼接，不管 URL 结构。urljoin 是URL 路径拼接，理解 URL 结构规则。两者不能混用：

import os
from urllib.parse import urljoin

# os.path.join 用在文件系统路径上
print(os.path.join("/a/b", "c"))
# ✅ /a/b/c

# urljoin 用在 URL 上
print(urljoin("https://example.com/a/b", "c"))
# ✅ https://example.com/a/c

base URL 末尾的 / 重要吗？

非常重要。

from urllib.parse import urljoin

# 有 /
urljoin("https://example.com/a/b/", "c")
# https://example.com/a/b/c

# 没有 /
urljoin("https://example.com/a/b", "c")
# https://example.com/a/c  ← 完全不同的结果！

爬虫里处理相对路径时，建议先对 base URL 做规范化处理：

def normalize_base_url(url):
    from urllib.parse import urlparse
    p = urlparse(url)
    if not p.path.endswith('/'):
        return f"{p.scheme}://{p.netloc}{p.path}/"
    return url

urljoin 能处理锚点（#hash）吗？

不能直接保留。 urljoin 会丢弃 base 的 fragment：

print(urljoin("https://example.com/a#section", "b"))
# https://example.com/a  ← #section 丢了

如果需要保留锚点到新页面：

def join_with_fragment(base, path):
    from urllib.parse import urlparse
    frag = urlparse(base).fragment
    joined = urljoin(base, path)
    return f"{joined}#{frag}" if frag else joined

协议相对 URL（以 // 开头）怎么处理？

有些资源链接写成 //cdn.example.com/logo.png，这是协议相对 URL：

print(urljoin("https://example.com/", "//cdn.example.com/logo.png"))
# ✅ https://cdn.example.com/logo.png

urljoin 会自动补全 scheme，但如果需要在没有协议的上下文中处理它，需要注意这一点。

总结

urljoin 的核心逻辑其实很简单：

相对路径（无 / 开头）：以 base 的「当前目录」（即去掉文件名后的路径）为基准，往下拼接
./：明确指向当前目录
../：向上回退一层目录
绝对路径（/ 开头）：从网站根目录开始，忽略 base 的路径
完整 URL：直接替换 base，不做任何拼接

爬虫里用 urljoin 的最佳实践：

提取页面资源时，先用 urljoin(base, relative_path) 拼接成完整 URL 再请求
用 urlparse 分析 URL 结构，用 urljoin 拼接相对路径，用 urlunparse 重组修改后的 URL
拼接前先规范化 base URL（检查末尾 /），避免目录层级判断错误
用 quote() 编码含空格或特殊字符的路径

FAQ

Q：urljoin 和字符串拼接 + 哪个更好？

A：urljoin 更好。它按 URL 结构规则处理路径拼接，能自动处理 / 和 ../ 等特殊符号，而字符串拼接会产生双斜杠或错误的路径。Python 的 urllib.parse 就是为这个设计的，不要自己写字符串拼接。

Q：base URL 带查询参数，urljoin 会保留吗？

A：不会。urljoin 只处理 path，base 的 query 参数和 fragment 会被丢弃。如果需要保留 query 参数，需要用 urlparse + urlunparse 手动处理。

Q：相对路径开头有 ./ 和没有有区别吗？

A：在 urljoin 里基本没有区别。urljoin(base, "img/1.jpg") 和 urljoin(base, "./img/1.jpg") 结果完全一样。./ 的作用是明确告诉阅读者这是当前目录下的路径，在 urljoin 解析层面是一样的。

Q：urljoin 会不会产生双斜杠 //？

A：不会。urljoin 会自动规整路径，消除多余的 /。但字符串拼接 base + "/path" 会产生 //（虽然大多数服务器能处理，但不符合规范）。

Q：爬虫里提取到相对路径，什么时候用 urljoin，什么时候不需要？

A：如果相对路径是完整的 URL（以 http:// 或 https:// 开头），不需要 urljoin。如果是以 /、./、../ 开头，或者没有任何 / 的纯路径，就必须用 urljoin 拼接成完整 URL。

Python 爬虫 requests 异常处理完全指南：超时、ConnectionError、HTTPError 怎么办

Sat, 30 May 2026 03:21:50 GMT

为什么你的爬虫请求总是失败？

requests 发出去的请求，一定会成功吗？

不一定。

服务器可能崩了，网络可能波动，代理可能失效，证书可能过期。这些事情不在你代码的控制范围内。

不处理异常，程序就会在某个你没想到的时候直接崩掉。

requests 异常有哪些？一图梳理完整体系

Python 异常最顶层是 BaseException，日常能捕获到的运行时异常基本都在它的子类 Exception 下面。

requests 在 Exception 下面定义了一个 RequestException，它是所有 requests 异常的基类。

BaseException
 └─ Exception
     └─ RequestException        # 所有 requests 异常基类
         ├─ HTTPError
         ├─ ConnectionError
         │   ├─ ProxyError
         │   └─ SSLError
         ├─ Timeout
         │   ├─ ConnectTimeout
         │   └─ ReadTimeout
         ├─ TooManyRedirects
         ├─ MissingSchema
         ├─ InvalidSchema
         └─ InvalidURL

只要捕获 RequestException，requests 的全部异常都能兜住。当然，你也可以细分捕获，不同的异常用不同的方式处理。

异常按阶段来理解更清楚

一次请求从发出到拿到结果，是分阶段的。异常基本上就是某个阶段失败了。

URL 报错 MissingSchema/InvalidURL 怎么处理？

请求还没发出去就报错了，多半是 URL 写错了。

import requests

requests.get("example.com")        # MissingSchema，缺少 http://
requests.get("ftp://example.com")  # InvalidSchema，不支持 ftp
requests.get("https://example .com") # InvalidURL，格式不合法

这类问题如果 URL 是手写的，检查一遍就能解决。如果 URL 来自上游爬虫，就要在拼接时做好校验。

连接失败 ConnectionError/ProxyError 怎么处理？

URL 没问题，进入连接阶段，可能遇到 ConnectionError。

常见场景：断网了、服务器 IP 不存在、端口没开、代理配置错、证书问题。

requests.get("https://not-exist-domain-xyz.com")  # ConnectionError

两个常见子类：

ProxyError：代理连接失败
SSLError：HTTPS 证书验证失败，前面讲过，可以传 verify=False 临时跳过

requests 超时怎么办？timeout 这样设置才正确

连上了，但服务器迟迟不响应。

这时候一定要设置 timeout，否则代码会一直卡着，永远等下去。

# 连接和读取共享 5 秒超时
requests.get(url, timeout=5)

# 分开设置：连接 3 秒，读取 10 秒
requests.get(url, timeout=(3, 10))

超时会抛 Timeout，子类是 ConnectTimeout（连接超时）和 ReadTimeout（读取超时）。

timeout 一定要带上，别省。

状态码报错 HTTPError 怎么处理？raise_for_status 用法

这种情况 requests 默认不抛异常。状态码 404、500，你都能正常拿到 response，requests 不认为这是错误。

如果你希望状态码非 2xx 时抛异常，就调用 raise_for_status()：

response = requests.get(url)
response.raise_for_status()  # 非 2xx 抛 HTTPError

重定向过多 TooManyRedirects 怎么处理？

requests 默认会自动跟随重定向，比如 http 跳 https 就是这么处理的。

但如果重定向形成了死循环，超过限制（默认 30 次）就会抛 TooManyRedirects。

requests 异常处理代码怎么写？（完整示例）

不是每个异常都要单独捕获，判断标准只有一个：这个异常能不能影响我的下一步行为？

能影响就单独捕获，不知道怎么处理就交给父类统一兜底。

import requests

try:
    response = requests.get(url, timeout=10)
    response.raise_for_status()
except requests.Timeout:
    # 超时可能要重试，或切换代理
    print("请求超时")
except requests.HTTPError:
    # 状态码不对，业务层处理
    print(f"HTTP 错误：{response.status_code}")
except requests.RequestException:
    # 其他所有 requests 异常统一兜底
    print("请求失败")
else:
    # 没有异常，正常处理结果
    print(response.text)

注意：RequestException 一定要写在最后，写在前面会直接拦截所有异常，子类捕获永远不会生效。

一句话记住异常处理精髓

异常按阶段理解，捕获按需细分，RequestException 最后兜底。

这套思路不只适用于 requests，写任何网络请求的代码都用得上。

常见问题

requests 超时了怎么办？

设置 timeout 参数。推荐分开设置连接超时和读取超时：requests.get(url, timeout=(3, 10))，连接超时 3 秒，读取超时 10 秒。如果没有设置 timeout，请求会无限等待直到服务器响应。

ConnectionError 和 Timeout 哪个先处理？

建议优先捕获 Timeout，因为超时更常见，而且可能是临时性网络问题，可以考虑重试。ConnectionError 通常意味着网络本身不通或者服务器不可达，重试的意义不大。但具体顺序可以根据业务需求调整。

requests 报 SSL 错误怎么解决？

如果是证书验证失败，可以传 verify=False 临时跳过验证（仅限开发环境）：

requests.get(url, verify=False)

如果是证书过期或者域名不匹配，应该检查 URL 是否正确，或者更新本地的 CA 证书 bundle。生产环境不建议关闭证书验证。

为什么状态码 404 不会抛异常？

requests 默认不会对任何状态码抛异常，2xx 和 4xx/5xx 都会正常返回响应。如果希望在非 2xx 时自动抛异常，记得加上 response.raise_for_status()。

代理设置后报 ProxyError 怎么办？

先检查代理地址和端口是否写对（格式如 http://ip:port），确认代理本身是否可用。也可以先在本地终端用 curl 测试代理是否正常工作。如果代理需要认证，记得在 URL 里带上用户名和密码：http://user:pass@ip:port。

捕获所有异常用哪个？

用 requests.RequestException，它是所有 requests 异常的父类，捕获它就能兜住全部情况。注意一定要放在子类异常（Timeout、HTTPError 等）之后，否则子类永远不会被命中。

网页源代码和 Elements 有什么区别？静态页面与动态页面怎么判断

Sun, 17 May 2026 00:00:00 GMT

先说结论

网页源代码和 Elements 不是一回事。

网页源代码：服务器最初返回的 HTML 文档。
Elements 面板：浏览器当前实时渲染出来的 DOM 结构。

这两个内容经常很像，但它们的来源、用途和变化方式都不一样。

网页源代码是什么

网页源代码是浏览器从服务器拿回来的原始 HTML。

它的特点是：

来自网络响应。
通常是静态文本。
反映的是页面最初的返回结果。

你可以把它理解成“施工图纸”。它告诉你浏览器最开始收到了什么，而不是页面最后变成了什么。

Elements 面板是什么

Elements 面板展示的是浏览器当前正在使用的 DOM。

它的特点是：

会随着 JavaScript 改变而变化。
会反映当前页面真实结构。
可以看到动态插入、删除或修改后的内容。

这也是为什么你在页面上改一个元素的文本，Elements 会立刻更新，但网页源代码通常不会变。

为什么两者会不一样

原因很简单：JavaScript 会在页面加载后继续修改 DOM。

可能的情况有三种：

HTML 一开始就把数据写好了。
JavaScript 后面请求接口，再把数据插入页面。
JavaScript 修改了原有节点的内容或结构。

所以你在页面上看到的内容，不一定是服务器最初返回的 HTML 里就有的。

`$0` 是什么

在开发者工具里，你选中的那个元素，控制台里可以用 $0 直接引用。

这在调试时非常方便，比如：

快速查看当前选中元素。
修改元素文本。
临时测试样式和结构。

它本质上就是浏览器给你的一个便捷入口，帮助你更快操作当前选中的节点。

静态页面和动态页面怎么区分

静态页面

静态页面指的是：目标数据直接写在 HTML 里，浏览器拿到源代码就能看到。

这种页面的特点是：

数据在源代码里能找到。
不依赖复杂的 JavaScript 渲染。
直接请求 HTML 往往就能拿到主要内容。

动态页面

动态页面指的是：页面内容由 JavaScript 后续生成或填充。

这种页面的特点是：

源代码里可能看不到目标数据。
Elements 里通常能看到最终结果。
需要进一步分析 JavaScript 或 Network 请求。

怎么快速判断一个页面属于哪一种

你可以按下面这几个步骤看：

先在页面上找到目标数据。
打开网页源代码，看数据是否已经存在。
如果源代码没有，再去 Elements 面板找。
如果 Elements 里有，说明内容大概率是动态生成的。
再切到 Network 面板，刷新页面，看是不是接口返回了这些数据。

这套方法对爬虫分析非常实用，因为它直接决定你下一步该怎么抓数据。

为什么爬虫一定要分清这两个视图

很多爬虫问题，根源不是“代码写错了”，而是找错了数据来源。

如果你把源代码当成最终页面，就可能：

误以为数据不存在。
错过真正返回数据的接口。
在错误的 HTML 结构上浪费时间。

所以，先分清“源代码”和“实时 DOM”，你后面的分析效率会高很多。

一个非常实用的判断口诀

你可以记成这样：

源代码看起点，Elements 看结果。

如果页面上有数据，源代码没有，那就优先考虑 JavaScript 动态渲染。如果页面上和源代码一致，那它更像静态页面。

和浏览器加载流程的关系

这篇内容其实是上一节的延伸。

浏览器先拿到 HTML，再加载资源，再执行 JavaScript。而 Elements 面板展示的，就是这一整套过程结束后的最终状态。

所以你在学完页面加载流程之后，再回头看源代码和 Elements，就会突然清楚很多。

总结

网页源代码、Elements、静态页面、动态页面，这四个概念一定要一起理解：

源代码是服务器返回的原始 HTML。
Elements 是浏览器当前实时 DOM。
静态页面的数据通常在 HTML 里。
动态页面的数据通常由 JavaScript 后续生成。

这篇文章读完后，你在分析网页时，应该能更快判断： 是直接看 HTML，还是要去找 JavaScript 和接口。

配合前两篇一起看，会更完整：

浏览器输入 URL 后发生了什么？页面加载流程全解析

Sun, 17 May 2026 00:00:00 GMT

浏览器输入 URL 后要经历哪些步骤？

很多人以为"输入 URL 回车"只是打开了一个网页，其实浏览器在背后做了很多事。

如果把整个过程拆开，它大致会经历这几个阶段：

处理 URL。
发起网络请求。
拿到 HTML 文档。
继续加载 CSS、图片、JavaScript 等资源。
执行 JavaScript，生成或修改页面内容。
页面渲染完成。

理解这条流水线，对爬虫学习特别重要。因为你后面判断"数据到底来自哪里"，本质上就是在判断它落在这条流水线的哪个环节。

第一步：浏览器怎么处理 URL？

当你在地址栏输入一个网址后，浏览器并不是立刻发请求，它会先做一轮标准化处理。

常见处理包括：

补全协议，比如自动加上 http:// 或 https://。
对非 ASCII 字符做 URL 编码。
把最终地址整理成可以真正发请求的完整 URL。

这里最关键的一点是：浏览器真正发送请求时，用的一定是完整 URL。

也就是说，浏览器输入框里看起来"像地址"的东西，和真正能发出去的地址，不一定是同一个形态。

第二步：浏览器怎么向服务器发起请求？

URL 处理完成后，浏览器会向服务器发起 GET 请求。

如果服务器正常返回，浏览器会收到一个响应。这个响应里最核心的是响应头和响应体：

响应头告诉浏览器"这是什么类型的内容"。
响应体里装着真正的资源内容。

对于你在地址栏输入的网页来说，服务器通常先返回的是 HTML 文档。

第三步：浏览器怎么根据 Content-Type 处理内容？

浏览器不会只看文件后缀，它更在意响应头里的 Content-Type。

如果响应头告诉它这是 text/html，浏览器就会把返回内容当作 HTML 来解析。如果是 CSS，就按 CSS 处理。如果是 JavaScript，就交给 JS 引擎执行。

这就是为什么同样是一个地址，返回不同 Content-Type 时，浏览器会表现出完全不同的行为。

第四步：HTML 是怎么被解析的？

浏览器拿到 HTML 后，会从上到下顺序解析。

解析过程中，它会遇到不同类型的标签：

link：通常引用 CSS。
img：通常引用图片。
script：通常引用 JavaScript。
a：默认不会自动发请求，要等用户点击。

这一步很像浏览器边读边做决定。看到一个资源，就根据资源类型继续往下处理。

第五步：CSS、图片、JS 等资源是怎么加载的？

当浏览器解析到 link、img、script 这类资源引用时，它会继续发请求去拿这些内容。

这里经常会遇到一个细节：路径不一定写的是完整 URL。这时候就要先分清 绝对路径 和 相对路径。

比如：

这些路径如果不是完整 URL，浏览器就会先补全，再去请求。

想把这块理解得更扎实，可以继续看绝对路径和相对路径是什么？浏览器如何补全资源地址。

第六步：JavaScript 怎么改变页面内容？

当浏览器拿到 JavaScript 文件后，会把它交给 JS 引擎执行。

JavaScript 执行后，页面可能发生这些变化：

新增元素。
删除元素。
修改文本。
请求接口并把接口结果渲染到页面上。

所以你在页面上看到的内容，并不一定都来自最初返回的 HTML。

这点对爬虫特别关键，因为它直接决定了你是要：

直接解析 HTML。
还是去分析 JavaScript 发起的接口请求。

第七步：为什么源代码和页面内容不一样？

很多初学者第一次看浏览器开发者工具时，都会有这个疑问： "页面上明明有内容，为什么查看网页源代码却找不到？"

原因很简单：

网页源代码看到的是服务器最初返回的 HTML。
页面上看到的是浏览器执行完 JavaScript 之后的最终结果。

也就是说，源代码是"起点"，页面上的内容是"结果"。

如果某些数据是 JS 动态生成的，源代码里可能完全没有，但 Elements 面板里已经出现了。

第八步：Elements 面板展示的是什么？

浏览器里的 Elements 面板看到的，不是静态文本，而是当前实时的 DOM 结构。

你可以在控制台里选中一个元素，然后通过 $0 快速引用它。

比如你修改了 $0 的文本内容，Elements 面板会立刻变化。但这并不意味着网页源代码也变了，因为源代码还是服务器返回的原始 HTML。

这就是"源代码"和"当前页面 DOM"之间最重要的区别。

第九步：怎么判断一个页面是不是动态页面？

如果你想快速判断一个页面是不是动态页面，可以按这个顺序观察：

先看页面上有没有目标数据。
再看网页源代码里有没有。
如果源代码没有，但页面上有，去 Elements 面板看。
如果 Elements 里有，大概率是 JavaScript 生成或渲染的。
再去 Network 面板找对应接口。

这个判断顺序，基本能覆盖大多数网页数据源分析场景。

如果你想继续分清"源代码"和"Elements"到底差在哪，可以接着看网页源代码和 Elements 有什么区别？静态页面与动态页面怎么判断。

浏览器页面加载流程怎么记最实用？

你可以把页面加载流程记成一句话：

URL 先被浏览器整理，HTML 先被拉回来，资源继续补齐，JavaScript 再把页面"活"起来。

只要这条主线清楚了，你后面学抓包、接口复现、静态页和动态页判断，都会顺很多。

总结

浏览器输入 URL 后发生的事，不是"打开一个页面"这么简单，而是一整套连续动作：

处理 URL。
请求 HTML。
解析资源。
执行 JavaScript。
渲染最终页面。

这篇文章最重要的价值，是帮你建立一个判断框架。当你以后面对任何网页时，都可以先问自己：这个数据是在 HTML 里，还是在 JavaScript 之后才出现的？

绝对路径和相对路径是什么？浏览器如何补全资源地址

Sun, 17 May 2026 00:00:00 GMT

先记住一个前提

只有完整 URL 才能真正发起网络请求。

浏览器看到的路径写法可以很多，但真正发给服务器的，必须是它自己补全后的完整地址。

所以你在页面里看到的 ./css/main.css、/css/main.css、//example.com/main.css，只是写法不同。浏览器最终都会把它们整理成完整 URL，再去请求资源。

什么是绝对路径

绝对路径的特点是：它本身就能定位资源。

常见写法有三种：

https://tc.xfei.tech/web/css/styles.css
//tc.xfei.tech/web/css/styles.css
/web/css/styles.css

这三种写法的共同点是：浏览器都有办法把它们补成完整 URL。

1）完整 URL

最完整的写法就是协议、域名、路径都齐全。

https://tc.xfei.tech/web/css/styles.css

这类地址可以直接请求，几乎不会产生歧义。

2）协议相对写法

//tc.xfei.tech/web/css/styles.css

这种写法省略了协议，浏览器会自动继承当前页面使用的协议。如果当前页面是 HTTPS，最终就会补成 HTTPS。

3）根路径写法

/web/css/styles.css

这种写法从站点根目录开始找资源，和当前页面所在的子目录无关。

什么是相对路径

相对路径的特点是：它必须依赖当前页面地址来补全。

常见写法有：

css/styles.css
./css/styles.css
js/app.js
./logo.svg

它们本身不是完整地址，单独拿出来不能直接请求。浏览器必须先知道“当前页面在哪个目录下”，然后才能把它补成完整 URL。

浏览器到底是相对谁

相对路径相对的不是“整个网站”，而是当前页面的 URL 所在目录。

例如当前页面是：

https://tc.xfei.tech/web/index.html

那么：

css/styles.css
./css/styles.css

最终都会被补成：

https://tc.xfei.tech/web/css/styles.css

这也是为什么很多人第一次写路径会出错。他以为路径是相对网站根目录，实际上它是相对当前页面目录。

浏览器如何补全路径

浏览器补全路径时，通常会按这几个步骤理解：

先拿到当前页面的完整地址。
找到当前页面所在目录。
把相对路径拼到这个目录后面。
得到最终可请求的完整 URL。

如果你把这个机制想明白了，很多“资源 404”问题就会立刻变得清晰。

在页面里最常见的几种资源引用

CSS

图片

JavaScript

这些写法都很常见，而且都依赖浏览器补全。

如果路径写错了，最直接的结果就是资源加载失败。所以分析页面时，除了看标签本身，还要看它引用资源的路径是否正确。

为什么绝对路径在分析页面时很省心

绝对路径最大的优点是稳定。

不管当前页面在哪个目录，只要路径是绝对的，浏览器请求的目标都不会变。这对于静态站点、后台管理页、以及很多爬虫脚本里的资源定位都很有帮助。

相对路径虽然写起来短，但当页面目录结构变化时，出错概率更高。

路径分析时最容易混淆的点

1）`/` 开头不等于相对路径

很多初学者会把 /css/main.css 看成“相对当前文件”的路径，其实不是。它是从站点根目录开始的绝对路径。

2）`./` 和不写 `./` 很接近

css/styles.css
./css/styles.css

这两种在多数场景下效果几乎一样，都是相对路径。

3）协议相对写法会继承当前协议

//tc.xfei.tech/web/css/styles.css

这个写法会直接继承页面协议，所以调试时要特别注意它最终是 http 还是 https。

一个很实用的排查方法

当你发现资源加载失败，可以按这个顺序排查：

先看路径是不是完整 URL。
如果不是，判断它是绝对路径还是相对路径。
如果是相对路径，确认当前页面目录是什么。
把路径手动补成完整 URL。
直接在浏览器里打开，看资源是否真的存在。

这套方法不仅适用于网页资源，也适用于你后面做爬虫时分析接口路径。

一句话总结

你可以这样记：

绝对路径自己就能指路，相对路径要靠当前页面补全。

只要你能把这个规则记牢，浏览器为什么能加载 CSS、图片和脚本，基本就能讲通了。

这篇内容和浏览器输入 URL 后发生了什么？页面加载流程全解析是一组，建议顺着一起看。

HTTP/1.0、HTTP/1.1、HTTP/2、HTTP/3 差异详解（含队头阻塞）

Thu, 14 May 2026 00:00:00 GMT

为什么要理解 HTTP 版本演进

很多网络问题看起来像“代码问题”，本质却是协议机制差异导致的。尤其在抓包和性能分析场景里，搞清 HTTP/1.0 到 HTTP/3 的演进，会让你更快判断瓶颈在哪里。

HTTP/1.0：一次请求一次连接

HTTP/1.0 的典型特征是短连接：

发一个请求，建立一次 TCP 连接。
请求完成后，连接立即关闭。

问题在于 TCP 建连和断连都有成本。页面资源一多，这个成本会被不断放大。

HTTP/1.1：长连接提升复用效率

HTTP/1.1 引入 Keep-Alive，让多个请求复用同一个 TCP 连接，减少反复握手与挥手开销。

这是非常关键的一步优化，但它并没有彻底解决并发效率问题。

HTTP/1.1 的核心痛点：队头阻塞

在同一个连接内，请求与响应的处理顺序强相关。前面的请求慢，后面的请求就会被拖住，这就是 HTTP 层面的队头阻塞。

浏览器常见绕法是开多个 TCP 连接并行请求，但这也会带来额外连接成本。

HTTP/2：二进制分帧 + 多路复用

HTTP/2 的关键变化是把传输单位从“整段文本报文”改为“二进制帧（Frame）”。

一个完整请求/响应被组织为一个流（Stream）。
每个帧标记所属流编号。
多个流可在同一 TCP 连接上交错传输。

这让 HTTP 层面的队头阻塞得到明显缓解。

HTTP/2 另一个关键优化：头部压缩

HTTP/2 通过静态表 + 动态表压缩头字段，减少重复传输开销。高频字段可用索引表达，不必每次完整传输。

参考规范： RFC 7541 静态表定义

HTTP/2 仍然存在的问题：TCP 队头阻塞

HTTP/2 虽然解决了应用层请求乱序匹配的问题，但底层仍依赖 TCP。一旦 TCP 某个分段丢包，后续数据即使已到达，也要等待重传完成。

这就是传输层队头阻塞。

HTTP/3：基于 QUIC，面向传输层问题优化

HTTP/3 将底层从 TCP 切换到 UDP，并通过 QUIC 提供可靠传输能力。目标是把连接管理、重传、多路机制做得更适合现代网络环境。

常见收益包括：

握手更快。
连接 ID 支持网络切换时更平滑地延续会话。
更好地缓解传输层阻塞影响。

版本差异速览

HTTP/1.0：短连接，连接成本高。
HTTP/1.1：长连接复用，但同连接内易队头阻塞。
HTTP/2：二进制分帧、多路复用、头部压缩，解决应用层阻塞痛点。
HTTP/3：基于 QUIC，重点改善传输层阻塞与连接体验。

对爬虫和接口调试的实际价值

理解版本差异后，你在抓包里看到“慢”时会更清楚该看哪里：

如果是大量短连接，先怀疑连接复用不足。
如果同连接串行等待明显，关注 HTTP/1.1 队头阻塞。
如果上层并发正常但仍卡，考虑 TCP 丢包和传输层影响。
协议版本不同，开发者工具可见信息也不同，分析方式要跟着调整。

总结

HTTP 版本演进，本质是在不断降低网络通信中的结构性开销和阻塞成本。当你把“问题发生在应用层还是传输层”区分清楚，调试效率会明显提升。

HTTP 协议入门：请求、响应、状态码（爬虫视角）

Thu, 14 May 2026 00:00:00 GMT

为什么爬虫一定要先学 HTTP

爬虫本质不是“神秘技术”，而是一个自动发请求、收响应的客户端程序。你能不能把请求发对、把响应看懂，直接决定了爬虫项目能不能跑起来。

所以在学代码之前，先吃透 HTTP 的通信格式，后面抓包、接口复现、反爬排查都会轻松很多。

HTTP 的两个核心特性

无状态：每次请求默认独立，服务端不会天然记住你上一次做过什么。
文本协议（HTTP/1.x 视角）：请求与响应按规范组织成可读文本结构。

无状态意味着什么？你上一次请求成功，不代表下一次自动成功。Cookie、Token、会话参数，都需要你在后续请求里明确带上。

请求报文怎么读：三段式结构

一个完整 HTTP 请求可分为三部分：

请求行
请求头
请求体

其中，请求头和请求体之间必须有一个空行，这是协议格式要求。

1）请求行：先看“你要做什么”

请求行通常包含：请求方法 + 路径 + 协议版本。爬虫里最常见的方法是：

GET：拿数据
POST：提交数据

很多登录、注册、搜索提交会用 POST，并把参数放进请求体。

2）请求头：再看“你是谁，从哪来”

请求头是键值对集合，用来补充请求上下文。初学爬虫先重点看这几个：

User-Agent：声明客户端环境（浏览器/系统）。
Referer：说明当前请求来源页面。
Cookie：携带会话态与业务标识。

请求失败时，先别急着改代码，先对比浏览器和脚本这三个头是否一致，往往就能快速定位问题。

3）请求体：业务数据放这里

请求体是提交给服务端的业务内容。 GET 通常没有请求体，POST 更常见有请求体。

响应报文怎么读：同样三段式

响应结构也分三部分：

响应行
响应头
响应体

响应头和响应体之间同样有空行分隔。

响应行：状态判断的第一现场

响应行包含：协议版本 + 状态码 + 状态描述。在爬虫排错里，状态码是第一优先级信息。

常见状态码速查（爬虫高频）

2xx：成功

200 OK：请求成功并返回结果。

3xx：重定向

301 Moved Permanently：永久重定向，浏览器通常会缓存。
302 Found：临时重定向，通常每次都要重新请求旧地址。

4xx：客户端请求问题

400 Bad Request：请求格式或参数错误。
401 Unauthorized：未授权，常见于未登录或登录失效。
403 Forbidden：请求被拒绝，常见于权限不足或风控拦截。
404 Not Found：路径错误或资源不存在。
429 Too Many Requests：请求过快，被限流。

5xx：服务端错误

500 系列通常表示服务端内部处理失败。

更多状态码参考： MDN HTTP 状态码文档

一个实战中常见的坑

状态码 200 不等于业务成功。很多站点会返回 200，但在响应体里给出“未登录”“签名错误”“访问频繁”等业务错误信息。

所以排错顺序建议固定为：

先看状态码
再看响应头（例如 Content-Type）
最后看响应体的真实业务内容

给初学者的请求排查流程

遇到“脚本拿不到数据”时，按这个流程走：

在浏览器开发者工具定位同一请求。
对比 URL、方法、参数是否一致。
对比关键请求头：User-Agent、Referer、Cookie。
对比状态码与响应体错误提示。
观察是否出现 301/302 跳转或 429 限流。

这个流程跑通后，你会发现大多数“玄学问题”都能落到明确字段差异上。

总结

学 HTTP 不是背概念，而是为了把请求发送和响应解读变成可重复的工程动作。把请求结构、响应结构、状态码这三块打牢，爬虫入门就完成了一半。

HTTP 请求头与响应头实战：User-Agent、Referer、Cookie、Content-Type

Thu, 14 May 2026 00:00:00 GMT

为什么 HTTP 头字段决定了爬虫成败？

很多同学会遇到这种情况：浏览器访问正常，脚本请求却失败。最常见原因不是 URL 写错，而是 HTTP 头信息不完整或不一致。

在爬虫场景里，头字段可以理解为"请求的上下文身份信息"。服务端经常根据这些信息做鉴权、风控和内容分发。

HTTP 请求头要看哪 3 个？

User-Agent 是什么？声明客户端身份有什么用？

User-Agent 用于告诉服务端"我是哪个浏览器/设备发起的请求"。许多站点会根据它做基础策略判断，缺失或异常可能直接触发拦截。

实战建议：

先复用浏览器真实 User-Agent。
批量采集时保持同一会话内稳定，避免频繁切换。
如果返回异常页，优先检查 User-Agent 是否丢失。

Referer 是什么？为什么重要？

Referer 表示当前请求来自哪个页面。部分接口会要求"必须从特定页面跳转而来"，否则直接拒绝。

实战建议：

先在浏览器抓包确认真实 Referer。
请求链路中涉及详情页、播放页、下载页时重点检查。
出现 403 时，把 Referer 放到首批排查项。

Cookie 是会话状态的核心载体。登录后拿到的数据，脚本如果不带对应 Cookie，大概率会变成未登录视图或直接报错。

实战建议：

把 Cookie 视为"会话钥匙"，注意时效和刷新。
优先使用会话对象自动管理 Cookie，而不是手写拼接。
当响应提示未授权时，先检查 Cookie 是否过期或缺字段。

响应头为什么要先看 Content-Type？

Content-Type 告诉你响应体是什么格式。例如：

text/html; charset=utf-8：HTML 页面
application/json：JSON 数据
image/webp：图片资源

它对爬虫的价值主要有两点：

判断当前拿到的是"真实业务数据"还是"跳转页/错误页"。
判断解码方式，避免乱码或解析失败。

为什么不能只看状态码，还要看响应头？

很多请求返回 200，但实际上拿到的是登录页 HTML，而不是目标 JSON。这时候如果不看 Content-Type，你会误以为接口成功，后续解析才报错。

正确做法是：

先看状态码
再看 Content-Type
最后根据类型选择解析策略（HTML 解析或 JSON 解析）

如何用请求头与响应头联动排错？

当你遇到"浏览器有数据，脚本没数据"时，按顺序检查：

URL、请求方法是否一致。
请求参数（query/body）是否一致。
User-Agent 是否缺失或异常。
Referer 是否符合来源要求。
Cookie 是否有效且完整。
响应状态码是否异常（尤其 401/403/429）。
Content-Type 是否符合预期。

这 7 步能覆盖大部分接口复现失败场景。

浏览器开发者工具怎么用来排查爬虫请求？

建议固定在 Network 面板做三件事：

找到目标请求（先看 document，再定位 xhr/fetch）。
查看 Headers，记录关键请求头和响应头。
对照脚本请求逐项比对，不一致就先改一致。

只要你养成"先抓包，再写代码，再比对"的习惯，排错成本会明显下降。

总结

HTTP 头字段不是细枝末节，而是爬虫请求能否通过服务端校验的基础。把 User-Agent、Referer、Cookie、Content-Type 这四项吃透，接口复现成功率会有非常明显的提升。

网页由什么组成？HTML、CSS、JavaScript 入门（爬虫必学）

Thu, 14 May 2026 00:00:00 GMT

为什么爬虫要先学网页基础？

很多同学学爬虫时，会急着上手 requests、BeautifulSoup、Scrapy，但一打开网页源代码就懵了：标签、属性、样式、脚本混在一起，到底哪个才是我要抓的数据？

所以在写爬虫之前，先搞懂网页由什么组成非常重要。你不需要一开始就成为前端工程师，但至少要知道网页里哪些内容负责结构、哪些内容负责样式、哪些内容负责交互。

一个普通网页，核心由三部分组成：

HTML
CSS
JavaScript

可以把它们理解成一套房子：

HTML 是毛坯房，负责基础结构。
CSS 是装修方案，负责页面长相。
JavaScript 是智能控制系统，负责交互和逻辑。

HTML 是什么？网页的骨架是怎么组成的？

HTML 全称是 HyperText Markup Language，中文叫超文本标记语言。注意，它是"标记语言"，不是"编程语言"。

这意味着 HTML 本身不负责复杂逻辑判断，它主要负责描述网页结构。例如页面上的标题、段落、图片、链接、按钮，都可以用 HTML 标签表示。

一个最基础的 HTML 页面大概长这样：



  
    
    我的第一个网页
  
  
    爬虫你好
    这是一个简单的网页。
    访问文档

这里面有几个关键部分：

：声明这是一个 HTML 文档。
：整个网页的根元素。
：网页配置区，例如编码、标题、样式引用。
：网页内容区，用户真正能看到的内容通常在这里。

从爬虫角度看，HTML 是最重要的基础。因为很多页面数据，最终都会以 HTML 标签和文本的形式出现在页面结构里。

CSS 是什么？网页装修是怎么实现的？

只有 HTML 的页面通常很朴素，就像只有墙体和门窗的毛坯房。如果想让网页变好看，就需要 CSS。

CSS 全称是 Cascading Style Sheets，中文叫层叠样式表。它负责控制网页的视觉表现，例如：

字体大小
文字颜色
背景颜色
图片尺寸
按钮圆角
页面布局
鼠标悬停效果

例如：

h1 {
  color: #1f2937;
  text-align: center;
}

button {
  padding: 10px 16px;
  border-radius: 999px;
  background: #111827;
  color: white;
}

CSS 本身不改变网页"有什么内容"，它改变的是这些内容"怎么显示"。同一份 HTML，换一套 CSS，视觉效果可能完全不同。

对爬虫来说，CSS 还有一个额外价值：它会用到选择器。选择器不仅能选中元素来改样式，以后我们也会用类似写法在 Python 或浏览器里定位要抓取的数据。

JavaScript 是什么？网页交互和逻辑是怎么实现的？

如果说 HTML 让网页"能看"，CSS 让网页"好看"，那么 JavaScript 就是让网页"能动起来"。

JavaScript 是一门真正的编程语言。它可以处理：

点击按钮后弹出提示。
鼠标划过后展开菜单。
输入框实时校验格式。
页面滚动时加载更多数据。
请求接口并把结果渲染到页面上。

例如：

这段代码做了三件事：

用 querySelector 选中按钮。
给按钮注册点击事件。
点击后创建一个新的 p 元素并插入页面。

这就是 JavaScript 的作用：处理交互，操作页面结构。

为什么浏览器内容和网页源代码不一样？

初学爬虫时，一个常见困惑是：浏览器里明明有数据，但右键查看网页源代码却找不到。

原因往往是：这些数据不是 HTML 初始返回的，而是 JavaScript 后续请求接口再渲染出来的。

也就是说，网页内容可能有两种来源：

服务端直接返回在 HTML 里。
JavaScript 在浏览器运行后，再请求接口并动态插入页面。

这会影响爬虫策略：

如果数据在 HTML 里，可以直接请求页面并解析 HTML。
如果数据由 JavaScript 动态加载，需要去 Network 面板找接口。
如果接口有复杂参数，可能还要分析请求头、Cookie、签名逻辑。

所以网页基础不是"前端知识点"，而是爬虫判断数据来源的前置能力。

爬虫怎么观察网页？有什么标准顺序？

打开一个网页后，建议按这个顺序观察：

先看页面上有没有目标数据。
右键查看网页源代码，确认数据是否在原始 HTML 中。
打开开发者工具 Elements 面板，观察元素结构。
打开 Network 面板，刷新页面，看是否有接口返回目标数据。
如果页面点击后才出现数据，重点观察对应点击触发了哪些请求。

这个顺序能帮你快速判断：应该解析 HTML，还是应该复现接口。

HTML、CSS、JavaScript 和爬虫有什么关系？

把三者放到爬虫语境里，可以这样理解：

HTML：最常见的数据承载结构。
CSS：提供定位元素的选择器思路。
JavaScript：解释动态加载、交互行为和接口请求来源。

很多爬虫问题看似是代码问题，其实是网页认知问题。当你知道一个页面由结构、样式和交互三层组成，就不会只盯着页面表面，而会开始追问：数据到底是从哪里来的？

总结

网页基础可以先抓住一句话：

HTML 搭结构，CSS 改样式，JavaScript 做交互。

对爬虫学习者来说，最重要的不是把所有前端语法背下来，而是建立判断力：看到一个页面，能分清内容在哪里、样式怎么选中元素、交互背后可能触发了什么请求。

这个判断力一旦建立，后面学 HTML 解析、CSS 选择器、接口抓包和 JavaScript 逆向都会顺很多。

延伸阅读：如果你还没建立客户端和服务器的概念，可以先看 URL 是什么？从客户端与服务器讲透爬虫第一步。

DOM 树是什么？节点、父子关系与兄弟关系详解

Thu, 14 May 2026 00:00:00 GMT

为什么要理解 DOM 树

学爬虫时，你迟早会遇到这样的问题：页面上有很多相似的标题、图片、按钮和链接，怎么才能准确选中自己想要的那一个？

答案通常不只是“看标签名”，而是要看它在整个页面结构里的位置。这就需要理解 DOM 树。

DOM 树能帮你回答这些问题：

某个元素在页面结构的哪一层？
它的外层容器是谁？
它旁边有哪些同级元素？
它内部还有没有更深层的子元素？
选择器为什么能选中它，或者为什么选不中它？

DOM 是什么

DOM 全称是 Document Object Model，中文通常叫文档对象模型。你可以把它理解为：浏览器把 HTML 文档解析后，生成的一棵结构树。

HTML 源代码是文本，浏览器不能只把它当普通字符串处理。浏览器会把标签、属性、文本、注释等内容解析成一个个节点，再按嵌套关系组织起来。

这棵树，就是 DOM 树。

什么是节点

在 HTML 中，很多东西都可以被看作节点（Node），例如：

文档本身是节点。
元素是节点，例如 html、head、body、h1、p。
属性也可以被理解为节点信息，例如 id、class、href。
文本是节点，例如标题里的文字。
注释也是节点。

例如下面这段 HTML：


  爬虫你好
  这是一个段落。
  访问文档

可以简单理解为：

div 是一个元素节点。
h1、p、a 是 div 里面的子元素节点。
class="container"、id="title"、href="..." 是节点上的属性信息。
爬虫你好、这是一个段落。、访问文档 是文本内容。

父节点、子节点和兄弟节点

DOM 树最重要的是节点关系。新手先掌握三种关系就够了：

父节点
子节点
兄弟节点

父节点：包住当前节点的上一层

如果一个元素在另一个元素里面，那么外层元素就是它的父节点。


  爬虫你好

在这段结构里，body 是 h1 的父节点。

子节点：被当前节点直接包住的下一层

反过来看，h1 是 body 的子节点。如果一个节点直接出现在另一个节点内部，它就是直接子节点。


  
  电影标题

这里 img 和 h2 都是 div.card 的子节点。

兄弟节点：拥有同一个父节点的同级节点

如果多个元素被同一个父元素包住，它们就是兄弟节点。


  电影标题
  电影简介
  查看详情

这里 h2、p、a 都在同一个 div.card 里面，所以它们是兄弟节点。

DOM 树为什么是一棵树

HTML 是层层嵌套的结构。一个文档里有 html，html 里有 head 和 body，body 里又有各种标题、段落、图片、按钮。

它看起来就像一棵倒过来的树：

document 是整棵树的入口。
html 是页面的根元素。
head 和 body 是 html 的子节点。
body 下面继续分出更多内容节点。

除了根节点外，每个节点通常都有自己的父节点，也可能拥有多个子节点或兄弟节点。

DOM 树和选择器有什么关系

选择器的本质，就是在 DOM 树里找到目标节点。

例如：

.container img {
  border-radius: 12px;
}

这句 CSS 的意思不是“随便找一张图片”，而是：

先找到类名为 container 的元素。
再去它内部找所有 img 后代元素。

这就是基于 DOM 层级关系的查找。

再看一个例子：

.card > img {
  width: 160px;
}

这里的 > 表示只找直接子元素。如果图片藏在更深层的 div 里面，就不会被选中。

所以，想写准选择器，就必须先看懂 DOM 树。

爬虫里怎么利用 DOM 树

假设页面结构是这样的：


  
  星际穿越
  9.4
  查看详情

如果你要抓电影标题，不能只想“抓 h2”，因为页面上可能有很多 h2。更稳的思路是：

先定位每一个 .movie-card。
再在每个卡片内部找 .title、.score、.detail。
把同一个卡片里的标题、评分、链接组合成一条数据。

这就是爬虫里非常常见的“先定位列表项，再提取字段”的思路。

常见误区：只看页面，不看结构

浏览器展示出来的是视觉结果，DOM 树展示的是结构关系。视觉上挨得很近的两个元素，不一定在 DOM 中就是兄弟节点；视觉上隔得很远的元素，也可能在同一个父容器里。

所以爬虫调试时，不要只凭页面肉眼判断。更可靠的做法是打开开发者工具，在 Elements 面板里观察真实结构。

建议养成这个习惯：

先选中页面上的目标文字。
在 Elements 面板里查看它所在的标签。
向上找外层容器。
判断它和其他字段之间的父子、兄弟关系。
再决定用什么选择器。

总结

DOM 树是浏览器理解网页结构的方式，也是爬虫定位数据的地图。

你只要先掌握这三组关系：

父节点：外层包住当前节点的节点。
子节点：当前节点直接包住的下一层节点。
兄弟节点：拥有同一个父节点的同级节点。

再配合 CSS 选择器，就能从“看见页面”进一步走到“准确定位数据”。这一步打牢后，后面学 HTML 解析、XPath、CSS Selector 和动态页面抓包都会更轻松。

CSS 选择器入门：从改样式到爬虫数据定位

Thu, 14 May 2026 00:00:00 GMT

爬虫为什么要学 CSS 选择器？

CSS 选择器最早是用来给网页元素加样式的。例如选中标题改颜色，选中按钮加圆角，选中图片设置大小。

但对爬虫来说，选择器还有一个更重要的作用：定位数据。

当你要从网页里提取标题、图片、链接、价格、评分时，本质上都在做同一件事：从 DOM 树里选中目标元素，再取出里面的文本或属性。

所以选择器不是前端专属知识，而是爬虫入门必须掌握的基础能力。

CSS 选择器有哪三种写法？

在了解选择器之前，先看 CSS 代码可以写在哪里。

内联样式怎么写？

内联样式直接写在元素的 style 属性里，只影响当前元素。

爬虫你好

这种写法很直观，但不适合大量复用。

内部样式表怎么写？

内部样式表写在 head 里的 style 标签中。

这里的 h1 就是元素选择器，它会选中页面上所有 h1 元素。

外部样式表怎么引入？

外部样式表写在独立的 CSS 文件里，再通过 link 引入。

大型网站通常会使用外部样式表，方便维护和复用。

CSS 基础选择器有哪些？元素、类、ID 怎么用？

基础选择器先掌握三类：

元素选择器
类选择器
ID 选择器

元素选择器怎么用？

元素选择器直接写标签名，会选中页面上所有同类型元素。

h1 {
  color: red;
}

如果要同时选中多个标签，可以用逗号分隔：

a,
img,
button {
  display: block;
}

在爬虫中，元素选择器适合粗略定位，例如先拿到所有链接：

但它通常不够精确，因为页面上可能有大量相同标签。

类选择器怎么用？

类选择器用点号 . 开头，后面跟类名。

.container {
  display: flex;
}

它会选中所有 class 包含 container 的元素。

HTML 里可以这样写：

内容区域

类选择器在爬虫里非常常用。例如很多列表卡片会有稳定的类名：

.movie-card

如果你想批量提取列表数据，通常会先选中每个卡片容器。

ID 选择器怎么用？

ID 选择器用井号 # 开头。

#btn {
  background: black;
  color: white;
}

HTML 中对应：

规范上，id 在同一个页面里应该唯一。所以 ID 选择器通常只选中一个元素。

在爬虫中，如果目标元素有稳定唯一的 ID，定位会非常方便。但实际网站里，很多 ID 可能由前端框架动态生成，不一定适合长期依赖。

CSS 选择器怎么组合？后代、子元素、多个类名怎么用？

真实网页结构通常不止一层，所以只会基础选择器还不够。接下来要掌握组合选择器。

后代选择器怎么用？空格代表什么意思？

后代选择器用空格表示"在它里面找"。

.container img {
  border-radius: 50%;
}

意思是：选中 .container 内部所有层级的 img 元素。不管图片是直接子元素，还是藏在更深层的容器里，只要在 .container 里面，都算后代。

爬虫场景中，后代选择器很常见：

.movie-card .title

表示在每个电影卡片里找标题。

子元素选择器怎么用？大于号和空格有什么区别？

子元素选择器用 > 表示，只选中直接子元素。

.container > img {
  width: 160px;
}

如果 img 外面还包了一层 div，这条选择器就选不中它。

它适合结构比较明确、希望避免误选更深层元素的场景。

多个类名同时匹配怎么写？

一个元素可以有多个类名：

如果要选中同时拥有这两个类名的元素，可以连着写：

.movie.featured

注意中间没有空格。如果写成 .movie .featured，意思就变成了在 .movie 里面找 .featured 后代元素。

这个区别非常重要，少一个空格和多一个空格，选择结果完全不同。

CSS 兄弟选择器怎么用？加号和波浪线有什么区别？

兄弟选择器用于选择同一层级中，某个元素后面的元素。

相邻兄弟选择器怎么用？加号选的是什么？

+ 只选中紧挨在后面的第一个兄弟元素。

a + img {
  border: 2px solid red;
}

它表示：选中紧跟在 a 后面的第一个 img。

通用兄弟选择器怎么用？波浪线选的是什么？

~ 会选中后面所有符合条件的同级元素。

a ~ img {
  border: 2px solid red;
}

它表示：选中 a 后面所有同级的 img。

兄弟选择器在爬虫里不如类选择器高频，但遇到"标题后面的价格""标签后面的值"这类结构时，会很有用。

CSS 属性选择器怎么用？能匹配链接和图片吗？

属性选择器用于根据元素属性进行匹配。它在爬虫里尤其重要，因为链接、图片、接口入口经常藏在属性里。

属性选择器有哪些常见写法？

常见写法如下：

[href]

选中所有带 href 属性的元素。

[href="https://www.xfei.tech"]

选中 href 完全等于指定地址的元素。

[href^="http"]

选中 href 以 http 开头的元素。

[href$=".tech"]

选中 href 以 .tech 结尾的元素。

[href*="xfei"]

选中 href 中包含 xfei 的元素。

属性选择器在爬虫里怎么用？

爬虫中经常会用属性选择器筛选链接，例如：

a[href*="/detail/"]

表示选中所有 href 中包含 /detail/ 的详情页链接。

CSS 伪类选择器怎么用？:not 和 :empty 能帮爬虫做什么？

伪类选择器用冒号开头，用来描述元素的特殊状态或筛选规则。

:not(...) 怎么用？怎么排除某些元素？

a:not(.doc) {
  font-size: 18px;
}

这表示选中所有不是 .doc 的 a 元素。

在数据提取中，如果你想排除某些广告链接、文档链接或空链接，:not(...) 会很方便。

:empty 怎么用？能识别空元素吗？

a:empty {
  display: none;
}

:empty 会选中没有子节点内容的元素。它可以帮助你识别页面里没有文本的空标签。

JavaScript 和 Python 怎么用 CSS 选择器查找元素？

选择器不只出现在 CSS 里。 JavaScript 也可以用选择器查找元素：

const btn = document.querySelector("#btn")
const links = document.querySelectorAll("a[href]")

后面写爬虫时，很多解析库也支持 CSS 选择器。例如在 Python 的 BeautifulSoup 里：

from bs4 import BeautifulSoup

soup = BeautifulSoup(html, "html.parser")
titles = soup.select(".movie-card .title")
links = soup.select('a[href*="/detail/"]')

你会发现，不管是 CSS、JavaScript 还是 Python，选择器的核心思想都是一样的：从 DOM 树里选中你想操作的元素。

爬虫 CSS 选择器有哪些实战技巧？

写选择器时，建议遵循这几个原则：

优先从稳定的列表容器开始选。
不要只依赖过于宽泛的标签名，例如 div、span。
类名语义清晰时，优先使用类选择器。
ID 稳定且唯一时，可以使用 ID 选择器。
提取链接和图片时，多关注 href、src、alt 等属性。
选择器越短越好，但前提是不会误选。
页面结构复杂时，先在开发者工具里验证选择结果。

一个推荐模式是：

.list-item .title

而不是：

body div div div h2

后者太依赖页面层级，一旦前端结构稍微调整，就容易失效。

总结

CSS 选择器的核心目的只有一个：选中你想操作的元素。

在前端里，选中元素是为了改样式；在 JavaScript 里，选中元素是为了做交互；在爬虫里，选中元素是为了提取数据。

先掌握元素、类、ID、后代、子元素、兄弟、属性和伪类选择器，就足够应对大多数入门级网页解析场景。后面再学习 XPath、浏览器抓包和动态页面分析时，你会发现这些选择器思维仍然是通用的。

URL 是什么？从客户端与服务器讲透爬虫第一步

Wed, 13 May 2026 00:00:00 GMT

先建立一个最重要的认知

爬虫不是“黑科技”，它本质上只是一个模拟客户端发请求的程序。你在浏览器里点开网页，和你在 Python 里请求网页，底层都在做同一件事：客户端向服务器要资源。

所以在写任何爬虫代码之前，先把这套通信模型吃透，会让后续学习快很多。

客户端和服务器，到底是谁在做什么

在网络通信中，永远有两个角色：

客户端（Client）：发起请求的一方。
服务器（Server）：接收请求并返回结果的一方。

你常用的浏览器就是客户端，网站背后的应用服务就是服务器。这也是为什么我们常说 B/S（Browser/Server）架构，本质上仍然是 C/S（Client/Server）架构。

把它放到爬虫语境里就更直观了：

你写的爬虫程序 = 客户端。
目标网站 = 服务器。
你请求页面/接口 = 发起 Request。
网站返回 HTML/JSON/图片 = 返回 Response。

这就是一轮完整的爬虫工作流。

URL 是什么，为什么它是爬虫定位资源的核心

URL 全称是 Uniform Resource Locator（统一资源定位符），也就是我们日常说的网址。它的作用是告诉客户端：去哪里、用什么方式、拿什么资源。

一个完整 URL 通常可以拆成 6 部分：

协议（Protocol / Schema）
主机（Host）
端口（Port）
路径（Path）
参数（Query / Param）
hash（锚点）

1）协议：先约定通信规则

协议就是通信格式，比如 http 或 https。你可以把它理解为“双方说话前先统一语法规则”。

在爬虫里最常见的就是 HTTP(S) 协议，后续我们抓接口、带请求头、带 Cookie，都是在这套规则里工作。

2）主机：找到目标机器

主机就是你要访问的那台计算机，对应两种常见形式：

IP 地址：网络中的机器编号。
域名：便于记忆的别名（会经 DNS 解析为 IP）。

也就是说，你输入域名访问网站时，浏览器会先帮你“翻译”到对应 IP，再去连接服务器。

3）端口：找到目标服务

一台机器上可能同时跑很多服务，所以只知道 IP 还不够。端口就像同一栋楼里的门牌号，帮你找到具体服务进程。

端口可以省略，客户端会按协议自动补默认值：

http 默认 80
https 默认 443

4）路径：告诉服务器你要哪份资源

路径用于标识具体资源或服务入口。例如：

/ 通常表示首页资源。
/list 可能是列表服务。
/api/v1/items 可能是接口资源。

同一个站点，不同路径往往对应不同业务能力。

5）参数：传递额外条件

参数用于补充请求条件，常见于搜索、分页、筛选：

http://movie.com/list?page=3&size=20

上面这个 URL 的参数表达了两件事：

请求第 3 页
每页 20 条

多个参数用 & 连接，键值使用 key=value 形式。

6）hash：更多是浏览器侧定位

# 后面的 hash 一般用于前端页面内部锚点跳转，通常不参与服务器资源定位。在多数爬虫请求里，hash 不是关键点。

URL 编码：为什么中文会“变成一串百分号”

URL 中不能直接出现非 ASCII 字符（比如中文）。当你搜索中文关键词时，浏览器会自动把中文转成编码形式，这就是 URL 编码（Percent-Encoding）。

例如中文关键词会被编码成 %E4%BA%91%E9%9F%B5 这类字符串。在 Python 中，你可以这样编码和解码：

from urllib.parse import quote, unquote

keyword = "云韵"
encoded = quote(keyword)
decoded = unquote(encoded)

print(encoded)  # %E4%BA%91%E9%9F%B5
print(decoded)  # 云韵

实战里很多 HTTP 客户端库会帮你自动编码，但你要知道这个机制，否则排查请求失败时会非常被动。

给爬虫初学者的一套 URL 分析步骤

拿到任意一个网址，先按下面 5 步拆解：

看协议：HTTP 还是 HTTPS。
看主机：目标站点是谁。
看路径：对应哪个页面或接口服务。
看参数：哪些是必传参数，哪些是可选参数。
做最小化实验：逐步删减参数，验证服务是否还能正常返回。

这套步骤能帮你快速识别“请求最小闭环”，是后续接口分析、请求复现、反爬排查的基础能力。

总结

如果把爬虫学习看成盖楼，客户端/服务器 + URL 就是地基。理解了这篇里的核心点，你就能更稳地进入下一步：抓包、请求复现、参数分析和自动化采集。

一句话收尾：先学会读 URL，再学会发请求，最后再谈爬虫工程化。

爬虫合法吗？一文讲清爬虫法律边界与风险

Wed, 13 May 2026 00:00:00 GMT

爬虫合法吗？先说结论

爬虫技术本身并不违法，真正有风险的是“不当使用”。判断一个爬虫行为是否可能违法，核心看三件事：你爬什么、你怎么爬、你爬完拿来做什么。

如果是个人学习、技术研究、教学演示，且只抓公开信息、不破坏对方系统、不传播敏感数据，通常风险较低。如果是批量抓取后倒卖、泄露个人信息、造成网站故障，风险会急剧上升。

为什么“爬虫违法”这个说法会误导初学者

很多人把“有人因爬虫被处罚”理解成“爬虫本身违法”。这个理解不准确。和开车一样，车本身不是问题，超速、酒驾、肇事才是问题。

爬虫也是同一逻辑：

技术中立：爬虫是自动获取网络信息的手段。
行为可分：合法用途和违法用途都可能存在。
后果导向：是否侵权、是否造成损害，是关键判断点。

与爬虫密切相关的法律框架

做爬虫时，常被讨论的法律主要有以下几类：

《数据安全法》：关注数据处理活动的安全与责任边界。
《网络安全法》：关注网络运行安全、系统保护与秩序维护。
《个人信息保护法》：关注个人信息收集、处理、传输、共享等合规要求。
《反不正当竞争法》：关注是否通过不正当方式攫取商业利益。
《著作权法》：关注作品内容抓取后的复制、传播、商用风险。
《刑法》：针对严重后果行为可能涉及刑事责任。

这些法律并不是“专门用来禁止爬虫”，而是防止数据滥用、系统破坏、隐私泄露与商业侵权。

判断爬虫风险的三重标准

1）动机：你为什么要爬

学习、研究、教学、模型验证：通常更容易落在合理范围内。
抓付费内容并转售、搬运牟利：高风险，可能构成侵权或不正当竞争。

2）行为：你怎么爬

控制频率、抓公开页面、遵守访问规则：风险相对可控。
高频并发冲击、绕过限制、导致对方服务异常：风险显著升高。

3）结果：你造成了什么影响

数据仅用于个人学习，不传播、不交易：风险较低。
导致隐私外泄、商业损失、系统故障：风险可能升级到民事、行政甚至刑事层面。

7 个最常见的高风险雷区

下面这些场景，是爬虫初学者最容易踩坑的地方：

采集和流通敏感个人信息如身份证号、账单、社保、公积金等，风险极高。
把目标站点“爬崩” 不限流、不降频、高并发扫站，容易被认定为恶意行为。
接黑灰产外包如批量登录、批量注册、验证码打码、账号批量操作。
做内容搬运型商用抓视频、小说、图书、资讯后改头换面二次分发变现。
忽视版权边界 “自己看”与“公开传播、售卖”在法律上不是一回事。
误判“非公开数据” 需要登录或付费才能看到的数据，不等于可随意采集和扩散。
公开传播破解/逆向细节个人研究与公开扩散有本质差别，后者更容易引发法律争议。

爬虫学习者的合规清单

在每个项目开始前，先自检这 8 条：

目标数据是否包含个人敏感信息？
数据是否属于登录后/付费后才能访问？
本次采集是否有明确、正当、可解释的用途？
是否设置了请求频率上限与超时重试上限？
是否避免对目标服务造成明显性能压力？
是否避免将抓取结果用于侵权传播或商业倒卖？
是否保留了最小化采集原则（只拿必要字段）？
是否准备了“发现异常立即停止”的机制？

常见问题（FAQ）

Q1：爬公开网页，一定合法吗？

不一定。公开可访问不等于可任意采集、任意商用，仍要看用途、方式和影响。

Q2：只做学习 demo 会被追责吗？

一般风险较低，但前提是数据和行为都在合理边界内，不触碰敏感信息与系统安全底线。

Q3：课程学习阶段最重要的原则是什么？

一句话：用途不明不写，写到一半发现不对劲立刻停。

总结

“爬虫合法吗”这个问题，答案从来不是简单的“是/否”。真正决定风险的，不是工具，而是使用者的动机、行为与后果。

把边界先立住，再学技术，爬虫就能成为创造价值的能力；越过边界，技术优势也可能变成法律风险。

说明：本文用于技术学习与合规认知，不构成法律意见。涉及具体业务时，建议咨询专业律师。

TraceCloud 学习中心

XPath 教程：爬虫如何用 XPath 定位网页元素

为什么爬虫要学 XPath？

XPath 是什么？和 CSS 选择器有什么区别？

XPath 基础语法：节点选取怎么写？

最基本的五种表达式

谓语怎么用？如何精确找到第 N 个元素或特定属性？

按索引定位：第一个、第二个、最后一个

按属性值定位：class、href、id

按文本内容定位

组合条件：多个谓语叠加

XPath 轴怎么用？父子兄弟节点定位

常用轴

实战例子

Python 爬虫里怎么用 XPath？lxml + etree 示例

常用 lxml + XPath 方法

XPath 和 CSS 选择器怎么选？哪个更好用？

XPath 常见报错与处理

1. 空列表：匹配不到元素

2. 下标越界

3. 属性名拼错

4. 文本含空格或换行导致匹配失败

XPath 优化技巧：写得更精准、更稳定

常见问题

XPath 和 CSS 选择器哪个更快？

页面是 JavaScript 动态生成的，能用 XPath 吗？

为什么 XPath 在浏览器开发者工具里能选中，但 lxml 解析不出来？

XPath 能处理 JSON 数据吗？

XPath 中的通配符怎么用？

XPath 支持逻辑运算吗？

总结

相关知识

FAQ

Python Parsel 教程：用 CSS、XPath 提取网页数据

安装 Parsel

从 Selector 开始

Python 爬虫入门

用 CSS 选择器提取数据

用 XPath 提取数据

循环内要使用相对 XPath

.get() 和 .getall() 有什么区别

用正则表达式做二次提取

提取列表页数据

Parsel 配合 requests

解析 XML 和命名空间

为什么选择器明明正确，却取不到数据

1. 响应里根本没有目标内容

2. 请求被重定向或返回了验证页

3. 页面编码判断错误

4. XPath 查询范围写错

5. 文本藏在子标签里

CSS 还是 XPath

常用方法速查

Python urljoin 教程：URL 路径拼接与相对路径处理完整指南

为什么爬虫要处理 URL 路径拼接？

URL 结构：urljoin 到底在处理什么？

urljoin 基础：相对路径怎么拼？

相对路径：以「当前目录」为基准

./：明确表示"当前目录"

../：向上回退一层目录

urljoin 进阶：绝对路径怎么处理？

/ 开头：从网站根目录算

完整 URL：直接覆盖

urljoin vs 字符串拼接：本质区别在哪里？

实战：爬虫里怎么用 urljoin 拼接图片链接？

场景：从 HTML 里提取相对路径，拼接完整 URL

场景：批量拼接资源 URL 并下载

场景：拼接分页 URL

urljoin 常见报错与处理

报错 1：拼接结果包含了旧的 query 参数

报错 2：相对路径带空格导致拼接失败

报错 3：base URL 末尾有 / 跟没有，结果不一样

报错 4：协议相对 URL（//开头）

urljoin 与 urlparse、urlunparse 的关系

常见问题

urljoin 和 os.path.join 有什么区别？

base URL 末尾的 / 重要吗？

urljoin 能处理锚点（#hash）吗？

协议相对 URL（以 // 开头）怎么处理？

总结

`.get()` 和 `.getall()` 有什么区别

`$0` 是什么

1）`/` 开头不等于相对路径

2）`./` 和不写 `./` 很接近