urllib.parse.urlparse比正则更可靠，因其严格遵循rfc 3986解析url结构，能正确处理localhost、idn域名、中文路径等复杂情况，而正则易漏判或误杀且难以覆盖所有合法格式。
为什么 urllib.parse.urlparse 比正则更可靠？
直接用正则校验 URL 格式容易漏判或误杀——比如合法的 https://example.com/path?k=v#section 可能被简单正则 ^https?:// 拒之门外，而 http://localhost:8080 或含中文路径的 https://例.com/测试 更难用正则覆盖。Python 内置的 urlparse 会严格按 RFC 3986 解析结构，只要能拆出 scheme 和 netloc，基本可认为是格式有效的 URL。
实操建议：
- 优先用
urlparse(url).scheme和urlparse(url).netloc非空且scheme in ("http", "https", "ftp")做基础过滤 - 对明显畸形的（如空字符串、纯空格、
javascript:void(0)、#top）先做字符串级排除，再进解析 - 避免写类似
re.match(r"https?://[^\s]+", url)的正则——它不校验域名合法性，也放过https://这种残缺形式
哪些链接必须在解析后额外拦截？
urlparse 只管语法，不管语义。很多“格式正确”的 URL 对爬虫毫无价值，甚至引发异常请求。
常见需二次过滤的情形：
-
netloc是私有地址：127.0.0.1、localhost、192.168.0.0/16等，可用ipaddress库判断 -
path或query含无效扩展名：如.pdf、.zip、.exe（除非你明确要下载） -
fragment非空（即含#）且无对应 JS 渲染逻辑时，通常指向页面内锚点，无需单独请求 -
scheme是mailto:、tel:、data:等非 HTTP 协议
正则真要用，怎么写才少踩坑？
如果硬要上正则（例如预过滤大量脏数据、或配合日志提取），别追求“完美匹配所有 RFC URL”，而是聚焦常见有效模式 + 明确黑名单。
一个较实用的最小化正则：
^(https?|ftp)://[^\s/$.?#].[^\s]*$
说明与限制：
- 开头限定协议为
http、https或ftp，排除file:等 -
[^\s/$.?#]强制第二字符不能是空格、/、$、.、?、#，挡住http:///、http://?等明显错误 - 结尾
[^\s]*允许路径、查询、片段，但整体不能含空格 - 仍无法识别
https://例子.com（IDN 域名），这类应交由urlparse+idna处理
相对链接和 base_url 怎么统一处理？
爬虫遇到的多数无效链接其实是相对路径（如 /about、../img/logo.png、index.html），它们本身不是 URL，必须补全才能校验。
关键步骤：
- 用
urllib.parse.urljoin(base_url, link)补全，base_url必须是完整、已通过前述校验的 URL - 补全后再次用
urlparse检查scheme和netloc——若仍为空，说明补全失败，是无效相对路径（如javascript:alert(1)） - 警惕
urljoin对某些奇怪输入的“过度容错”，例如urljoin("https://a.com", "https://b.com/x")返回"https://b.com/x"（合理），但urljoin("https://a.com", "//c.com/y")会返回"https://c.com/y"（协议继承，易被忽略）
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
