[中文]

用途:

• 获取博主粉丝随时间的变化曲线，对应博主主页「粉丝分析 → 粉丝趋势」

请求体参数:

• user_id: 必填，博主用户ID
• increase_type: 曲线口径，1=粉丝总量(默认，累计数) 2=粉丝增量(每日新增)
• date_type: 时间范围，1=近30日(默认) 2=近60日

返回:

• list[]: 逐日数据点（当日值与日期）
• fansNumInc: 区间净增
• fansNumIncRate: 区间增长率

提示:

• 两个参数的默认值都与蒲公英网页一致（粉丝总量 + 近30日）
• 要看每日新增曲线请传 increase_type=2

响应结构（取数要剥两层）:

• resp["data"] 是蒲公英原样信封（含 code/msg/success），业务数据还在它里面一层
• 正确取法：data = resp["data"]["data"]；下面「返回」列的字段都在这一层下

计费:

• HTTP 200 → 计费。包含「查无结果」（data 为 null，如 ID 不存在或筛选无命中）—— 请求已送达蒲公英，同样扣费，不要因为拿不到数据就重试
• HTTP 400 → 不计费（参数格式非法，或上游资源不足/异常）

[English]

Purpose:

• Fans growth curve over time ("Fans Analysis → Fans Trend")

Request Body Parameters:

• user_id: required, blogger user ID
• increase_type: 1=cumulative total (default), 2=daily increment
• date_type: 1=last 30 days (default), 2=last 60 days

Return:

• list[]: daily data points
• fansNumInc: net growth over the period
• fansNumIncRate: growth rate over the period

Tip:

• Defaults match the PGY web page (cumulative total + last 30 days)
• Pass increase_type=2 for the daily-increment curve

Response shape (two layers):

• resp["data"] is PGY's raw envelope (with code/msg/success); the payload is one level deeper
• Correct access: data = resp["data"]["data"] — every field listed under "Return" lives here

Billing:

• HTTP 200 → charged, including "no result" (data is null, e.g. ID not found or filters matched nothing): the request did reach PGY, so retrying on empty data just burns quota
• HTTP 400 → not charged (malformed params, or upstream unavailable/error)

[示例/Example]

// ① 累计粉丝数曲线（默认，近 30 日）
{"user_id": "5c668b3e0000000012021605"}

// ② 每日新增曲线，近 60 日
{"user_id": "5c668b3e0000000012021605", "increase_type": 2, "date_type": 2}

// ③ 累计曲线拉到近 60 日
{"user_id": "5c668b3e0000000012021605", "date_type": 2}

increase_type=2 的曲线出现孤立尖峰，通常意味着买量或蹭到热点， 选号时值得再看一眼那几天的笔记。

Isolated spikes in the daily-increase curve usually mean bought traffic or a viral hit.

{
  "user_id": "5c668b3e0000000012021605",
  "increase_type": 1,
  "date_type": 1
}