官方授权通道和灰色爬虫，做数据服务该选哪条路（附 python 源码）

官方授权通道和灰色爬虫，做数据服务该选哪条路（附 python 源码）

第 12 篇算过一笔自用的账：自建爬虫三年 37 万，官方 API 17.2 万。那篇的结论是「自用场景下，风险是一票否决项」。

但很多人问的不是自用------他们想做数据服务：把多平台的价格、商品数据聚合起来，卖给商家或开发者。这个问题必须单独回答，因为答案比自用场景更一边倒，而且原因完全不同。

一句话：自用，灰色爬虫是成本问题；做成服务，是生存问题。

自用时风险由你自己承担，封了就封了，损失可控。做成服务，你的每一个客户都跟你签了 SLA------你的上游哪天断了，你就是在对所有客户违约。这篇讲清楚为什么，以及走官方授权这条路要付的真实代价。

先划清边界：这篇不讨论怎么爬、怎么绕。爬虫的攻防不是技术选型，是法律风险------绕过技术措施可能触及刑法第 285 条，有真实获刑判例。这里只讲两条路的商业与合规结构，以及走合规路线需要的工程设施。

一、先精确定义「灰」在哪：四条边界

「灰色爬虫」不是一个笼统的概念，它压着四条线。做自用和做服务，压线的深度完全不同：

边界	说什么	自用	做服务
技术措施	绕过反爬、破解接口 = 刑法 285 条风险	不碰就相对安全	同样不能碰
个人信息	买家昵称、评价内容、地址都算	容易顺手采集	对外提供 = 违规放大
实质性替代	向第三方提供平台数据的替代视图	小规模通常够不上	必然够得上------你就是在做这件事
平台协议	robots、用户协议、接口条款	违约成本是封你一个号	封你，然后你违约于所有客户

关键差异在第三条。做数据服务，天然就是「向不特定第三方提供平台数据的聚合视图」------这正是反不正当竞争法里「实质性替代」的典型形态。爬公开数据自己看，和法律风险之间还有距离；聚合起来卖，距离就没有了。

所以不要问「爬公开数据违不违法」这种笼统问题，要问：我提供的这个东西，是不是平台功能的替代品，我有没有权利向第三方提供它。

二、做服务，风险是传导的

这是本篇的核心论证。画一条链：

上游数据源 → 你的服务 → SLA 合同 → 客户

客户看到的、签合同的、付钱的，都是你 。但你的服务质量，实际上由上游决定：

• 官方授权上游断了：有公告、有工单、有恢复预期，多数故障在小时级恢复，你甚至能提前收到字段变更通知。
• 灰色上游断了 ：一夜之间全挂------封号、IP 段拉黑、验证码升级，没有公告、没有申诉渠道、往往不可恢复。你连告诉客户「什么时候恢复」都做不到，因为没有「恢复」这回事。

而你和客户签的合同不会写「因为我的上游是灰色的」。SLA 写的是 99.9%、数据准确率、赔偿条款。上游断一天，就是全员违约：赔偿是月费的几倍，但真正的损失是客户流失和行业口碑------数据服务的圈子很小，一次大面积断供，名字就传开了。

所以数据服务的第一性问题不是「哪条路便宜」，而是：你的上游有没有给你「对客户履约的能力」。 灰色爬虫在这条上是结构性缺失，不是运营努力能补的。

顺带一个现实：灰色上游的故障是突发的、全量的------不存在「降级到 50%」，只有「可用」和「归零」两种状态。这让 SLA 的数学根本不成立。

三、官方授权通道的真实形态：不是一条路，是一组上游

「官方授权」也常被误解成「自己去申请开放平台」。做服务时，合法上游其实有四种，各有各的位置：

上游	拿到什么	适合
平台开放平台 / ISV 授权	你有权限范围内最全的字段	自家店铺数据、精修层
联盟接口（淘宝客、京东联盟）	全站商品的价格、券、佣金	覆盖层，门槛低
持牌数据商采购	归一化后的多平台数据	补充层，要尽调合同
人工与授权补录	长尾与特殊字段	量小，但必须留痕

三点实操建议：

1. 混合上游是常态，不是妥协。 没有单一上游能同时满足覆盖、深度、时效。成熟的数据服务商都是「官方为主 + 采购补充 + 人工兜底」------重要的是每一条数据知道自己从哪来（下一节的代码就是干这个的）。
2. 采购持牌数据商要做尽调。 问清授权链路（第 17 篇那五问直接适用）：是直连官方授权还是二次倒卖？授权范围含不含「对外提供」？合同里把数据合规责任写进去。
3. 「客户授权」也是授权。 商家把店铺 session 授权给你（他用型 ISV 模式），你拿到的是该店铺自己数据的读取权------用它去查别的商家的商品，是越权。私域和行情的边界，第 17 篇讲过，这里只提醒一句：这个错误在自用时是隐患，在服务场景里是事故。

四、数据溯源：合规不是纪律，是代码

合规这件事，靠「团队自觉」一定会出事------半年后新人接手，从某个来源抓了批数据直接进了对外接口，没人知道。

所以正确做法是把授权状态做进数据本身：每条数据带溯源字段，未验证来源的数据在代码层面就出不了 API。

# provenance.py ------ 数据溯源：让「灰数据进不了产品」成为系统属性
from dataclasses import dataclass
from enum import Enum


class SourceType(str, Enum):
    OFFICIAL = "official"        # 平台开放平台 / ISV 授权接口
    AFFILIATE = "affiliate"      # 联盟接口（淘宝客、京东联盟）
    PROCURED = "procured"        # 向持牌数据商采购（有合同）
    MANUAL = "manual"            # 人工录入 / 授权补录
    UNVERIFIED = "unverified"    # 来源未验证------禁止对外提供

# 封装好API供应商demo url=https://console.open.onebound.cn/console/?i=Lex
@dataclass
class Provenance:
    source_type: SourceType
    authorization_ref: str       # 授权依据：ISV 合同号 / 采购合同编号 / 联盟备案号
    fetched_at: str              # 抓取时间（ISO 8601）
    license_scope: str           # 允许用途：internal_only / client_delivery / redistribution
    upstream_version: str = ""   # 上游接口版本------平台改字段时能圈定影响面


class ComplianceError(Exception):
    pass


DELIVERABLE = {SourceType.OFFICIAL, SourceType.AFFILIATE,
               SourceType.PROCURED, SourceType.MANUAL}


def assert_deliverable(p: Provenance) -> None:
    """对外提供前强制检查。这个函数在 API 出口处调用，不是在文档里写一遍就完了"""
    if p.source_type is SourceType.UNVERIFIED:
        raise ComplianceError("来源未验证的数据禁止对外提供（internal_only）")
    if p.source_type not in DELIVERABLE:
        raise ComplianceError(f"来源类型 {p.source_type} 不允许对外提供")
    if "client_delivery" not in p.license_scope:
        raise ComplianceError(f"来源 {p.source_type.value} 的授权范围不含对外提供")

三个设计点，每一个都有真实用途：

1. UNVERIFIED 不是「不准用」，是「不准出」。 临时来源的数据可以进内部分析库做研究，但 assert_deliverable 挂在 API 出口，它永远发不出去。研究自由和交付合规分开管。
2. license_scope 比来源类型更重要。 同样是采购数据，合同里授权了 internal_only 和 client_delivery 是两个世界。签合同时看清楚，代码里对应上。
3. upstream_version 是救命字段。 平台改字段（第 14 篇讲过字段映射的坑）时，你能精确回答「受影响的数据是从哪个上游、哪个版本抓的」，圈定影响面、定向修复。没有它，就是全量重刷。

五、合规自查：定期扫自己的系统

上游合规之外，还要防自己人越界。两类常见事故，都可以用脚本定期扫：

事故一：越权调用。 拿 A 店的授权去查 B 店的商品------接口返回 200，但这是第 17 篇说的越权，在服务场景里是事故。

事故二：个人信息入库。 抓商品数据时顺手把评价里的买家昵称、地址存下来了。单条看是脏数据，攒起来就是一个个人信息库------而你没有处理它的合法性基础。

# audit.py ------ 两类自查：越权调用模式 + 疑似个人信息字段
import re

# ---- 自查一：session 与查询对象不匹配 = 越权 ----
def scan_unauthorized_calls(call_log: list[dict],
                            token_owner: dict[str, str]) -> list[dict]:
    """
    call_log:    [{"token_id": "...", "seller_queried": "...", "api": "..."}]
    token_owner: token_id -> 该授权店铺的 seller_id
    返回所有「用 A 店的 token 查 B 店数据」的调用
    """
    alerts = []
    for call in call_log:
        owner = token_owner.get(call["token_id"])
        if owner and call.get("seller_queried") not in (None, "", owner):
            alerts.append({**call,
                           "reason": f"token 属于店铺 {owner}，却查询了 {call['seller_queried']}"})
    return alerts

# 封装好API供应商demo url=https://console.open.onebound.cn/console/?i=Lex
# ---- 自查二：疑似个人信息字段 ----
PI_FIELDS = {"buyer_nick", "buyernick", "receiver_name", "receivername",
             "receiver_mobile", "receivermobile", "mobile", "id_card",
             "address", "detail_address"}

PI_PATTERNS = {
    "手机号": re.compile(r"\b1[3-9]\d{9}\b"),
    "身份证": re.compile(r"\b\d{17}[\dXx]\b"),
}


def scan_pi_fields(schema: dict[str, str]) -> list[dict]:
    """
    schema: {"orders.receiver_name": "收货人姓名", ...}
    返回疑似个人信息字段清单及命中原因，逐条评估去留
    """
    hits = []
    for key, desc in (schema or {}).items():
        name = key.split(".")[-1].lower()
        if name in PI_FIELDS:
            hits.append({"field": key, "why": "字段名命中 PI 清单"})
        elif desc and any(p.search(desc) for p in PI_PATTERNS.values()):
            hits.append({"field": key, "why": "字段说明命中格式特征"})
    return hits


def run_audit(call_log, token_owner, schema) -> str:
    pi = scan_pi_fields(schema)
    cross = scan_unauthorized_calls(call_log, token_owner)
    report = [f"[审计] 疑似 PI 字段 {len(pi)} 个，越权调用 {len(cross)} 笔"]
    for h in pi:
        report.append(f"  PI 字段: {h['field']}（{h['why']}）")
    for c in cross[:20]:
        report.append(f"  越权: {c['api']} {c['reason']}")
    return "\n".join(report)

这个脚本建议每月跑一次、接到 CI 里，输出直接发到内部告警群。它防的不是黑客，是自己系统的熵增：新同事加了张表、新接了个来源、某个字段顺手存了明细------每一次单看都无害，攒起来就是合规事故。

六、决策框架：三个问题定路线

不绕弯子，三个问题问完，答案自己就出来了：

问题	答案是 A	答案是 B
① 给谁用？	自己/公司内部	对外客户（SaaS、API、报告）
② 数据去哪？	内部分析，不对外分发	聚合后对外提供
③ 出事谁赔？	自己承担，损失可控	合同违约，全员赔偿

三问里只要有一个落在 B 列，灰色爬虫就不是选项------不是「风险高低」的权衡，是商业模式结构上不成立：你无法对客户承诺一个随时可能归零的上游。

只有一个特殊情况值得说：自用研究、一次性分析、无开放能力的长尾站点 （第 12 篇列过的爬虫合理场景），这些可以做，但数据必须标记为 UNVERIFIED------按第四节的机制，它们进得了你的分析库，出不了你的产品。

七、一句话收尾

两条路的差别，不在技术，在商业模式的地基：

灰色爬虫的商业模式建立在「平台没发现」上，每一天都在倒数；官方授权的建立在「平台允许」上，虽然慢，但没有倒计时。

做服务的人选哪条路，其实不是技术选型------是你打算把「客户信任」建在哪块地上。数据的生意是长生意，上游稳，才能谈 SLA；SLA 稳，才有复购。

---

我们自己做三平台接口服务，走的就是全授权链路：开放平台 + 联盟 + 持牌合作，每个字段可溯源。如果你的选品、比价、监控系统不想在数据来源上冒风险，评论区或私信聊。