在抓取商品页面时，HTTP 200 响应并不保证能获取到有效数据，因为关键信息通常通过 JavaScript 动态加载。核心问题并非“该用哪个爬虫？”，而是“数据位于何处？”许多电商页面采用客户端渲染（Client-Side Rendering），通过后端 API 调用获取数据。一个良好的起点是在 DevTools 中检查网络请求，寻找包含商品详情的 JSON 响应。大致的工作流程包括：手动加载页面，过滤 Fetch/XHR 类型的网络请求，在响应体中搜索已知的商品数据，将请求复制为 cURL 命令，并精简请求头以找出必要项。部分网站允许直接通过 cURL 调用，而另一些则需要会话 Cookie、地理定位头或 CSRF 令牌。Shopify 商店通常更容易处理，因为许多商店通过 /products.json 端点公开其商品目录，提供商品标题、变体、价格和图片 URL。这种方法比解析 HTML 更快、更稳健，且可避免因主题变更导致的 CSS 选择器失效。然而，部分 Shopify 商店会封锁该端点或限制暴露的数据范围。当无法直接访问 JSON 端点，或需要 JavaScript 生成令牌时，必须使用无头浏览器（如 Playwright）渲染页面。Playwright 可以捕获 API 响应，或在 JavaScript 执行后从 DOM 中提取数据。这种方法速度较慢，且需要处理超时、验证码（CAPTCHA）和区域推断等问题。完整的浏览器自动化仅适用于需要交互操作的状态，例如受登录保护的价格、心愿单或结账流程，这些场景需要点击操作和持久化会话。然而，这是资源消耗最大且最容易出问题的方案，可能导致任务变慢、验证码风险增加以及浏览器指纹问题。决策树应优先尝试公开 JSON 端点，其次是内部 API 调用，然后是无头浏览器渲染，最后才是完整浏览器自动化。除非绝对必要，否则不要从完整浏览器自动化开始，因为其在大规模使用时成本高昂且不稳定。