2025-12-18 22:43:19
手上开了一些港卡账户，除了日常的一些境外消费使用需要外，有些福利还是挺香的，比如众安 ZA Bank，交易 2% 回赠，可以直接换成现金，然后现在推广股票交易后，还可以将回赠转成想要的股票回赠。比较可惜的是，外币交易的话众安会收 1.95% 的货币转换费，无论是直接卡支付还是绑定支付宝微信，所以也不怎么用，只是偶尔在需要消费 HKD 时使用。
最近刷小红书学到了新东西，没有 HKID 的情况下，也有办法开通 Wechat Pay HK，然后通过 Wechat Pay HK 绑定 ZA Bank，这样用 Wechat Pay HK 支付的场景下，众安的卡可以 HKD 入账，这样就免去货币转换费了。同时大部分能用微信支付的场景（商户码）现在也能用 Wechat Pay HK 支付。一天使用下来，支持的范围还是挺全的。
流程如下
Wechat Pay HK 和微信切换起来也比较方便，点进去钱包，切换地区就行了。比较有意思的一个点是，切换了 WeChat Pay HK，给好友发红包和转账都是 HKD，然而如果对方没有开通 Wechat Pay HK 的话，就收不了红包。但是反过来就没有问题，别人发 CNY 的红包，在切换 WeChat Pay HK 后可以直接收下，连切换都不需要。
2025-12-14 19:51:07
国外出差了两个月，基本没有怎么看 RSS 订阅内容。之前在推特上偶然刷到说 Folo 出新的 AI 功能开始商业化，当时还以为只是出了新的 feature 来变现。
然后十二月初回到国内后就吃到了 Folo 技术人员离职的瓜，一个贡献很多的技术人员在突然被开后，写了一些很真诚的感想（只剩 RSS version 了，想看的话可以订阅用 RSS 阅读器渲染下），最后还被公关掉，甚至引起推特各种争论和公告。说实话几个 Folo 和 RSS3 的员工之前就有关注他们的博客，对项目的贡献其实看在眼里。说实话之前还可能挺羡慕他们这样能够为喜欢的事情还能远程工作，现在看来，打工都是一个样子。
然后这周打开 Folo 想看一下我的 RSS 订阅，发现商业化的行为原来已经影响到我原本的正常使用了：非付费订阅用户只能订阅 150 个源。看了下订阅价格，想了下之前的使用体验，对我来说这个订阅价格并不值得，尤其是很多时候 RSS Reader 我只是用于抓取了解是否有新内容，大多数时候我还是会跳进去博客本身去浏览内容，这些很多 feature 对我来说都是浪费。
最终重新挑选一下后，选择切换到 Fluent Reader 这个开源的 RSS 阅读器，纯本地抓取与阅读，而且完全免费。暂时使用体验也很不错，而且也没有限制订阅源数量，估计应该能一直用下去了。
回想一下觉得这种名人产出的项目/社区明星项目，其实很多时候也不见得运营得很好，或者是没有想好。产品可能是好产品，想法可能是好想法，但是商业化这些完全都没跟上，甚至我都怀疑是没考虑过？比如推特上面有解释说 Folo 收费是因为运营成本高，但是这些运营成本难道不是一开始做的时候就能预想到运营成本的？尤其是加的 AI 功能，随便算一下就能算出来要烧多少资源。运营实际上也做得莫名其妙。最开始邀请制炒得红红火火，但是居然是每个人都能生成邀请码，最后大赚的是卖邀请码的贩子，平台自己啥都没赚到。（最搞笑的是我的邀请码也是咸鱼低价买的，然后我买了之后后期又靠签到生成了两个邀请码卖出去把钱赚回来了。）
然后上一个 xLog 项目，去年有段时间推特上也是很快，号称区块链的博客平台，这个就更加完全不知道可以转化盈利的地方在哪里？无偿搭一个博客平台给大家使用，也看不出有什么需要付费获得的功能，也没有广告等流量变现的内容。看了下原作者的推特，简介里已经完全看不到这个项目的痕迹了，甚至作者自己的博客也已经从 xLog 迁走了。而 xLog 的官方推特，活跃时间也已经停在了 24 年 5 月。当时刚出的时候也掀起一股热潮，不少人可能也把自己的博客都迁过去过，我当时也搞了一个博客镜像在那里，但是后面又迁走了。实在是想不到这个平台能带来的价值在哪，在后续没有运营，没有热度，没有奖励之后，只能慢慢等待衰落和死亡。
现在回过头看，其实产品和商业化变现，并不一定就是坏事，为爱发电实际上并不可持续，合理的商业化规划，反而才能让产品变得更好和走得更远。毕竟理想主义也得靠钱烧出来。
迁移 RSS 订阅源的过程中发现，200 个订阅里面，有 20 个订阅的 RSS 链接已经访问不了了，然后剩下的 180 个订阅中，也有很多博客已经可能一两年没有更新了，what a pity.
2025-11-30 16:36:07
切换到 Windows 环境，重新设置一些软件，在拉回博客设置 hugo 的时候，又遇到了之前的 hugo 版本过高与本地博客主题不适配的问题，需要降级 hugo 的版本到指定版本。macOS 环境通过 Homebrew 管理应用，在 Windows 中通过 Scoop 来完成。
问了一下 Gemini，给的回复是 Scoop 也像 Homebrew 一样不支持安装指定版本的应用，但是可以通过指定 url 指定安装的配置文件，来安装旧版本的应用。
于是只要到 Scoop 的软件仓库，找到对应应用的配置文件，查看提交历史，找到历史版本的源文件 url 就可以了。
.json 文件（例如 nodejs.json）。https://raw.githubusercontent.com/.../commit_hash/.../app.json
然后根据这个 url 进行安装。这样通过指定配置的 url 来安装，安装下来的 app 也没有办法更新，自动就锁了版本了。
|
|
但是这样找配置文件的历史版本，实际上是非常麻烦的，需要一页一页往后翻，如果版本旧点，得翻挺久。搜了一下，发现实际上 Scoop 是支持下载应用的指定版本的。下载指定版本后，可以通过 hold 命令禁止更新。
|
|
实际上这个命令在 Scoop 的 help 命令里面都能看到，Gemini 有点不太靠谱，在后面我发现了可以下载后，还是嘴硬不承认。
2025-09-12 23:04:48
之前为了境内能够流畅地访问博客，给网站做了 ICP 备案，用上了又拍云赠送的 CDN 加速。境内访问非常丝滑，而且因为备案的原因，在微信内分享也可以直接打开，不会提示未知网站，需要多点一次才能访问。
然而备案后还是时不时有问题找过来。备案的要求也非常奇怪，网站备案除了要求域名备案，还需要有一个授权码，而授权码又来自于购买云服务器。导致即使只是部署一个在 GitHub 上的静态页面，还要额外掏钱买个云服务器，基本上就是闲置了。
突然昨天直接网警打电话过来了，因为网站之前只做了 ICP 备案，没有做公安备案。当时没有公安备案也不影响访问，而且做公安备案也比较麻烦，还有说法是甚至还要去派出所面谈做备案，干脆就没有做公安备案。现在籍贯地的网警直接打电话来问网站还用不？用的话要去做公安备案。
原本还想坚持下，把公安备案做了。后面想了想，还是算了，还是放弃备案。申请备案麻烦，各种材料，还要手写申请书，备案材料层层上交审批，搞一次得几天。然而撤销就干脆利落得多了。十一点提交的撤销申请，过十来分钟直接撤销完成了。
放弃备案之后，又拍云的 CDN 加速用不了了，应该基本国内平台的 CDN 都用不了。于是干脆迁到 Cloudflare 上，整个域名都迁到 Cloudflare 上来解析，静态内容都可以走它家的 CDN。
至此，所有域名都迁移到 Cloudflare 这个赛博菩萨上。自己试验了一下，访问速度也还好，不知道看到这边文章的大家感觉如何？
2025-08-31 12:38:08
Logseq 在打开的时候，会自动创建当天的 Journal 页面。正常来说，当打开 Logseq 的时候，确实大部分可能都是要记录，这样的 feature 看着没什么问题。然而如果 Logseq 打开后没有彻底退出，也会照常每天创建 Journal 页面。久而久之，打开 Logseq 后你将会看到一堆的空白页，让人非常不爽，而且想要浏览此前的 Journal 记录也非常不方便。
为了避免这种情况，之前都是提醒自己在用完之后，记得 commond + q 完全退出 Logseq，然后偶尔忘掉的情况，再手动删除空白页。但实际上非常容易就忘掉退出，然后又可能因为工作可能过了一周再打开，一次就积累了一堆空白页，手动一个个删除也比较费力。
一开始想的是简单写个脚本，扫一下目录里面空白的 markdown 文件，但是打开本地目录发现，空白的 Journal 页面还不一定会创建空白文件。后面上网搜了一下发现，原来自带就有这个移除功能的，而且移除的范围还不止空白的 Journal，所有的空白 Page 都能扫出来然后移除。
具体入口路径：All pages -> ... -> Remove orphaned pages
2025-07-19 14:46:50
我一直是 Bitwarden 的忠实用户，并且为了数据自由和可控性，以及省钱，选择了自建服务。我的整套配置如下：
这套组合一直稳定运行，直到今天……
今天像往常一样，我打开手机上的 Bitwarden App，想添加一个新的登录项。但奇怪的是，当我点击保存后，在列表里却怎么也找不到刚刚添加的项目。
起初我以为是 App 的 Bug，但为了保险起见，我打开了电脑客户端尝试添加，结果客户端直接提示我保存失败。
这时我意识到，问题可能没那么简单，大概率是客户端与我服务器之间的接口通信出了问题。
我首先想到的是检查我的 Vaultwarden 管理页面。我通过域名访问，结果发现了第一个问题：
(图：腾讯云因未备案拦截页面)
破案了？看起来八九不离十。证书过期导致 API 接口的 HTTPS 请求失败，客户端自然无法正常保存数据。
但新的问题也随之而来：我使用 Caddy 就是因为它能自动实现 HTTPS，可以自动申请证书并续签，为什么这次偏偏就失效了？更奇怪的是，我同一台服务器上的其他服务的域名都能正常访问，证书也都是有效的，唯独 Bitwarden 的这个域名出了问题。
我尝试重启 Caddy 服务、重新加载配置，但都无济于事。无奈之下，只能去看 Caddy 的运行日志。
日志中的错误信息揭示了真相：Caddy 在尝试申请新的 HTTPS 证书时，需要通过 HTTP 端口进行验证（HTTP-01 challenge）。然而，这个验证请求被腾讯云的直接拦截并返回了一个未备案提示的页面。
所以，核心原因找到了：腾讯云升级了防火墙策略。以前对于未备案的域名，仅仅是拦截了 80 端口的访问，而现在，它会拦截所有端口的对外服务。
这个策略直接导致了 Caddy 的证书续期 / 申请机制完全失效。
既然是腾讯云的问题，我心想，能不能把域名解析迁移到 Cloudflare，利用 Cloudflare 的 DNS 服务来绕过这个限制？
然而，当我尝试在腾讯云后台修改域名的 NS (Name Server) 记录时，发现这个选项是锁定的！想要修改，必须通过一个独立的“DNS 服务器修改”入口，比较隐蔽。
然后迁移后发现其实也没有作用，拦截实际上是发生在服务器上而不是 dns 解析上（也可能是两边都会有拦截）
最后为了稳定性和省心，选择了付费订阅 Bitwarden 高级会员，$10 一年，不再折腾。这境内的个人云服务器感觉用处越来越小，要不是博客需要备案号需要云服务器，绝对停掉转用境外的云服务器。
