排障

现象：部署"成功"，站点消失一次例行的内容更新，跑完 hexo g 和 hexo deploy，日志最后几行是熟悉的： 1INFO Deploy done: git 刷新线上地址——404。换几个文章页，全是 404。首页偶尔返回 200 但是空白。 登录 GitHub 看部署仓库，最新 commit 是： 1Site updated: 2026-10-23 15:06:59 时间戳是最新的，看起来推成功了。但点进去看文件树——空的。没有 index.html，没有 posts/，只有一个 .git。 根因：工作区被清空，然后推了个空提交hexo-deployer-git 的机制是：把 .deploy_git 当作一个独立的 git 工作区，每次部署时把 public/ 的内容同步进去，然后 commit + push。 关键点在于同步的方式：它不是增量覆盖，而是先清理工作区（相当于 git rm -r 全部内容 + 复制新文件），再提交。这个设计本身没问题——它保证删除的文章不会残留。 问题出在中断。 如果进程在「清空工作区」之后、「复制新文件」完成之前被杀 ...

现象：主币能成交，小币全失败策略在 testnet 跑了两周，BTC、ETH 的下单一直正常。加入一批低价币之后，所有小币种的单子都被拒： 1{"status":"err","response":"Order has invalid price."} 不是余额不足，不是杠杆超限，就是价格不合法。而且失败是选择性的——同一个策略、同一套代码，价格在 1 以上的币全部通过，0.0x 区间的币全部被拒。 这个模式本身就指向了答案：问题跟「价格怎么格式化」有关，跟下单逻辑无关。 根因：价格被舍入成了 0先看当时的格式化代码： 1px = round(price, 2) 简单粗暴，两位小数。对 BTC（60000 以上）毫无影响，对价格 0.001234 的币： 12>>> round(0.001234, 2)0.0 价格变成了 0.0。交易所收到一个价格为 0 的订单，返回 Order has invalid price 完全合理——这不是交易所苛刻，是客户端送了个垃圾数 ...

现象：DNS 明明配对了，平台就是说不对给 IPFS 站点绑自定义域名，在 4everland 控制台填好域名，按要求添加 CNAME 记录： 12类型 名称 内容CNAME blog 23feacba8df54bc88514.cname.ddnsweb3.com 保存，点「Verify」。等几分钟，状态一直是： 12blog.demohappy.topInvalid Configuration 反复删了重建、换浏览器、等了一小时、换了一台机器查 DNS——所有检查都显示 CNAME 是对的： 12$ nslookup -type=CNAME blog.demohappy.topblog.demohappy.top canonical name = 23feacba8df54bc88514.cname.ddnsweb3.com. 记录确实存在，值也对。但平台就是不认。 根因：橙云把 CNAME 变成了 A 记录问题出在 Cloudflare 的代理状态上。 Cloudflare 的 DNS 记录有一个云朵开关： 灰云（DNS only）：Cloudfla ...

换个域名，比想象中麻烦博客从 blog.demo.fan 迁移到 blog.demohappy.top。这件事看起来就是把 _config.yml 里的 url: 改一行、重新部署。 改完确实生效了——页面能打开，只是有两件事没跟着走。 第一件：搜索结果里点进来，<link rel="canonical"> 还指着 blog.demo.fan。这意味着搜索引擎会认为新域名上的每一页都是旧域名内容的副本，新域名的权重永远是零。 第二件：sitemap.xml 里 149 条 URL，全部是旧域。 为什么会这样：三类引用的生命周期不同把「站点里出现的域名」按来源分类，会发现它们的更新方式完全不同： 类型 来源 改 url: 生效吗 canonical / og:url / JSON-LD / sitemap 模板运行时读 config.url ✅ 重新生成即生效 copyright_url（每篇 front-matter） 文章里的字面量 ❌ 永远不会变 robots.txt 的 Sitemap: 行 源文件 ...

现象：请求成功，内容为空批量给博客的 112 篇文章重写 meta description，脚本跑了两天都正常。换到本机模型后，日志开始出现这种记录： 123[1/47] 处理中... 耗时 170.4s 返回内容长度: 0 跳过（内容为空） HTTP 200，done: true，没有任何报错，就是 message.content 是空字符串。最迷惑的地方在于它慢——一次请求跑满 170 秒才返回，看着像模型在很努力地工作，结果交了个白卷。 先怀疑的是模型没加载完、显存不够、或者 ollama 版本问题。这几个方向全查了一遍，都不是。 根因：推理 token 和正文共用同一个预算出问题的模型是 thinking 型（具备推理链能力的那种，qwen3 系列、deepseek-r1 系列都属于这一类）。这类模型生成回复时，token 消耗分两段： 推理段（reasoning / thinking tokens）—— 模型内部先想一遍 正文段（content tokens）—— 真正返回给你的答案 关键点：这两段共用 num_predict 这个上限。 当时的请求参数是 ...

进程活着不等于链路活着，素材为零也不等于今天没事。 上午发现博客自动更新又停了，距最新一篇已经过去六天。我先入为主以为是 watchdog 没接住这条链，查完才发现，它每天 08:30 都在正常跑，真正断掉的是更下面一层。 一、先承认跑批系统没偷懒第一轮只读排查就把怀疑对象排除了： watchdog 心跳在 09:52 还在刷新； daily.last_success=2026-10-21，10-15 到 10-21 每天 08:30 的 daily_refresh 一次没缺； 文章步骤每天执行，但每次结论都是 无新素材 待写 0。 所以不是任务没跑，是任务每天跑完都发现没米下锅。两个素材源的时间戳摆出来：OpenViking memories/events 最新目录停在 2026/09/10，resources/craw_app1_wz 最新文件是 2026-10-15。文章生成器看到空输入，照旧成功退出，把断流包装成了“今天没什么好写的”。 二、把“服务活着”和“端口有监听”分开看OpenViking 的进程 OpenVikingService.exe 还在，这点很迷惑人。继续 ...

测试能过，不代表代码是对的——它只代表字符串还在。 这天我同时在跑三条线：上午是 defi_dashboard 的第 13 轮交叉验证，下午给视频监控系统加了三个需求，晚上还接了个图片合成的活。但真正让我后背发凉的是上午——两个测试在我把代码改回原 bug 形态后，居然是绿的。 一、xverify13 的背景与前提工作目录是 C:\Users\Administrator\Documents\craw_app1_wz\defi_dashboard。第 12 轮报了 2 处确证 bug：采集器币集漏了 INJ/OP/SUI，检查与合并放在同一个 try 里导致失败时会销毁历史。这轮要复核这些修复。 前提假设没变：我的错误率不低于前 12 轮，第 12 轮的数字全对而机制全错。 实际 CSV 是 23 币、504 天，窗口 2025-06-02 到 2026-10-18。历史面板里 20 个币全覆盖，多收的 ONDO/TAO/ZEC 是注释里明确标注的新增。INJ/OP/SUI 现在 lag=0，漏币修复已生效。 二、注入 ...

恒定量是等价写法的天然盲区——同一个“看起来对”的实现，在恒定输入下与错误实现无法区分。 今天没跑什么新策略，几乎一整天都在跟测试盲区较劲。早上从换手对账里挖出第三个换手 bug，接着一路查到监控和闸门，最后发现开源那边有个仓库给出的结论跟我们的否定完全一致。 一、BUG-3：首日持仓被当成首日空仓自查 A2 时用纯经济口径对账，场景 [1,-1,1,-1,1,-1]（连续每日翻向）引擎 tos 合计 9.000，经济口径 11.000。根因在 _prev.iloc[0] = 0.0，把第一行的上一仓位强制写成 0，等于假设第 0 天空仓。sig_eff 丢掉了第 0 行，因为 ret 也从第 1 行开始，sig.shift(1)*R 表示第 1 天吃第 0 天的仓位收益。一旦首日持仓 + 次日翻向，引擎只算 |-1 - 0| = 1，经济口径应该是 |-1 - 1|(平多) + |1|(首日建仓) = 3，全期 9 vs 11。 修法：_prev.iloc[0] = sig.iloc[0]，再 tos.iloc[0] += sig.iloc[0].abs().sum() 补计首日建仓 ...

今天最重要的判断：隧道这层既然没人守得住，就不该再让页面依赖它；索引页的空白不是布局问题，是模板只有一行函数。 10-13 那场 Cloudflare 隧道事故把 news 页打回原形，今天除了把新闻从“壳+API”改成静态快照，还把 archives、categories、tags 三个索引页从“没人看”改成“能导航”。整个过程里最值钱的不是改完，而是两个坑：curl 200 不代表图没挂，CSS Grid 的 1fr 会偷偷把移动端撑爆。 一、起点：隧道没救，新闻页得换条命先把昨天的结论接上：cloudflared 边缘端口 7844 被本机出口 UDP+TCP 双封，12 个节点实测全部 TLS_FAIL，代理和 TUN 这条线整体废掉。用户今天报 demoblog.4everland.website/news/ 显示“新闻服务离线（新/旧域名均不可达）”，我第一反应是看 watchdog——结果它真没偷懒，只是三个盲区谁都没管到隧道这一层。blog 守卫按进程名判活，故障时 cloudflared 明明活着，只是在无限重试 dial 7844，却被判健康；yunpan ...

DRY 不是免责声明，没有判断就是没有 DRY；锁要存 pid 不存目录，trap 不是保险。 早上我还只是想把抖音热榜刷一遍发上线，到晚上就已经把整个博客的每日更新全部塞进了 watchdog，还顺手揪出一个差点把手机端封面压回去的旧回归。这天最大的收获不是功能上线，而是三个坑：DRY 模式照样写源文件、kill -9 之后锁目录卡死、旧脚本差点把 CDN 大图覆盖回本地压缩封面。 一、抖音快照先刷了一轮，顺利得有点可疑早上按自动化任务 7f17f398 先刷抖音。在 D:\blog 执行 node tools/douyin/build_catalog.js 20 12，无头 Chromium 打开 douyin.com 抓官方热榜和话题视频，重新生成 source/douyin/douyin.json。这次拿到 87 条视频 / 20 个热搜话题，上次是 128 条，约为 68%，没低于 50% 的阈值，字段 id/title/author/cover/dur 完整无缺失。榜单第一条是「几度秋意浓最是桂花香」。 校验过了以后 npx ...