动态标签未等到即解析，90%因混淆“DOM插入”与“内容可读”阶段；应等待真实挂载节点（如ul>li数量变化或data-loaded属性），而非template本身。
动态标签没等到就解析，90% 是因为没区分“DOM 插入”和“内容可读”两个阶段。 直接用 WebDriverWait 等 presence_of_element_located 只能保证节点在 DOM 树里，但不保证它已渲染完成、文本已填充、class 已更新——这正是你拿到空值或 stale element 的根源。
Playwright 中怎么等一个动态 <template> 被克隆并注入到 DOM？
浏览器原生 <template> 不会自动渲染，它的 content 是只读 DocumentFragment。JS 执行克隆逻辑后，才真正生成可交互节点。Playwright 无法靠 selector “猜”这个过程是否完成。
- 别用
page.wait_for_selector('template#list-item')—— 它永远存在，但没用 - 应监听真实挂载点的变化：比如等待
ul#product-list > li数量从 0 变为 >0，或等待某个li[data-loaded="true"]出现 - 更稳妥的是拦截 JS 注入行为本身：用
page.route()拦住返回列表数据的 API，再调用page.wait_for_response()，响应返回后再查 DOM - 如果服务端返回的是 HTML 片段（非 JSON），记得先用临时
template解析：const tmp = document.createElement('template'); tmp.innerHTML = htmlStr;，否则直接innerHTML =可能破坏结构
Selenium 里 text_to_be_present_in_element 总超时？检查三件事
这个等待条件看似直白，实则对 DOM 状态非常敏感。常见失败不是超时设置短，而是目标节点还没进入“可读文本”状态。
- 确认元素已 visible：
visibility_of_element_located必须先通过，否则文本即使存在也取不到 - 检查是否被 CSS 隐藏（
display: none或visibility: hidden）—— Selenium 不认为这类元素“可读” - 避免用模糊 selector：比如
//div[contains(@class, 'price')]可能匹配到多个节点，而等待逻辑只作用于第一个；应尽量用唯一属性如data-testid="product-price" - 若文本由 JS 动态拼接（如
span.innerText = '$' + price），确保等待时机在赋值语句之后——可在 DevTools 的 Sources 面板打断点确认执行顺序
为什么用 requests + BeautifulSoup 解析不到 <template> 里的内容？
因为 <template> 内容根本不会出现在原始 HTML 响应体中——它只是浏览器的“待命区”，服务器压根不执行、不渲染、不序列化它。你用 requests.get() 拿到的源码里，<template> 标签是空壳，里面什么都没有。
立即学习“前端免费学习笔记（深入）”；
- 右键“查看网页源代码”，搜索关键词，搜不到就说明它来自 JS 运行时生成，
requests天然无解 - 想绕过浏览器？得逆向定位 JS 如何加载模板：查 Network 面板里
.html或.js请求，找类似fetch('/templates/item.html')的调用 - 如果模板内容硬编码在 JS 里（如
const tpl = `<div>...</div>`），就得用 AST 解析或正则提取，但 class 名、变量名可能混淆，稳定性差 - 最稳路径仍是 Playwright/Selenium 拦截实际渲染后的 DOM，而非试图还原模板逻辑
真正容易被忽略的，不是“怎么等”，而是“等谁”。很多同学盯着 <template> 标签本身，却忘了它从来不是终点——你要等的是它被克隆后 append 到的那个真实容器节点，以及该节点上是否已挂载数据属性或文本内容。这个边界不厘清，所有等待都只是在等一个不存在的状态。
