playwright语义化定位优先使用用户可见信息（如按钮文案、标签文本）而非dom实现细节，因其抗重构性强，能应对class哈希化、shadow dom、微前端等现代前端挑战。
直接用 soup.select() 或 document.querySelector() 就能定位，但返回空或错位，八成是选择器没写对层级、忽略了动态渲染，或者误用了类名拼写。
为什么 soup.select('div.content') 有时返回空列表？
常见错误是把 class 名当作文本内容匹配，或忽略 HTML 中实际 class 值的细节。
- 检查真实 HTML：用浏览器开发者工具右键「检查」，确认元素是否真有
class="content"，而不是class="content active"或class="page-content" -
.content只匹配 class 属性中包含content的元素，但若你写成div.content p，它要求p是div.content的**后代**，不是必须直系子元素 - BeautifulSoup 默认解析器（如
html.parser）不区分大小写，但 class 名本身区分空格和连字符 ——.btn-primary≠.btn primary - 如果页面用 JavaScript 动态插入 class，
requests + BeautifulSoup拿不到，得换Playwright或requests-html
page.locator() 和 page.query_selector() 在 Playwright 中怎么选？
二者都支持 CSS 选择器，但行为差异直接影响稳定性。
-
page.query_selector('button.submit')立即返回第一个匹配元素（或null），不等、不重试，适合已知 DOM 已就绪的场景 -
page.locator('button.submit')返回一个“定位器对象”，本身不触发查找，只有调用.click()、.is_visible()等方法时才执行查找 + 自动等待（默认 5s） - 推荐优先用
locator()：它会重试、可链式过滤（如locator('nav a').filter(has_text='Home')），且与截图、断言等 API 对齐 - 注意：Playwright 不支持
:nth-child()这类伪类，要用locator().nth(0)替代
如何避免因 class 名动态变化导致选择器失效？
很多前端框架（React/Vue）生成带哈希的 class，比如 Button_button__abc123，硬写会崩。
- 优先找稳定锚点：用 ID（
#submit-btn）、语义化标签（main > form > button[type='submit']）、或属性（button[data-testid='login-button']） - 用属性选择器兜底：
button[data-action='login']、a[href='/profile']、input[name='email']都比 class 更可靠 - 组合层级缩小范围：与其写
div p span，不如写#user-card .name-text—— 越靠近目标的父容器越稳定，ID > class > 标签名 - 避免过度依赖空格后代选择器（
nav ul li a），改用直接子代（nav > ul > li > a）可减少误匹配，但也更脆；需权衡
浏览器里能用的选择器，代码里为啥不生效？
根本原因常是环境差异，不是语法错。
- 浏览器 DevTools 的
$$(selector)运行在完整渲染后的 DOM 上；而requests拿到的是原始 HTML 字符串，JS 未执行 → class、属性、节点都可能缺失 - 某些库（如旧版 BeautifulSoup）不支持部分 CSS3 选择器：
[attr^='http']、:is()、:has()大概率报错或静默忽略 -
requests-html的find()支持containing=参数，但这是扩展能力，不是标准 CSS 语法，别当成通用方案 - 大小写敏感性不一致：Chrome 控制台对标签名不敏感（
Div≈div），但某些解析器（如 lxml）严格区分
真正难的不是写出一个能跑的选择器，而是写出一个在 HTML 结构微调、class 名重命名、JS 加载延迟后依然有效的选择器 —— 它得靠锚点稳定性、层级克制和属性替代，而不是堆砌嵌套或依赖视觉位置。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
