本文讲解如何解决 puppeteer 中因 dom 文本异步渲染导致的 `$eval` 取值为空格或旧值的问题，核心在于等待目标元素文本内容稳定后再读取，避免依赖断点触发的偶然时机。
在使用 Puppeteer 进行网页内容抓取时，你可能会遇到一种看似“玄学”的现象：代码在调试模式下（设置断点）能正确获取到目标元素的文本，但一旦移除断点、全速运行，却只得到一个空格 ' ' 或空字符串。这并非 Puppeteer 的 Bug，而是典型的竞态条件（race condition）——页面元素虽已存在，但其 innerText 尚未完成动态渲染或 JavaScript 初始化。
你的原始代码：
let currentBuy;
try {
currentBuy = await scrappingPage.$eval('#market_commodity_buyrequests', (res) => res.innerText);
} catch (e) {
console.error('Failed to extract text:', e);
}
console.log(currentBuy); // ❌ 常为 ' '（空格），而非预期内容问题根源在于：$eval 执行时，目标元素 #market_commodity_buyrequests 虽已挂载到 DOM，但其文本内容可能正由前端框架（如 React、Vue）或异步脚本动态填充。断点人为引入了延迟，恰好让渲染完成，而无断点时代码执行过快，读取到了中间状态（例如仅含空白符的占位节点）。
✅ 正确解法不是加 await page.waitForTimeout(2000)（不可靠且低效），而是主动等待文本内容停止变化。推荐采用「值稳定性检测」策略：周期性读取文本，当连续两次读取结果一致（且非空/非纯空白）时，判定为稳定值。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
你可以使用社区成熟的工具库 bubanai-ng（Wix 团队开源），它提供了健壮的 waitForValueToStopChanging 工具函数：
npm install bubanai-ng
import { waitForValueToStopChanging, getText } from 'bubanai-ng';
// 等待 #market_commodity_buyrequests 的 innerText 值稳定（默认超时 5s，容差 100ms）
await waitForValueToStopChanging(
() => getText(scrappingPage, '#market_commodity_buyrequests'),
{ timeout: 5000, stabilityThreshold: 100 }
);
// 此时再安全读取
const currentBuy = await getText(scrappingPage, '#market_commodity_buyrequests');
console.log('✅ Stable text:', currentBuy.trim() || '<empty>');? getText() 内部使用 page.$eval 并自动 .trim()，避免空格干扰；waitForValueToStopChanging 默认重试 20 次（每次间隔 50ms），可按需调整 stabilityThreshold（两次读取间隔）和 timeout。
⚠️ 注意事项：
- 不要依赖 page.waitForSelector() 或 page.waitForFunction() 简单判断元素存在——它们无法保证内容已渲染完成；
- 避免 page.waitForTimeout() 硬编码等待，既降低效率，又难以适配网络/设备差异；
- 若无法引入第三方库，可手写轻量版稳定性检测逻辑（参考 bubanai 源码），核心是循环 page.$eval + Date.now() 计时 + 字符串深比较。
总结：Puppeteer 抓取动态内容的关键，在于从「等待元素出现」升级为「等待内容稳定」。用 waitForValueToStopChanging 替代断点，不仅修复了偶发性失败，更让自动化流程具备生产级鲁棒性。
