<p>re.search(r'.pdf$', url) 更可靠，因它可配合先清理 URL 的 # 和 ? 后内容，再精准匹配路径后缀，而 str.endswith() 会因查询参数或锚点返回 False；且正则支持忽略大小写和多格式扩展名。</p>
正则匹配 URL 后缀时，为什么 re.search(r'.pdf$', url) 比 url.endswith('.pdf') 更可靠？
因为真实网页中的链接常带查询参数或锚点，比如 https://example.com/report.pdf?version=2#page1。用 str.endswith() 会返回 False，而正则 r'.pdf$' 能正确锚定在“以 .pdf 结尾”（不考虑 fragment 和 query），前提是先去除 # 和 ? 后的内容。实际处理中建议先用 urllib.parse.urlparse() 提取 path 字段再匹配。
常见错误是直接对原始 url 字符串做后缀判断，漏掉参数干扰；更隐蔽的问题是忽略大小写——.PDF、.Pdf 都应被接受，所以正则推荐写成 r'.(pdf|docx|xlsx)$' 并加 re.IGNORECASE 标志。
用 requests 下载前，如何安全判断响应体是否真为文档内容？
仅靠 URL 后缀不可信：服务端可能返回 200 状态但实际是 HTML 登录页、404 重定向页，或 Content-Type 声明为 text/html 却强行塞了 PDF 二进制流。必须检查三件事：
-
response.status_code == 200（且非重定向状态码如 302） response.headers.get('Content-Type', '').lower().startswith(('application/pdf', 'application/vnd.openxmlformats-officedocument'))-
len(response.content) > 1024（排除极小的错误响应体）
特别注意：有些站点会把 PDF 放在 iframe 或 JS 动态加载，此时 URL 看似合法，但 requests 直接 GET 返回的是外层 HTML。这种得结合 BeautifulSoup 解析页面，找 <iframe src="...pdf"> 或 fetch(...pdf) 调用。
立即学习“Python免费学习笔记（深入）”；
批量下载时，文件名怎么从 URL 安全提取并保留原始后缀？
别直接用 os.path.basename(url)——URL 可能不含路径，或含多层编码（如 %2F）、参数（?t=123）、锚点（#section）。正确流程是：
- 用
urllib.parse.urlparse(url)解析出path - 用
urllib.parse.unquote()对path解码 - 用
os.path.basename()取最后一段，再用正则r'[^/\?#]+.([a-zA-Z0-9]{2,})$'提取带后缀的文件名（若没匹配到， fallback 到hashlib.md5(url.encode()).hexdigest()[:8] + '.pdf'）
Windows 下还要过滤非法字符（<>:"/|?*），建议统一替换成下划线；Mac/Linux 用户需注意文件名长度限制，超长名建议截断但保留后缀和哈希前缀。
遇到反爬时，requests 抓不到文档，但浏览器能打开，怎么办？
这类情况大概率是服务端校验了 User-Agent、Referer 或要求执行 JS 渲染。先用浏览器开发者工具看 Network 面板里 PDF 请求的完整 headers 和请求方式（GET/POST？带不带 cookies？）。
简单修复可加基础头：
headers = {
'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36',
'Accept': 'application/pdf,*/*;q=0.8',
'Referer': 'https://example.com/list/'
}
如果仍失败，说明该文档由前端 JS 拼接 URL 或动态生成 token（如 /download?id=123&token=abc），这时必须用 playwright 或 selenium 启动真实浏览器，等 JS 执行完再提取最终 URL——否则正则白过滤，requests 白发请求。
真正难啃的是文档藏在登录态后、或需滑动验证的场景，这时候正则过滤后缀只是第一步，后续链路完全依赖身份维持和行为模拟，不能只盯着 URL 规则。
