# 官方授权通道和灰色爬虫，做数据服务该选哪条路（附 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。
```python
# 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" # 来源未验证——禁止对外提供
@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}
# 封装好API供应商demo url=https://console.open.onebound.cn/console/?i=Lex
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 篇说的越权，在服务场景里是事故。
**事故二：个人信息入库。** 抓商品数据时顺手把评价里的买家昵称、地址存下来了。单条看是脏数据，攒起来就是一个个人信息库——而你没有处理它的合法性基础。
```python
# 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
# ---- 自查二：疑似个人信息字段 ----
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"),
}
# 封装好API供应商demo url=https://console.open.onebound.cn/console/?i=Lex
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 稳，才有复购。
---
*我们自己做三平台接口服务，走的就是全授权链路：开放平台 + 联盟 + 持牌合作，每个字段可溯源。如果你的选品、比价、监控系统不想在数据来源上冒风险，评论区或私信聊。*
