技术问询：为何当前代码仅支持特定UPC码？

我之前帮朋友排查过类似的电商网站爬取问题，这种“浏览器能打开但代码请求失败”的情况，大多和网站的反爬策略或者请求细节有关，咱们梳理几个最可能的原因及解决思路：

1. 请求头缺失或不规范，触发反爬拦截 #

浏览器访问网站时，会自动携带一套完整的请求头信息（比如User-Agent、Accept-Language、Referer，甚至会话Cookie），这些信息会让网站认为你是“正常用户”。但如果你的代码只发送了最基础的GET请求，没有模拟这些头信息，网站很可能会判定你是爬虫，返回错误或者空内容。

• 不同UPC对应的页面可能有不同的反爬强度，比如12位的627386004004对应的页面拦截更严格，而11位的UPC页面暂时没触发拦截。
• 解决办法：在代码里添加完整的请求头，优先把User-Agent改成主流浏览器的标识（比如Chrome的UA：Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36），必要时可以从浏览器开发者工具里复制当前会话的Cookie加到请求中。

2. URL拼接逻辑存在疏漏 #

仔细对比两个UPC对应的URL结构：627386004004是12位，20313447006是11位，网站可能对不同长度的UPC有不同的路由处理逻辑。如果你的代码是动态拼接URL，可能在处理12位UPC时，参数顺序、格式或者某个拼接细节出了问题，导致请求的URL看似正确，但实际不符合网站的路由规则。

• 解决办法：直接复制浏览器中能正常打开的627386004004的完整URL，替换到代码中测试。如果能正常返回数据，说明是你拼接URL的逻辑有问题，需要修正拼接代码的规则；如果还是报错，就排除这个原因。

3. 商品内容是动态加载的 #

有些电商网站的商品数据不是直接渲染在HTML里，而是通过AJAX请求从后端接口获取，浏览器打开页面时会自动执行JavaScript加载数据，但你的代码如果只是单纯请求页面的HTML，只能拿到空的内容容器，自然会返回错误。而部分UPC对应的页面可能是静态渲染的，所以代码能正常拿到数据。

• 解决办法：打开浏览器的开发者工具（F12），切换到“网络”面板，刷新页面，查看XHR/fetch类型的请求，找到实际返回商品数据的API接口，直接请求这个接口获取数据；或者使用selenium、playwright这类模拟浏览器的工具，让代码像浏览器一样加载页面、执行JS，等待内容渲染完成后再提取数据。

4. 网站的UPC校验规则差异 #

虽然可能性较低，但也不能排除网站对不同长度的UPC有不同的校验逻辑。比如12位UPC需要满足校验位算法，浏览器访问时网站会自动处理，但代码请求时可能因为缺少某种参数或者处理逻辑，导致校验不通过。不过既然浏览器能正常访问，这个原因的概率不大，可以放在最后排查。

内容的提问来源于stack exchange，提问作者J. Doe