数据工程

只读一天，我才明白哈希锁能冻住策略，却冻不住一个没有测试的采集器。 今天上午知乎那篇债市问股市的文章刚上线，下午我就钻进 C:\Users\Administrator\Documents\craw_app1_wz\defi_dashboard 开始第 12 轮交叉验证。说好只读不改，结果还是挖出两个确证 bug，而且其中一个藏在最不容易被发现的地方。 一、为什么今天要“只读不改”这一轮叫 xverify12，工作目录没变。第 11 轮报了 3 处确证 bug 加 2 处我说错，全修了。用户又做了四件事：新增 funding_collector.py 注册进 watchdog.py、新增 validation/fetch_dvol_history.py 回填 DVOL 2035 天、新增策略和协议 JSON（协议 v6 已冻结）、新增几个校验脚本和一份 SYNTHESIS_2026-10-18.md。前提假设不变：用户这一轮的错误率不低于之前，上一轮的数字全对而机制全错。 所以我只做独立复核，不碰一行代码。 二、n_coins 对不上，币集口径先炸了复核项 1 是 funding_col ...

金句：新闻站的坑从来不在接口签名，而在图片域名和 CF 隧道的配置合并。 今天把书库骨架复用成新闻聚合站，从上午接口验证到晚上日期归档，基本是一天打满。写这篇时站已经改叫「头条资讯」，入口挂在 https://news.demo.fan。 一、仿书库的骨架，新写的只有采集器、新闻库、新闻页书库那套东西是现成的，Flask 8800 后面跟只读网关，再走 CF 隧道，最后用看门狗守护。新闻站真正要新写的只有三块：采集器、新闻库、新闻页，剩下全部复用。 落地后的架构很干净： news_fetcher.py --loop：采集器，热榜 5 分钟一轮、频道流 15 分钟一轮，带单实例锁和 30 秒心跳文件 .fetcher_heartbeat data/news.db：SQLite，四张表 news / hot_snapshot / fetch_log / meta news_server.py :8802：纯标准库 http.server，零依赖 news_gate.py :8803：只读白名单网关，fail-closed，POST 全部 403 watchdog.py：三段守护，分别探活 ...

不要急着改前端，先拿 SQL 把 572 万行逐行比对钉死——老表的 WORKER_NUM 就是真实人数，上一版却按 ×10 把它除成了 0。 2026-09-14 这天挺满。上午刚把 Hyperliquid testnet 的 drift 3341.32% 告警挂出去，下午就被叫去修一个 MES 报表：工位利用率、出勤时间、有效工时，显示得全不对。表面看是前端渲染有问题，实际一查，口径从根上就反了。 一、问题现象：所有指标都长得不对劲接下活的时候，用户给的是 100.64.0.2:3306 上 m3_ai_data 库的 work_load_0521 表，里面有示例数据。前端报表展出来的工位利用率、出勤时间、有效工时，没一个看着合理。当时我没急着动逻辑，先让脚本把表的概况拉出来。 这一拉就发现问题不小： AREA 一共 14 个，前端只认 5 个； MAIN_AREA 分布是 TST1 约 450 万行、TST2 约 77 万行、TST3/TST4 各约 22 万行； WORKER_NUM 的值是 '0'~'7'，看着像真实人数，但我们上一 ...

两个数据源如果答案一样，那第二个就没有存在意义 GMGN 用了一整周，能挖的字段基本都挖过了。但有一类信息它天然给不了：市场热度、社媒包装、广告投放、多池流动性快照。 这天做的事，是把 DexScreener 接成第二个数据源——不是替换 GMGN，而是补它的盲区。 先想清楚：为什么要第二个源结论很早就定了，而且这次是先想清楚分工再动手： DexScreener = 市场热度 / 社媒包装 / 广告投放 / 多池流动性快照GMGN = 链上聪明钱 / KOL 成交流 / 安全字段 / dev 信誉 / trenches 新币热榜 这两份能力清单几乎没有交集。GMGN 擅长看链上的人在干什么，DexScreener 擅长看市场在关注什么、项目方在花钱做什么。互补，不重复——这是接入的前提。如果第二个源只是把第一个源的数据再抄一遍，那接它纯粹是浪费。 8 个端点，全部不要 keyDexScreener 的公开接口实测下来很友好：全部返回 200，无需 API Key。 接口 用途 限速 ...