改版一次,解析器就得重写
字段名换了、外面多套一层 div、列表变成瀑布流。昨晚还跑得通的脚本,今早返回空数组。
财经、舆情、开发者、媒体,这四类公开内容我们抓下来、对齐字段、去掉重复。 一个 JSON API 拉走:要全量就全量,要增量就带游标。字段是同一套,换源不用改代码。
$ curl -s "https://api.databridge.world/v1/feeds/fin-cn-macro/items?limit=2" \ -H "Authorization: Bearer dbw_live_••••"
// 200 OK · application/json { "feed": "fin-cn-macro", "updated_at": "2026-11-04T09:12:40Z", "items": [ { "id": "fin-cn-macro:9f21c8d4", "title": "央行公开市场操作:7 天逆回购 1320 亿元", "published_at": "2026-11-04T01:00:00Z", "lang": "zh", "hash": "9f21c8d4" }, { /* ... */ } ], "next_cursor": null }
到第五个,你花在修解析器上的时间会超过写业务的时间。
字段名换了、外面多套一层 div、列表变成瀑布流。昨晚还跑得通的脚本,今早返回空数组。
UA 会被封,频率得压下来,验证码得想办法过,出口 IP 得换。这些事没有做完的那天。
去重、增量、时区、编码、空值。第 12 个源犯的错,和第 1 个一样。
一个 token,一族端点。要落库、要二次计算、要喂给前端,都是同样的请求。
REST 加 Bearer 鉴权,游标增量,字段固定。第一次拉全量,之后只取新的。
GET /v1/feeds/{feed_id}/items ?since=2026-11-01T00:00:00Z &limit=100 &cursor=eyJvIjoyNDB9 GET /v1/sources # 可用源与状态 GET /v1/feeds/{id} # 单源元信息
Premium 档可以配推送地址。新条目入库就 POST 过去,带签名,验完再处理。
# 我们发给你,不是你去拉 POST /hooks/dbw X-DBW-Signature: sha256=6b1f...e0 { "feed_id": "tech-github-releases", "items": [ { "id": "...", "title": "..." } ] }
字段结构统一,解析逻辑写一次,换源不用改。
政策发布、交易所公告、行情聚合、财报日历
热搜、公开列表、论坛与公开频道、播客更新
Release、趋势榜、论文、产品更新日志、招聘
行业媒体、政府公告、独立博客、Newsletter
去重、对齐字段、处理时区,这些都在条目送到你手上之前做完。
id、title、url、summary、published_at、lang、hash,所有源都一样。合的时候不用写适配层。
游标按条目位置走,不是页码。翻得再深也不会变慢。
十家转载同一条新闻,你只收到一份。按归一化后的 URL 加标题指纹比对。
源站改标题或撤稿,条目带 revision 和 deleted 标记。标记变了,条目还在。
每个源都有上次抓取时间和连续失败次数。坏了能看见,不用等用户来抱怨。
给个端点,新条目进来直接 POST 过去,带签名头,可以验。
免费档没有倒计时,够用就一直用。升级只改三样:源的数量、每天能调多少次、入库多快。
接一两个源,看数据对不对得上
一个人维护的产品、内部工具或自动化流程
上生产,要推送、要回溯