ForeverBlog
一想起永久，我就想起王菲的歌有时候有时候 我会相信一切有尽头 相聚离开都有时候 没有什么会永垂不朽
我不能避免死亡，我害怕死后什么都没有留下来。
作为默默无闻的一人，没有什么闪耀，慢慢的也过了创造奇迹的年纪，我的世界一片黑暗。
想来想去，只能用老本行，科技改变命运!
曾经看过一个老美电影，就是一个极客得了绝症，为了家人，然后把自己的意识上传网络，让自己完全活在了网络中，家人还可以和网络中的极客对话。有一段时间有新闻说，可以使用AI重建去世亲人，我觉得都是同一类事情。
现阶段我只懂一些鸡肋IT，就做一个简简单单的Forever Blog吧，后面再慢慢完善下去！
现在我一个人更新Blog，以后可能会告诉家人，可以合力把Blog更起来。既然是Forever Blog，能子子孙孙的更新下去，也是奇迹呢。
作为永生博客，我简单的想法就是百年之后，博客仍然可以运行，哈哈😝，这样就可以让世人知道，曾经世上还有这人这事存在过!
新站几天不被收录？用 IndexNow 主动提交给 Bing 和 Yandex
新站为什么收录慢域名刚上线时，搜索引擎对它一无所知：没有历史、没有外链、没有抓取记录。爬虫发现的途径只有几条——别人链接了你、你在 sitemap 目录站登记了、或者你手动提交过。
即便 sitemap 提交了，排队也慢。Google 官方说法是「发现到抓取可能需要几天到几周」，新域名更要等。这段时间里，你的内容等于不存在。
有一个协议专门解决「主动敲门」这件事：IndexNow。
IndexNow 是什么一个由 Microsoft 和 Yandex 推动的开放协议（2021 年发布），机制极简：
你在站点根目录放一个 <key>.txt 文件，内容是 key 本身——证明你控制这个域名
你 POST 一个 JSON 到它的 API，列出「这些 URL 有变化」
搜索引擎收到后，把它们加入抓取队列
参与方：Bing、Yandex、Seznam、Naver，以及一些下游搜索引擎（DuckDuckGo 的部分结果来自 Bing，所以间接受益）。
Google 不参与 IndexNow，这条要记住——Google 只能靠 sitemap + Search Console 手动 ...
hexo deploy 把站点推成空白？因为用管道看了部署日志
现象：部署"成功"，站点消失一次例行的内容更新，跑完 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 全部内容 + 复制新文件），再提交。这个设计本身没问题——它保证删除的文章不会残留。
问题出在中断。
如果进程在「清空工作区」之后、「复制新文件」完成之前被杀 ...
Hyperliquid 下单报 Order has invalid price：低价币价格精度算错
现象：主币能成交，小币全失败策略在 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 完全合理——这不是交易所苛刻，是客户端送了个垃圾数 ...
4everland 自定义域一直报 Invalid Configuration？Cloudflare 橙云是元凶
现象：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 ...
Hexo 换域名后 canonical 和 sitemap 还指着旧域？完整迁移清单
换个域名，比想象中麻烦博客从 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: 行
源文件 ...
Ollama 调 API 返回空 content？thinking 模型吃光 num_predict 的排查与修复
现象：请求成功，内容为空批量给博客的 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 这个上限。
当时的请求参数是 ...