这次我们来看一个很有意思的协议提案Shelf Protocol作者把它直接定义为 Robots.txt for Commerce也就是“商业版 robots.txt”。这个名字起得很准确因为它的目标不是再做一套通用爬虫协议而是把 robots.txt 的思路迁移到电商和商业数据场景站点所有者可以通过一份机器可读的策略文件声明自己的商品数据、价格、库存、优惠信息允许谁抓取、以什么目的使用、是否需要授权。如果你在做电商平台、比价工具、AI 训练数据采集、第三方数据服务或爬虫治理这个项目值得仔细看一遍。它不是本地部署那类模型工具不挑显卡、不占显存本质上是一个标准提案和基础设施层的约定。本文会从协议动机、与 robots.txt 的对比、部署思路、验证方法、自动化接入、性能观察和常见排查几个方向展开尽量把“能不能用、怎么用、怎么验证”讲清楚。1. 核心能力速览Shelf Protocol 目前属于社区提案和标准讨论阶段从 Hacker News 上的展示内容和命名方式来看它的核心能力可以整理成下面这张表能力项说明协议类型面向商业数据的访问控制与授权声明协议核心定位Robots.txt for Commerce解决电商数据抓取与使用授权问题主要功能声明商品价格、库存、优惠、商品描述等数据的使用条件适用对象电商平台、比价站点、价格监测服务、AI 数据采集方、数据治理平台部署位置站点根目录、.well-known目录、HTTP 响应头或 DNS 记录具体以项目文档为准数据格式预计为 JSON 或 YAML 一类机器可读格式需要按实际项目确认硬件要求无特殊硬件要求普通 Web 服务器和 CDN 边缘节点即可承载是否支持一键启动不适用属于 Web 协议基础设施不需要本地安装是否支持 API协议文件本身可作为机器可读端点被调用是否支持批量任务适合对大量站点做批量策略采集和合规校验开源状态社区提案项目建议以仓库 README 和讨论帖为准从材料来看这个项目的重点不是“阻止所有爬虫”而是建立一套“商业数据使用的君子协定”和可执行声明。这里需要先明确一个边界Shelf Protocol 解决的是“声明问题”不是“防护问题”。它告诉数据使用方哪些行为被允许、哪些行为需要授权但它本身不是一个 WAF不能物理阻断恶意抓取。实际落地时它需要配合访问控制、反爬策略、法律条款和审计机制一起使用。2. 适用场景与使用边界2.1 适合谁用Shelf Protocol 最适合下面几类团队角色典型诉求Shelf Protocol 能做什么电商平台不希望比价插件直接抓价格和库存在协议文件中声明价格数据是否允许抓取、是否允许转售品牌方管控渠道价格透明度统一声明商品数据使用条款比价工具需要合法合规地获取商品信息通过协议文件判断是否可以直接抓取、是否需要申请授权AI 数据服务商需要大规模商品数据做训练自动识别数据使用边界规避侵权风险合规与安全团队建立数据访问审计基线将协议文件作为企业级合规审查的组成部分2.2 能解决什么问题过去电商网站只有两个选择要么全开放让所有爬虫随便抓要么全封禁导致正常的比价、搜索、数据分析渠道也受影响。Shelf Protocol 试图提供一个中间层你可以明确写出“搜索引擎可以索引商品详情页”也可以写“价格和库存只允许授权合作伙伴调用”还可以写“AI 公司需要单独申请数据许可”。这套机制一旦被爬虫工具、浏览器插件、数据平台和 AI 公司遵守就能从源头降低数据纠纷。2.3 不适合什么场景需要注意Shelf Protocol 不适合作为唯一的反爬手段。理由很简单它依赖调用方主动读取和遵守。遇到不遵守协议的抓取者协议文件本身起不到拦截效果。需要防护的场景仍然要配合 IP 策略、访问频率控制、滑块验证、接口签名、数据加密等手段。另外Shelf Protocol 也不是法律文书。它的表达能力再强也不能替代正式的数据授权协议、隐私政策和条款。2.4 合规与安全边界涉及商品价格、库存、用户评价、销量等数据时必须区分数据是否属于个人信息、是否属于商业秘密、是否受反垄断约束。商业数据的使用边界不能只靠一个协议文件解决需要由法务和合规团队共同确定策略。如果协议声明被用作排除竞争的借口或者涉及价格协同可能引发反垄断合规风险。这类问题要特别谨慎不要用技术声明的形式掩盖商业策略上的合规缺陷。涉及用户行为数据比如用户点击、购买记录时更要遵守个人信息保护相关法规不能通过协议文件绕开用户授权。3. 协议设计核心Robots.txt for Commerce 如何解决数据授权问题要理解 Shelf Protocol最直接的方式是把 robots.txt 的机制搬过来看。传统 robots.txt 的规则很简单在站点根目录放一个文本文件告诉爬虫哪些路径可以抓、哪些路径不能抓。它的工作模式是声明式的站点说了算爬虫自愿遵守。Shelf Protocol 本质上延续了这个逻辑但扩展了三个维度身份、资源、条件。维度robots.txtShelf Protocol 的扩展方向身份靠 User-agent 区分爬虫类型可能扩展为组织身份、用途身份比如“AI 训练爬虫”“比价插件”“学术研究”资源用路径表达 URL 范围可能直接面向商业数据对象比如价格、库存、促销条件只有 allow 和 disallow可能支持“允许抓取但需要署名”“允许查看但不允许转售”“需要付费授权”等条件用一句话概括robots.txt 解决的是 Web 资源索引边界Shelf Protocol 解决的是商业数据使用边界。3.1 常见能力模块从“商业数据授权声明”这个目标反推一个成熟的 Shelf Protocol 实现通常会包含以下模块权限声明这是最核心的模块。站点声明谁可以访问哪些商业数据。可以按爬虫身份区分也可以按访问目的区分。典型声明包括“允许搜索引擎索引商品标题和描述”“禁止第三方工具抓取价格和库存”。使用条件权限声明只说明“能不能拿”使用条件说明“拿了之后能做什么”。常见条件包括非商业用途允许、商业用途需要署名、禁止整合转售、禁止用于模型训练、需要先申请 API Token。配额与频率真实场景中同一份数据对不同消费者的开放频率不同。Shelf Protocol 可能会支持声明访问频率上限和批量抓取限制避免正常授权和数据滥用之间的边界模糊。归属要求站点所有者可以要求数据使用方在展示数据时附上来源链接或品牌标识。这和学术引用的逻辑类似也是很多比价网站与品牌方争议的焦点。联系与授权通道声明不能只告诉对方“不允许”还得告诉对方“如果你有正当需求应该去哪里申请”。所以协议中大概率会包含授权联系入口比如授权 API 地址、商务联系人、申请表单地址。3.2 与 robots.txt 的定位关系一个常见误区是Shelf Protocol 要取代 robots.txt。实际上不需要。两者定位不同robots.txt 控制的是“搜索引擎爬虫对 Web 资源的索引行为”核心是路径级控制。Shelf Protocol 控制的是“商业数据的使用与授权”核心是数据级控制。一个合理的技术栈是站点同时部署 robots.txt 和 Shelf Protocol。robots.txt 继续管搜索引擎爬虫Shelf Protocol 管商业数据抓取方和 AI 数据采集方。两者形成互补关系而不是相互替代。3.3 关键机制机器可读与人工可读协议要能落地必须有非常好的机器可读性。爬虫工具和数据处理平台在请求商品页面之前先读取站点发布的协议文件然后根据规则决定是否继续、是否需要走授权流程。同时站点运营人员也需要能看懂。所以协议文件的结构应该简洁字段命名要直观。从 Robots.txt for Commerce 这个类比看Shelf Protocol 的目标就是让“不懂代码的运营”也能理解“哪些数据被允许抓取”。4. 环境准备与部署思路Shelf Protocol 不是本地软件不需要安装依赖也不需要 GPU。它更像一份约定你需要在站点服务器上提供一个可访问、可解析的策略文件。下面给出通用的部署思路具体路径和字段以实际项目文档为准。4.1 前置条件准备项说明域名需要在主域名或指定子域上部署协议文件Web 服务器Nginx、Apache、静态托管服务或 CDN 边缘函数均可DNS 控制台如果需要通过 TXT 记录做验证需要域名解析权限HTTPS建议强制开启协议文件涉及数据授权明文传输不合理测试工具curl、浏览器开发者工具、Postman 或自写脚本4.2 策略文件生成协议文件的核心是生成一份结构化的策略声明。这里给一个通用参考结构字段命名不代表 Shelf Protocol 官方规范仅用于演示如何组织“权限、条件、联系信息”{ protocol: shelf-protocol, version: 1.0, domain: example.com, issued_at: 2025-01-01T00:00:00Z, policy: { search_engine: { allow: true, path: [/products*] }, price_comparison: { allow: false, note: 需要授权后开放 }, ai_training: { allow: false, note: 如需获取数据请通过下方 address 申请 }, authorized_partner: { allow: true, requires_token: true, token_endpoint: https://example.com/api/token } }, usage_terms: { attribution_required: true, resale_forbidden: true, rate_limit_per_minute: 60 }, contact: { authorization_url: https://example.com/data-license, email: data-accessexample.com } }实际字段需要按项目文档确认。上面这个结构只是用于说明“商业数据授权声明”可以包含哪些信息。4.3 Nginx 部署示例假设你已经生成好协议文件放在站点服务器的/var/www/example.com/.well-known/shelf.json可以通过 Nginx 直接暴露server { listen 443 ssl; server_name example.com; location /.well-known/shelf.json { alias /var/www/example.com/.well-known/shelf.json; default_type application/json; add_header Cache-Control public, max-age3600; add_header X-Content-Type-Options nosniff; } location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }这个配置做了三件事将协议文件以application/json类型返回。设置 1 小时缓存避免每次被爬虫请求都回源。开启nosniff避免浏览器或客户端对内容类型做错误判断。如果你的站点托管在纯静态服务上直接把文件传到对应目录即可不需要额外服务端配置。4.4 边缘函数动态生成如果协议内容会动态变化也可以在 Cloudflare Workers、边缘函数上动态生成。这里给一个通用伪代码export default { async fetch(request, env, ctx) { const url new URL(request.url); if (url.pathname /.well-known/shelf.json) { const policy await getShelfPolicy(); // 从 KV 或数据库读取 return new Response(JSON.stringify(policy), { headers: { Content-Type: application/json } }); } return new Response(Not Found, { status: 404 }); } };动态生成的好处是可以按请求方身份或 IP 返回不同策略版本也可以随时调整授权条件不需要改服务器文件。4.5 DNS 验证与声明从协议标准化角度来看DNS TXT 记录也是常见验证方式。它可以用于证明域名所有者认可该协议也可以声明协议文件当前位置# 示例在 DNS 控制台添加 TXT 记录 # 主机记录_shelf # 记录值Shelf-Protocol v1.0; policyhttps://example.com/.well-known/shelf.json不同 DNS 服务商的操作方式不同但原理一致通过 DNS 验证让数据使用方先确认协议真实性再读取具体策略。5. 功能测试与效果验证部署完成后要验证协议文件的可用性和正确性。下面给出一套通用验证流程。5.1 测试目标协议文件是否可以公开访问。返回内容类型是否正确。JSON 结构是否能被正常解析。爬虫客户端读取后能否做出正确判断。访问频率和缓存是否符合预期。5.2 用 curl 验证访问# 请求协议文件输出 HTTP 状态头和响应体 curl -I https://example.com/.well-known/shelf.json # 输出完整响应 curl https://example.com/.well-known/shelf.json预期结果HTTP 状态码为 200。Content-Type为application/json。响应体包含完整的策略声明结构。如果返回 404检查文件路径、Nginx alias 路径、静态托管目录是否正确。 如果返回 403检查目录权限或 WAF 规则是否误拦截。5.3 用 Python 解析并输出决策这里模拟一个爬虫工具读取协议文件后判断自己是否有权限访问商品价格数据。脚本结构是通用示例实际字段需要按项目文档调整import json import requests # 1. 读取协议文件 url https://example.com/.well-known/shelf.json resp requests.get(url, timeout10) if resp.status_code ! 200: print(f协议文件获取失败HTTP {resp.status_code}) exit(1) # 2. 解析 JSON try: shelf resp.json() except json.JSONDecodeError: print(协议文件不是合法 JSON) exit(1) # 3. 按调用方身份查找策略 # 这里只是通用示例实际需要按项目字段调整 client_type price_comparison policy shelf.get(policy, {}).get(client_type) if policy is None: print(未找到当前调用方策略默认拒绝访问) exit(0) if policy.get(allow) is True: print(允许抓取商品价格数据) if policy.get(requires_token): print(需要先申请访问 Token) else: print(禁止抓取商品价格数据请联系授权入口申请) auth_url shelf.get(contact, {}).get(authorization_url) print(f授权申请地址{auth_url})判断成功的标准能稳定获取协议文件。JSON 解析无异常。不同调用方身份返回不同策略结果。未知身份默认拒绝而不是默认放行。5.4 模拟多站点批量校验如果你做的是数据合规平台需要批量检查多个电商站点是否部署了协议文件。可以用脚本批量处理import json import requests from concurrent.futures import ThreadPoolExecutor domains [ https://example1.com, https://example2.com, https://example3.com, ] def check_shelf(domain): paths [/.well-known/shelf.json, /shelf.txt] for path in paths: url domain path try: resp requests.get(url, timeout10) if resp.status_code 200: return {domain: domain, status: ok, content_type: resp.headers.get(Content-Type)} except requests.RequestException: continue return {domain: domain, status: not_found} with ThreadPoolExecutor(max_workers5) as executor: results list(executor.map(check_shelf, domains)) for result in results: print(json.dumps(result, ensure_asciiFalse))5.5 失败场景判断现象可能原因排查方式返回 404文件路径不对检查目录结构和 Nginx alias返回 403目录权限或 WAF 拦截检查服务日志和安全策略Content-Type 错误服务器默认类型不是 JSON显式设置 default_typeJSON 解析失败编辑器保存了 BOM 头或格式错误用 JSON 校验工具检查爬虫不遵守协议协议还在推广阶段覆盖率不够配合 robots.txt 和访问控制使用6. 自动化接入与协议文件调用的实践Shelf Protocol 不提供传统意义上的“本地启动”但它提供的协议文件本身就是机器可读端点。可以把“读取协议文件—解析策略—执行决策”当成一个标准化接口流程接到自己的数据采集系统、合规平台或浏览器插件中。6.1 将协议文件作为接口使用协议文件本质上是一种轻量级接口请求路径固定返回格式固定状态码语义清晰。和传统 API 相比它有这些特点特点说明公开只读通常不需要鉴权即可读取适合前置判断标准化路径便于成为行业默认约定低消耗静态文件或边缘函数资源开销小可缓存数据变化不频繁时缓存友好6.2 curl 调用示例# 读取协议文件并把响应体保存到本地 curl -s https://example.com/.well-known/shelf.json -o shelf.json # 请求时带 User-Agent便于站点识别调用方身份 curl -s https://example.com/.well-known/shelf.json \ -H User-Agent: MyDataCrawler/1.0 (contactexample.com)6.3 Python 批量接入示例面对数千个电商域名的接入场景可以先通过协议文件判断授权状态再执行抓取。这里给出一个通用任务队列示例import json import requests import time import csv # 目标站点列表 targets [ {domain: https://example1.com, client_type: ai_training}, {domain: https://example2.com, client_type: price_comparison}, ] def get_policy_status(domain, client_type): shelf_url f{domain}/.well-known/shelf.json try: resp requests.get(shelf_url, timeout10) if resp.status_code ! 200: return shelf_missing policy resp.json().get(policy, {}).get(client_type, {}) if policy.get(allow): return allowed return denied except Exception: return error results [] for t in targets: status get_policy_status(t[domain], t[client_type]) results.append({domain: t[domain], client_type: t[client_type], status: status}) time.sleep(0.3) with open(shelf_check_result.csv, w, newline, encodingutf-8) as f: writer csv.DictWriter(f, fieldnames[domain, client_type, status]) writer.writeheader() writer.writerows(results) print(results)6.4 与数据治理平台集成更工程化的做法是把 Shelf Protocol 校验纳入数据采集环节数据采集任务启动前先请求目标站点的协议文件。解析策略判断当前任务类型是否被允许。如果允许记录本次采集依据的协议版本。如果拒绝任务进入审核队列由人工或法务判断是否走授权流程。所有判断结果落库留作合规审计。通过这套流程数据团队就不再是“先抓再说”而是“先查协议、再抓数据、全程留痕”。7. 资源占用与性能观察Shelf Protocol 不是重协议性能压力理论上很小但真实场景中的资源占用仍然要看部署方式。7.1 静态文件部署开销如果协议文件是纯静态 JSON文件大小通常只有几 KB 到几十 KB。对 Web 服务器来说这个开销可以忽略不计。实际观察重点放在指标观察方式正常范围参考响应时间curl 观察 Time Total静态文件应稳定在几十毫秒内文件大小LS 或响应体大小几 KB 到几十 KBHTTP 状态码访问日志统计200 占绝大多数缓存命中率CDN 控制台或日志越高越好7.2 边缘函数部署开销如果使用边缘函数动态生成协议文件资源占用取决于每次请求要执行的计算和 IO。建议把动态内容尽量做成 KV 缓存避免每次回源数据库。7.3 高峰流量与突发请求当比价插件、AI 爬虫大规模上线时协议文件的请求量会同步上升。这时要重点观察CDN 缓存命中率是否下降。源站是否出现 5xx 错误。协议文件响应时间是否劣化。一个稳妥的策略是给协议文件设置较长的缓存时间比如 1 小时到 24 小时。协议策略本身不会频繁变化过度实时反而不利于生态稳定。7.4 端口与进程管理Shelf Protocol 不涉及本地服务因此不需要关注端口占用和进程残留。只需要注意 HTTPS 证书是否有效、CDN 节点是否覆盖主流区域即可。8. 常见问题与排查方法问题现象可能原因排查方式解决方案请求协议文件返回 404文件路径错误或未部署检查服务器文件目录、Nginx 配置将文件放在正确路径并重载配置返回 403服务器权限或 WAF 规则误拦截检查 Nginx/Apache 错误日志、WAF 规则调整目录权限添加放行规则返回 Content-Type 是 text/html服务器未识别 JSON 文件类型用 curl -I 查看响应头在服务器配置中强制指定 application/jsonJSON 无法解析文件编码问题或格式错误用 JSON 校验工具检查重新生成文件去掉 BOM 头爬虫完全不读取协议协议生态尚未普及查看访问日志确认是否有爬虫访问配合 robots.txt、法律声明和 API 鉴权使用CDN 缓存了旧策略Cache-Control 设置不恰当检查响应头中的缓存字段更新缓存设置必要时手动清除DNS TXT 验证失败记录未生效或格式错误使用 nslookup 或 dig 查询检查记录名称和值格式协议声明与实际授权不一致运营人员和数据团队没有对齐人工复核策略文件建立策略文件发布审核流程9. 最佳实践与工程化落地建议9.1 与 robots.txt 叠加部署不要二选一Shelf Protocol 和 robots.txt 是互补关系。robots.txt 继续留给搜索引擎爬虫用Shelf Protocol 用于商业数据使用方。两者叠加部署覆盖面更完整。9.2 策略文件发布要走变更流程商业数据授权策略属于运营决策不应该由工程师直接改完上线。建议参考这种做法运营或法务提出策略变更需求。平台审核通过后生成新的策略文件。先在测试站点验证 JSON 格式和访问路径。灰度发布到部分域名。观察访问日志和授权申请量后全量上线。9.3 默认拒绝显式允许协议声明最好遵循“未知即拒绝”原则。当调用方身份不明确时默认返回不允许访问。这样可以避免策略漏洞。9.4 协议文件要带上联系方式一个只有“禁止”没有“如何联系”的协议很容易把正常的数据合作需求挡在门外。协议文件中应该包含授权申请入口和联系邮箱。9.5 监控和日志审计建议对协议文件的访问日志做独立分析记录哪些爬虫在读取协议、它们随后是否访问了受限数据。这些日志可以作为审计材料也能帮助发现异常抓取行为。9.6 对调用方的合规提醒如果你是需要访问商业数据的调用方也要意识到协议文件中可能存在价格、库存等敏感数据不能因为“站点的协议文件允许读取”就直接用于二次销售或 AI 训练。技术上的允许不等同于法律上的授权。9.7 版权和使用边界商品图片、品牌 Logo、用户生成的评论都可能涉及版权问题。Shelf Protocol 只声明数据使用权限不能替代图片版权和商标授权。凡是涉及人脸、个人信息、品牌素材的必须单独核对授权。10. 总结与下一步Shelf Protocol 值得关注的核心点不是它能立刻解决所有数据抓取纠纷而是它提供了一个非常清晰的思路把 robots.txt 的声明式逻辑从 Web 资源层扩展到商业数据层。这个思路一旦成为行业共识后续演化出的标准配置、解析器、授权平台会非常丰富。最先要验证的事情有两个自己站点部署协议文件后正常爬虫和搜索引擎是否不受影响。数据使用方能否通过脚本正确解析协议并执行授权判断。最容易踩的坑也有两个一是把协议文件当作反爬工具期望它能拦截恶意请求二是字段和路径没有按实际项目文档确认导致自己造的协议文件不被社区工具识别。后续可以继续关注这几个方向Shelf Protocol 是否进入标准化组织或开源社区的统一维护。主流电商框架是否把协议文件生成逻辑内置到后台。比价工具和 AI 数据平台是否开始默认读取协议文件。是否出现基于协议文件的商业化授权市场。如果手头有电商站点或数据合规平台建议先把协议文件部署到测试环境写一套解析脚本验证数据团队和业务团队是否能按这份声明执行。跑通之后你会更清楚它在真实业务里能承接到哪一层。这个项目不需要多高的技术门槛但它可能是未来商业数据合作的默认规则之一。建议先收藏再动手验证。