Lawtee | 法律小茶馆的 RSS 预览

写微信公众号和写博客的区别

2025-09-10 18:20:00

从 9 月 1 日老T正式开始启用公众号算起，到今天刚好 10 天，这 10 天说短也短，说长也长。短的是，自 2008 年老T开始网络写作以来，这 10 天几乎可以忽略不计。长的是，这 10 天算是老T 17 年写作历程中收获最多的时期，充满了新鲜感和挑战。

微信公众号简要回顾

这 10 天里，老T公众号共更新 10 篇文章，其中 8 篇都是从博客搬到公众号的，只有 2 篇是近期新作。

在 8 篇搬迁的文章中，前 4 篇基本就是直接从博客复制粘贴，后 4 篇经过了大范围修订，几乎相当于重新写了一遍。

10 篇文章共计阅读量 2.2 万，其中最高的约 1 万，最少的 17。

另外，老T也收获了首个赞赏，来自安徽的网友 @Chulixia, 在此表示衷心的感谢！

微信公众号与博客的区别

本来，老T以为微信公众号只是另一个信息发布平台，在已有文稿的基础上，简单发布即可。但由于微信天然的社交属性，这种想法很快就破灭了。微信公众号和博客看似都是写作平台，但本质上差异巨大，尤其是传播机制、读者互动和写作要求等方面。下面，老T就结合这 10 天的亲身经历，谈谈几点主要区别。

订阅数

微信公众号的价值很大程度上取决于粉丝数。粉丝越多，推送就越稳，阅读基数越高。老T这 10 天，粉丝从 0 涨到 100+，主要靠算法推荐拉新。但目前粉丝基数很小，新文章容易石沉大海。

博客的订阅数（比如 RSS 或邮件订阅）则没那么关键。博客读者往往是零散的搜索流量，订阅只是锦上添花。老T的博客订阅者不多，但文章通过 SEO 优化，也能持续吸引新访客。简单说，微信更像是是“粉丝经济”，而博客一直是“内容长尾”，前者靠积累人气，后者靠积累内容。

另外，这里老T再补充另一个经常使用的知乎平台情况，完全是另外一套逻辑的。知乎既不靠粉丝数，也不靠搜索引擎，甚至也可以说不靠算法推荐。因为它默认使用算法将问题推送给所有潜在创作者和读者，创作者只需要沿着知乎推荐的问题进行回答即可获得大量自然流量，也算是另一种“算法平权”。例如，老T最近一个月在知乎的回答几个问题，累计阅读近 40 万，绝大多数阅读量都来源于用户被知乎问题所吸引而点进页面后查看的。不管是作为创作者还是用户，老T都完全不用担心算法或关注数的影响。

写作风格

这 10 天下来，老T感觉微信公众号的生态不适合太长、太专业的写法。读者大多用的是碎片化时间在阅读，刷朋友圈或订阅号时，更喜欢短平快的内容。老T花大力气写了几篇 5000 字以上的长文，比如分析印度强奸率、研究外国人如何看待93阅兵等，但阅读量和推荐最多的，反而是飞牛 NAS 相关的那些 2000 字以内的实用性文章。当然，这也可能因为内容差异，几篇长的文章，公众号后台审核后都明确不给推荐。

博客则更注重专业性和深度。没有什么限制，可以尽情展开，写成万字长文也没关系，因为读者是主动搜索来的，往往有特定需求。老T在博客上写的那些长篇内容，阅读量虽不高，但反馈很专业，读者留言讨论也更深入。微信像快餐，博客像大餐，前者求速，后者求精。

结语

总之，这10天让老T深刻感受到，微信公众号更像一场算法游戏，需要不断试错、优化。而博客则更适合个性化创作，注重长效价值。当然，两者不是非此即彼，老T会继续双管齐下，保持两边同步更新。希望这些心得对其他创作者有帮助。如果你也有类似经历，欢迎留言交流！

码字百万之际—开通个人微信订阅号

2025-09-06 09:30:00

昨天在 QQ 群看到朋友说我码字已经超 100 万。确实，截止目前，Hugo 统计 359 篇文章，已合计 1036977 字。其实这个统计在到八九十万的时候，我还是比较关注，毕竟很快要到 100 万，心里还有点激动。但真等到后边恰好破百万时，又没怎么在意了。这让我想到心理学中的目标达成悖论：人们往往在追求目标时投入巨大情感，真正实现后却可能产生空虚感。

回顾码字经历

这次码字破 100 万，也许是个迟来的“成就”。毕竟，熟悉老T的老朋友，特别是从 2008 年开始一起加入 Blogfans 的老兄弟们，都知道我曾经多次大量删除过以往的文章。按照老T在 2017 年留下的老 Mysql 数据库统计，当时字数就已经有 114 万，只是当年并没有去想过这个问题。而如今留下的这些内容里边，属于 2017 年以前写的，占原本比例应该不足 1/4 。不过，不管怎样，这次破 100 万，对自己来说还是有一定纪念意义。

最初想法

回顾老T 2008 年以来码字的经历，我想正是印证了最初写下的那句 When each sunrise, we start a new. 虽然在当年，这句话更多表达的是新生之意，晨光初启、新途又始。到后来，随着日复一日的坚持更新，这句话逐渐演变为红日再升、新章复启。如今，站在新的起点，我更多的在想，这很可能又是一个破晓之时，需要境界新开了。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12



---
title: "您好, 世界!"
slug: "hello-world"
date: 2008-05-21
categories: ["技术"]
tags: ["WordPress"]
---

经过十多小时从零开始的学习，我终于开通了自己的第一个网站。
在这里我要特别感谢抓抓，要是没有他在最后一刻发出的消息免费提供了本网站的主机空间，我就真的去租新业在线的服务器啦!
同样我也要感谢身边的朋友，不管是风雨与共的兄弟姐妹，还是素未谋面的远方朋友。今后还得靠大家大力支持，我才能有更好的进步喔! ^_^
> When each sunrise，we start a new.

老T在学生年代，语文成绩一直很差，讲话也不利索。一时头脑发热开始码字后，也不知道写什么好。

于是，便从流水账日记开始，强迫自己坚持更新。也不管网友看了什么感想，反正就是我行我素。

也就是在这种简单幼稚的做法中，老T 逐渐开始放飞自我。看到啥，想到啥，都一股脑写下来。

以至于后来，老T再去回看自己曾经写下的文字时，很多内容，自己也看不懂了。

毕竟，那些文字很可能就是不知道在哪看到一段话、一件事之后，一瞬间的想法。

码字方向

在最初码字的那几年里，老T的文字，主要还是聚焦校园生活。

2011年，在老T进入社会开始打拼后，码字方向逐渐向工作靠拢。

特别是老T误打误撞进入 IT 行业的那段日子，几乎每天都能学到大量新知识，留下了很多 IT 笔记。

以至于后来的一段时间里，老T一直在纠结一个问题 —— 个人写作到底要不要保持一个固定的主题方向。

然而，就像晨光初启时的历程，总需要自由地延展边界，这么多年来，老T完全是出于个人爱好在坚持，“我行我素”这个“光荣传统”也自然保留下来。

老T在 Hugo 上简单统计了目前留存的 359 篇文章，其中生活类的 109 篇，技术类 74 篇，法律类 68 篇，社会类 34 篇，另外还有 65 篇大杂烩。

在未来一段时间里，老T的这种分散的主题风格，毫无疑问会继续保持下去，不过也会适当节制一点，争取在“自娱自乐”和“知识共享”之间，取得更好的平衡吧。

微信公众号

多年前就有朋友劝老T，为啥不搞个微信公众号？个人主要有几点担忧。

公众号需要较为固定的码字方向。 前边提到，多年来，老T码字并没有特定方向。如果前一天还在谈如何维修智能马桶盖，后一天就变成要素式起诉状的写作技巧，确实不怎么像话。但也正如目前老T公众号所展示情况，这个问题，真是无解。只能寄希望于各位已经关注老T的朋友多多包涵！
公众号的写作方法有明显差异。 老T之所以不用公众号，很大原因是因为公众号属于“封闭式”平台，很难与外界联通，里边的东西出不去，外边的东西进不来。而 Hugo Next.js Astro 等开源平台则完全不同，这些平台往往都以创作为中心，作者只需要专注写 Markdown 文档，随地存放，随时搬迁，其他事情，都可以交给自动化程序完成。哪怕是老T早年使用的 WordPress, 也可以实现一键同步发送到微博、知乎、简书、掘金、CSDN、typecho等众多平台，显著解放生产力。

公众号的内容写法有很大不同。 目前，使用开源平台进行创作的朋友，绝大多数都具有一定的 IT 互联网学习、从业基础，平常多数交流也是围绕这些方面进行。很多名词、方法、工具，大家都耳熟能详，一点就透。但微信公众号这边，由于受众更为广泛，原本写作方式需要进行转换，需要重新下不少功夫。

事实上，老T几年前就注册了微信公众号，当时也随手复制两篇文章测试 CMS 功能，深感不便后，便没再折腾了。

为何开始搞公众号

说来也怪，作为一个向来对封闭平台嗤之以鼻的“老顽固”，老T自己也没想到，居然主动捡起了尘封多年的公众号。

就像高中时在 QQ 空间写火星文装深沉，如今也不得不向现实低头。倒也不是突然开窍觉得公众号有多好，而是发现身边那些技术老哥们，一个个都偷偷在公众号上安了家。

这感觉就像在当年在网吧通宵时撞见数学老师，一阵尴尬后，各自默契地开了一台机子。

技术问题已经基本解决。 老T前几个月在帮朋友解决微信公众号排版编辑过程中，研究了一下如何将 Markdwon 文档渲染后一键复制到微信公众号编辑器，目前已经显著降低文章同步发布到微信公众号的难度（不过还是得手动登录微信公众号后台捣鼓一番）。
内容沉淀与多元化考虑。 多年码字下来，老T意识到开源平台虽灵活，但受众多为同圈好友，而公众号的多元受众特性，能帮助内容抵达更广泛的群体，从而促进知识跨界的交流。例如，在老T的好友文章订阅列表中，随便用一个冷门 AI 大模型名称去搜索，都能找到大家写过的不少文章，但如果这些 AI 方面知识仅仅只在技术圈内传播，显然也不利于 AI 发展和社会进步。
纪念里程碑的新起点。 码字百万，恰似老T人生旅途中的一个驿站，而重启公众号就像在这个驿站点亮一盏新灯。这不仅是为了记录这个特殊时刻，更是老T想在新平台尝试更贴近生活的一种表达方式。毕竟，写作的本质在于分享，而非自赏。

关于码字频率

在启用微信公众号后，老T依然会保持原有的码字节奏进行。主要利用下班和周末时间来更新，每周大概能更新 1-2 篇文章。

前期频率可能会高一点，毕竟老T还有比较多的“存货”，之后还是会回到既有节奏上来。

关于公众号名称

老T几年前注册“观北”这个公众号名字时也没想太多，是按照以往注册域名的一贯思维，想着尽量短一点、简单一点、好记一点。“观北”这个名字也没有什么特定含义，跟“北方观察”这种字面理解也没有任何关系，只是因为需要先注册中文名再选英文名，顺手就写成 watchnorth。

就如“老T”这个名字，也仅仅是因为家中小孩的一句戏言，再加上网上一搜发现用的人也少，就这么定下来的。

为何1000M宽带，有时候测速只有300M（二）

2025-09-05 11:30:00

2020年，老T曾以这个标题写过一篇简单的文章，主要是因为当年在百度上搜索这个问题答案时，找到的都是千篇一律洗稿内容，鲜有能够讲清这个问题的文章。

甚至可以说，当时网上大多数关于这个问题的解答都是在瞎扯。有些讨论下边，还各种对提问者挖苦、讥讽，认为提问者丝毫不懂网络常识，但又不给出解决问题的思路办法。由于当年老T也恰好遇到这个问题，便进行一番研究。

现今5年过去，国内网络环境又与此前有了一些不同，千兆宽带已成标配，甚至万兆宽带也开始进入部分家庭，老T觉得有必要重新对这个问题进行梳理。

为何1000M光纤宽带，测速只有300M？

当年老T遇到这个问题，首要原因就出在路由器上。

在1000M光纤刚开始进入千家万户的时候，由于多数家庭用户还在使用旧型号路由器，有些路由器虽然参数上写着支持 1000Mbps 网口，但那个网速只是供内网传输使用的，内外网之间的速度并不能达到 1000M。

也就是说，在内网配置没有明显问题的情况下，用户将两台电脑同时用网线连接到路由器时，这两台电脑之间的内网传输速度能够达到 1000Mbps。

而当用户通过这台路由器连接外网时，这时由于路由器内部芯片处理能力限制，传输速度就会骤减至 300-500Mbps。

老T 画了个示意图，争取把这个逻辑展示清楚。

5年前，不少家庭用户都是因为这个情况导致测速结果达不到运营商标称的速度。

例如：

网件 R7000 WAN TO LAN 最大速率：931 Mbps
网件 R6300v2 WAN TO LAN 最大速率：806 Mbps
华硕 AC68U WAN TO LAN 最大速率: 754.5 Mbps
TP-LINK TGR1900 WAN TO LAN 最大速率: 631 Mbps
网件 R6100 WAN TO LAN 最大速率: 93.1 Mbps

不过，当年老T 遇到的问题比这个还稍微复杂点。当时，老T使用的正是上边列出来的网件R6300v2这款路由器。可以看到，这款路由器最大 WAN TO LAN 速率达到了 800Mbps。但老T 当年死活只能测出来 300Mbps。

最后，老T研究一番发现，原来是因为自己对这款路由器进行了刷机的原因。原本路由器默认能够支持到 800Mbps 以上速度，但是在刷系统之后，这个功能被第三方系统默认关闭，只有在重新开启

NAT硬件加速（Hardware NAT）或 CTF 直通转发（Cut-Through Forwarding）功能后才能恢复到 800Mbps 以上。

如果确认自己的老路由器性能较低没法支持高速转发，一般也只能换路由器解决了。好在，目前当下主流路由器基本都能够支持到 900Mbps 以上的转发速率。例如。采用高通或博通芯片的千兆路由器（如小米AX系列、华硕AC系列等等）。选购时可参考路由器官方参数中的“WAN-LAN吞吐量”指标。

为何1000M光纤宽带，测速只有900M？

如果说前边1000M测出来只有300M算比较极端的情况，那1000M测出来只有900M则是普遍情况了。

导致这种情况的原因非常之多，个人觉得也没有太大必要纠结这个问题。毕竟 10% 以内的速率损耗，在日常网络传输中，真不算个事。

除了测速时会感觉稍微不爽点，日常使用时真是感觉不出什么区别。

这就好比标称100公里的电动车，实际跑个90多公里，日常开完全够用，没必要在乎剩下那点损耗。

不过，抱着刨根问底的态度，老T还是使劲查找了一番，大致有以下原因：

网线问题

没错，就是网线。我们很多时候光盯着路由器和光猫，却忽略了最基础的网线！

老T前阵子在家里玩游戏时，曾一度遇到个稀奇古怪的 Bug。就是在新买的游戏电脑上玩 CS2 时，偶尔会遇到断网问题。

一开始，老T还以为交换机出了问题。此前，老T 桌面 NAS 是直连墙插的，笔记本也用的无线 WIFI，没有使用交换机。自然想到，是否因为添加交换机导致故障。

但将电脑直连到墙插，绕过交换机使用，好像也没啥区别，该来的还是会来。然后老T就开始排查墙插到上层交换机的线路，不过，一顿排查下来，并没找到原因。毕竟，家中其他设备都运行正常，此前也没出现过这种问题。过程中，老T 还反复卸载这台游戏电脑的网卡驱动、主板芯片驱动。

这个蹊跷的问题，主要也是不必然发生，可能前一周每天用的都好好的，下周突然就遇到，导致这问题也拖了很长一段时间。

后来，有一天老T在抖音上刷视频时，偶然刷到一个 IT 运维类 UP 主排查某次网络故障的内容，他最后定位问题原因是在网线上：在某公司数百条网线中，夹杂了一条不合格网线，导致一名员工的电脑间歇性断网。

老T此前虽然也对是否因为网线故障而导致间歇断网产生过疑虑，但更多的是基于经验判断：家中大部分网线都是自己用压线钳压的，其中个别接头压的都不是很到位，确实在刚入住那段时间出现过问题；但游戏电脑上这条网线可是我专门在京东买的成品，一体成型的网线接头，没道理会出故障。

后来，老T尝试给这台游戏电脑更换一条网线，果然，更换之后，再也没遇到这个故障。

光纤问题

相比普通网线，光纤这边出问题的几率更大点。其中，最主要就是光纤缠绕问题。

与网线可以各种缠绕、打结甚至当跳绳（当然不推荐！）还能凑合用不同，光纤这玩意儿，很是娇气！对弯曲的角度和半径要求很苛刻。

没办法，这玩意传输的是光信号，不是电信号。光在玻璃丝里跑，拐弯太急或者被硬生生折出个小圈圈，光信号就“漏”了或者“跑偏”了，直接导致信号衰减，网速下降、延迟升高，甚至频繁断网。

有时候自己在弱电箱折腾设备时，很容易把入户光纤弄折或者挤压。此时，网速变慢甚至断网都不奇怪了。

这里老T也“自曝家丑”给大伙看看自家弱电箱的惨状。其中，中间那根细黄色的就是入户光纤。在这种糟糕的使用环境下，想保证光纤不被弯折、缠绕，也确实不容易。

光猫或路由器问题

这点可以参照前边第一部分内容。也就是路由器或光猫本身 WAN TO LAN 速率只能支持到 900M。其中，相对来说，路由器的可能性更高点。因为光猫的芯片和固件基本都是运营商深度定制的，唯一目标就是在完成光电转换+基础NAT 时，一般都能跑满带宽。

路由器方面，老T在国外专业技术网站上查询到，哪怕是售价数千元的华硕高端万兆路由器，如果只连接它的1000M网口，测出来 WAN TO LAN 最高速率也只能到 920Mbps。Chiphell 恩山等国内技术论坛上也都有近似的评测结果。

测速网站问题

老T经常使用网上各种测速工具，比如 Speedtest Cloudflare 等网页测试，融合怪、NodeQuality 等脚本测试，但这些网络工具最大的问题是很难对家庭网络进行测试。比如，在 Bing 中使用 speedtest 测速时，可能并不会连接自己家中最近的服务器，结果偏差就比较大了。

网络上各种测速工具五花八门，不同测速工具测出来的结果可能天壤之别。最主要就看用户测速时所使用的网络、所选择的测速节点和地理位置。

如果选了个离自己十万八千里、或者本身就很忙（很多人同时在测）的服务器，测出来的速度肯定比实际低很多。

在跨运营商网络测速使用方面，大多数网民经过多年熏陶，都已经知道不会有很好的结果。近年来出现的一个新问题是，运营商在以往跨网结算的基础上，又增加了同运营商之间跨省级公司之间的流量结算。容易导致异地测速结果进一步降低。比如，老T曾测试了广东移动到江苏电信的 UDP 连接速度，反复多次试验，也只测得不到 100K/s 的网速。当然，老T这个案例比较冷门，一般我们上网用的大多是 TCP 协议，而 UDP 更常使用在游戏方面。但无论如何，跨运营商、跨地区测速客观上都不会有太好的结果。

这里，老T也推荐几大自己觉得非常好用的测速网站，主要就是国内几个著名高校的公益测速站。包括：中国科技大学测速、南京大学测速、东北大学测速等。这些网站没有杂七杂八的广告，用起来也极致简单，一打开网页就自动测速。

但要说这些测速网站里边哪个最准，从老T多年经验来看，也只能说都是玄学。

协议开销

这是老T在网上查技术文档看到的，从名字上看，也是最“玄学”的问题。

这个问题，从技术角度来看，意思是：我们日常传输的网络数据基本都不是在“裸奔”，外面全都包着一层层的“衣服”（TCP/IP包头、校验码等）。这些“衣服”大概要占总数据量的5%-10%。

也就是说，办一条 1000Mbps 宽带，实际能用来传输自己想要的“数据”（比如电影文件）的速度，理论最大值也就950Mbps左右（1000*95%=950）。这是网络通信的基本规则，牛顿来了也改不了。

为何1000M宽带，上传速度只有30M？

讲完下载速度跑不满的各种“委屈”，老T再来说说上传速度这茬。

不少用户在办了千兆宽带后兴冲冲测速时发现：下载速度确实能蹭到八九百兆，接近运营商吹的“千兆”，可上传速度却像个害羞的小媳妇，常常缩在30-50Mbps，死活不肯往上走。

这可以说是国内家庭宽带的普遍现象了。从二十年前老T刚接触网络开始，这问题就一直存在。“下行千兆猛如虎，上行百兆慢如蜗”，不管你家里办的是 200M 300M 500M 还是 1000M 哪怕是万兆宽带，上行速度也可能都在 30-50M 这个范围内。

这里，老T也不想讲太多（主要是PON网络非对称设计的历史包袱+运营商成本控制），只说两个近几年越发明显、且容易被大家忽略的“新问题”。

高峰期临时性限速（QoS策略）

运营商一般都有各种 QOS 策略对网络传输使用量大的用户进行限速。这种规则一般都是写在宽带套餐的“小字条款”中，最主要就是晚间网络高峰期会出现。

其实也很好理解，就像大城市车辆限行一样。运营商的网络高速公路建设好后，一段时间内很难再继续更新扩容。一年中大部分时间内，可能这些路上都没什么车，可一旦遇到节假日便开始拥堵。

运营商为了保障晚上黄金时段（通常是19:00 - 23:00）大多数用户能“凑合刷个视频不打转”，会对整个区域网络启动更严格的动态 QoS 策略。这玩意平时不明显，一到节假日就有可能出现。特别是长期占用高带宽、大流量的用户，可能感受更加强烈一些。

打击 PCDN （黑名单策略）

据老T观察，这几年网上不少“受害者”集中“控诉”的一个事情就因涉嫌使用 PCDN 技术被运营商列入黑名单。

PCDN 是啥？简单说就是用户用自家宽带上行带宽帮企业（比如某心、某云）做内容分发，赚点电费钱。

但对运营商来说，这是用家庭宽带的低价套餐，挤占昂贵的骨干网资源，妥妥的“薅羊毛”行为，必然重拳出击。一旦检测到家庭宽带流量模型像PCDN（长时间满速上传、特定端口高连接数），轻则限速上传到 10M 以下，重则直接断网+上门签保证书！

据老T了解，各地运营商对 PCDN 的判定标准有一定的差异。但主要标准是以下几个。

上传数据量。比如，有的地方大概是连续单日上传 100G 数据就容易被标识为 PCDN 用户，而有的地方这个标准甚至下探到 50G；另外也有按照月流量来统计的，比如每月上传流量达到 2TB 或 4TB。以单日上传 100G 为例，相当于24小时连续以 9.3Mbps 的速度上传。
上下行比值。比如，上传数据是下载数据的 10 倍、20 倍甚至 50 倍的，完全超出超出普通家庭宽带用户的使用逻辑。
连接数和其他。包括网络连接数，用户和其他宽带用户之间的数据交互次数，用户和 PCDN 厂商之间的数据交互次数等等。运营商通常有特定模型对这些行为进行识别，从而实现精准打击。

需要注意的是，老T也在各种技术论坛看到不少网友提到，自己只是将家里文件传到网盘，只是在家里长时间搞网络直播，只是在外长时间远程控制家中电脑设备等原因，就被运营商错误标识为 PCDN 用户，经过反复投诉才解决。弄得一些网友连正常使用都不敢了。

老T觉得，这种如“惊弓之鸟”一般的想法倒也大可不必。毕竟，我国几大运营商都还是国有企业，正常网络带宽使用，大概率不会有啥问题。老T这几年也经常使用 NAS 将数据同步上传到网盘，并没有遇到过被“误封”的情况。真要遭遇“误封”，老T建议是收集好证据后积极向当地电信行业主管部门投诉，也不要动不动就去找工信部，很多时候“县官不如现管”，在当地处理，灵活度更高。

对于真正的 PCDN 行为，此前，老T也接受过个别网友法律咨询，说其在与运营商反复周旋之后，都未能解决，是否可以起诉运营商，毕竟与运营商的服务协议中并没有这种内容。但老T在裁判文书网上看了一圈案例后，还是建议他作罢，一方面诉讼成本不少，另一方面胜诉率也不高。还不如换一家运营商，或者以家中其他人名义重新办理更简单。当然，重新办理后如果还是继续搞 PCDN，那也只能说抱歉了。

当外国人看93阅兵时，他们在看什么

2025-09-04 16:30:00

纪念中国人民抗日战争暨世界反法西斯战争胜利80周年阅兵仪式在昨日隆重举行。老话说，国之大事，在祀与戎，而和平年代的阅兵式，正是这两件事的完美结合。作为当今世界最受关注的事件，老T在网上冲浪过程中，也看到不少外国人的评价，其中很多都比较有意思，这里也简单跟大家分享一下。

俄罗斯人如何看待93阅兵

老T在日常混迹的多个技术论坛上都看到有人发贴讨论中国的阅兵式，其中最典型的评论就是：“看吧，中国果然没有向俄罗斯提供武器，不然战争局面早就改写了。” 由于在多个平台都看到这种评论，老T也感觉摸不着头脑。只能说，相比西方媒体这些年大肆宣扬的“中国威胁论”，西方民间对俄罗斯的恐惧感，确实是入心入肺了。

由于我们这一代人都在亲身经历中国工业现代化进程，对国内的制造能力早已有充分认识。哪怕按照最朴素的唯物主义思维也知道，一个常住人口和GDP都比不过广东的国家，制造能力显然跟中国有巨大差距。

但西方老百姓长期受媒体偏见影响，对中国的这种能力认识还是存在较大偏差。而此次阅兵展示，一定程度上也算是在帮他们纠偏。

不过，在这过程中，我也很好奇，就是作为这种评论里的另一方，俄罗斯人会如何看待中国阅兵呢？

老T特意找了些懂俄语的朋友帮忙，也翻了翻俄罗斯两大社交平台 VK.com 和 Pikabu.ru，了解下到底俄罗斯普通网友有何观后感。

“大受震撼”的技术派

主要评论包括： “规模惊人！技术顶尖！” “正步完美，装备像科幻片” “机器狗和核导弹？中国准备好应对一切了” “水下无人机和机器人才是未来战争，中国AI武器领先了” “新型坦克配高超音速导弹…北约想清楚要和谁打了吗？”

照老T说，这反应在我们这边看来也还算实在。我们天天看着“下饺子” 新装备官宣，可能有点习以为常了。但对俄罗斯人来说，这次阅兵式上展示的装备，特别是高超音速、无人机、AI 这些新装备，确实刷新了他们的认知，甚至带点羡慕嫉妒。毕竟毛子那边也是一堆搞军工的，一眼就能看出门道高低。他们这个“科幻片”的评价，跟我们网上常说的“过于先进，不便展示”也算是有异曲同工之妙。也说明我国这些科技树也确实是点到位了，把老邻居都“震”住了。

地缘政治说

主要评论包括： “中俄朝三位领导人同台——这是给西方的信号！” “中国展示核力量就是领导权宣言，特朗普气疯了” “世界在变，美国中心要没了，这对我们俄罗斯人好” “这是个反西方联盟！” “中国不可威慑，这是给世界的警告” “俄罗斯会不会成了中国的桥头堡？普京在阅兵上像路人…”

这部分就挺有意思了。很多俄罗斯网友，把三国领导人同框解读成“反美统一战线”，觉得中俄抱团取暖对抗西方是好事。他们挺享受这种“世界秩序要变”的感觉，觉得能削弱美国挺好。不过，也有些人担心：中国实力这么强，又这么高调展示，俄罗斯会不会慢慢从“盟友”变“小弟”或者“前哨站”？这种“既想靠大树乘凉，又怕被树荫完全遮盖”的矛盾心态挺明显。

其实，这次我国搞阅兵主要还是聚焦自身发展和对历史的纪念，展示实力也是国家发展的自然结果。至于“对抗联盟”的解读，更多是外界自己加戏了。至于俄罗斯的地位，那得看他们自己怎么走。

吃瓜与调侃的围观

主要评论包括： “有成龙吗？想来场天安门动作戏！” “要是特朗普看到，肯定要搞个带广告的阅兵！” “中国军演像科幻电影，好看但实战咋样？（引用俄军经验）” “看了三小时直播！这女孩分享的彩排片段好感动。”

老实说，全世界网民都一个调性，围观、看热闹、玩梗都是常态。调侃特朗普（真是全球顶流）、cue成龙、甚至拿俄军在乌克兰战场的拉跨经验来质疑阅兵式军队的“实战性”，都是普通网友的自然反应。其中，也有被宏大场面感染，或者被某个小细节打动的。就像老T，始终对战士们在阅兵时从车后跳进车内时的行云流动作佩服至极，也算得上是“人类围观行为学”的普遍现象了。说明阅兵式除了硬核展示，也确实达到了吸引眼球、引发情感共鸣的效果。

美国人如何看待93阅兵

说完俄罗斯，那势必得提提阿美利坚。毕竟，老T在观看直播时，一个很明显的感受就是，这次集中展示这么多新装备，一个重点的目的应该就是让阿美利坚好好冷静一下吧。特别是东风5C拆成3段展示，感觉就是担心川普那草台班子看不懂。

老T 试着汇总了一下美国贴吧、美国知乎和常逛的几个技术论坛上一些评论。总体感觉就是，来自美帝这边的评价，看起来就是“离散值”高得离谱，有的评论从技术角度客观冷静得惊人，有的插科打诨，有的歇斯底里，分化的特别厉害，不知道这算不算美帝内部撕裂的又一次生动展示。

1. 吃瘪的军迷

“中国阅兵是纪律与协调的教科书级展示，美军根本比不了”（前美国海军教官）
“一个方阵350人！我们练48人都要命，他们怎么做到的？”（美国退伍兵）
“无人机+机器狗+高超音速导弹——这装备像从科幻片里扒出来的！”（美国军迷）

老T重点看了看美国军迷那边的反应，毕竟老牌帝国主义了，天天在外边打仗，军迷规模也算庞大，而且长期以专业性著称。

这次，美国军迷圈最炸锅的，是中国全套反潜黑科技的首次公开亮相。以往被美军视为“终极底牌”的核潜艇，这次成了阅兵式的“头号靶子”：

“深海刺客”无人潜艇：能悄无声息摸到美军潜艇身边放鱼雷，有人哀嚎：“这玩意比好莱坞《猎杀红色十月》还离谱！”
“空中猎手”反潜无人机：撒声呐浮标像天女散花，帖子里热议：“P-8反潜机的活儿被无人机干了，成本还只要零头？”
智能水雷+火箭鱼雷全家桶：尤其智能水雷被戏称“深海地雷阵”，火箭助飞鱼雷更被解读为“专治美军潜艇高速逃逸”。

老T觉得，这届美国军迷还算有点本事，不过也真破防了——“以后弗吉尼亚（核潜艇）要躲无人机、防无人艇、避智能雷，还得防天上扔鱼雷？！”。但也有一些人依然嘴硬：“没实战都是PPT！”。

犹记得一个月前，老T还兴致勃勃的看了好莱坞大片《碟中谍8：最终清算》。电影里边，阿汤哥从黑人女总统手上要来一个航母舰队指挥权，然后从鱼鹰直升机上一跃而下，想肉身进去弗吉尼亚级核潜艇。不过，这核潜艇上的科技装备倒也刷新老T对这种水下巨物的认知。

毕竟，从现实来说，核潜艇也算是美帝的最后依仗了。此前，美军应该老早意识到，在西太平洋这块中国家门口的地方，美军陆上、水上装备算是优势丧尽，不然也不至于每次派个航母舰队过来时，一遇到 055 大驱就夹着尾巴逃。

但美帝可能也一直幻想，虽然水面会挨揍，但他最先进的核潜艇一直安全得很。没想到被这次93阅兵三位一体的潜艇杀手装备集中亮相，打了个措手不及，也难怪五角大楼得连夜加披萨。

2. 中国威胁论

“DF-5C射程覆盖全球，这是对美国的死亡警告！”
“反美联盟形成，第三次世界大战倒计时”（阴谋论者）
“关岛基地？DF-26D早瞄准了！深海堡垒？中国反潜网已铺开！”

这帮人差不多是西方媒体一贯论调，一会中国崩溃，一会中国威胁，左右脑互博，很少有清醒的时候。当看到这次中国展示先进装备时，仿佛听到自己精神防线崩裂的声音。最逗的是有人狂at特朗普：“他肯定在连夜策划更浮夸的阅兵！”（结果特朗普真发了条咆哮体推文骂“中国阴谋”😂）。不过也有清醒的人反驳：“中国40年没打仗，美国同期扔了50万枚炸弹，到底谁才是和平破坏者？”

3. 娱乐至死

“中美阅兵对比：中国像星际舰队，美国像刚蹦完迪的醉汉” “如果中美同时点披萨，中国导弹会比披萨先到你家”
“特朗普想要的生日阅兵，中国给他搞了个顶配版” “以前美国潜艇是深海狼人，现在中国无人机是预言家，无人艇是猎人，智能水雷是女巫——狼人第一晚就出局！”
“五角大楼该给中国打钱——他们帮美军省了军费！”

美帝网民自黑起来也算是狠！自家阅兵被吐槽成“迪士尼花车游行”，还有人毒舌：“英国博物馆该把抢的中国文物还了，不然东风快递包邮上门”。这种解构式幽默背后，其实也藏着对中美实力迭代的微妙认知。就像一句高赞评论：以前中国没钢铁只有钢铁意志，现在中国有钢铁了，该轮到你们练意志了！

的确，美国人看中国阅兵，更像在围观一场陌生人秀，一边惊叹，一边警惕，又忍不住用美式幽默消解焦虑。

当俄罗斯人还在纠结“中俄关系里谁当老大”时，美国人更纠结的是“中国崛起算不算美国衰落”。

但无论哪种声音，都印证了这次阅兵的核心意义：祀以告慰英灵，戎以止战维和。至于美帝核潜艇还能不能睡好觉？不妨学学央视主持人在东风5C亮相时的宣传词：射程覆盖全球，但具体参数嘛……“过于先进，不便展示”😉。

全球围观潮：其他国家网民看法

在看美国网民评论过程中也有个头疼的事，毕竟美帝的平台，很多都是全球各国网友都在用，有时候也很难分清那些发言到底是哪个国家的人。不过也还是很多主动表明身份，以及使用其他语种的发言，大体也能分辨出一些来源，这里也简单汇总下一些典型评价。

总体来看，如果说美俄网民的评论还带着“对手滤镜”和“盟友包袱”，那么其他国家网友的反应则更纯粹。有人当科幻大片看，有人当历史课补，还有人默默掏出小本子记笔记。老T翻了上千条评论，发现这四类评论最有代表性：

1. 发展中国家的集体共鸣

“中国证明了一点：曾被殖民的国家也能逆袭成强国！”（越南@vietnamesebeauties）
“西方媒体总说中国威胁，可中国帮我们修铁路时，欧美只送来账单”（肯尼亚@meja2546）
“看完阅兵我立刻学中文——未来是中国的游戏”（印尼@mohamedaminali6594）
“美国在伊拉克扔炸弹，中国在伊拉克建电站——谁才是真朋友？”（伊朗@haamedkasmaei3999）
“巴西被美国监听十年，中国却给我们发射卫星！”（巴西@leoncioco3305）

正如天安门城楼上“世界人民大团结万岁”，广大第三世界朋友，总体上对这次阅兵都是赞誉和表扬。

不过老T在翻看这些评论时，也感受到很多无奈的情绪，很多人都明显透露着“苦美久矣”的憋屈。

这次93阅兵，对广大第三世界而言，更像是一段爽文剧情：曾经被欺压的穷兄弟，如今带着东风61来撑腰了。

尤其当菲律宾网友 @Axel-t1q9 自嘲“我们挨过日本打却还舔美日”时，一种“恨铁不成钢”感觉，让人五味杂陈。

2. 被日本侵略过的国家集体控诉

“日本至今不认南京大屠杀，却有人批评中国阅兵‘秀肌肉’？”（韩国@문재인-i6p）
“祖父被日军强迫修‘死亡铁路’，中国阅兵也是替我们发声”（泰国@dimsimbogan.）
“欧美只纪念诺曼底登陆，谁记得亚洲死了2000万人？”（越南网友高赞评论）
“奶奶被日军刺刀捅伤时，美军还没参战。中国抗战凭什么被抹杀？”（马来西亚华侨@dangoh2237）

这次阅兵，主题是中国人民纪念抗战胜利。而抗日战争也是能让亚洲众多国家引发共鸣的核心问题。

当西方媒体炒作“中国威胁论时”，韩国网友直接甩图：“看看汉城‘慰安妇’雕像！中国在纪念所有亚洲受害者！”

过程中，老T感觉最扎心的是柬埔寨网友@nuomitang30的质问：“如果中国炫耀武力算威胁，日本隐藏罪行算什么？”

3. 欧洲职业看客

“350人方阵误差小于0.1秒——德国人DNA动了！”（德国@jonaswiegandt3829）
“英国博物馆该归还中国文物了，不然下次阅兵方阵开到伦敦？”（英国@nistelooyv7847）
“阅兵整齐得像AI生成……哦等等这是真的？！”（法国网友暗讽）
“中国花车秀再炫，也改变不了我是自由公民”（阴阳怪气的瑞典网友）

欧洲也是老阴阳人扎堆了，把“双标”玩得明明白白：夸中国纪律性时秒变理工男，提价值观立刻切换圣母模式。

不过也有画风突变的时刻，特别是来自东欧塞尔维亚、保加利亚、匈牙利那边的评论。

有的还特地用翻译软件，将想表达的赞美翻译成中文发出来。本文前边截图中就有一个塞尔维亚的高赞评论。不过，显然人家也不懂简体中文和繁体中文是啥意思，翻译时用的繁体字。

4. 印巴总能出彩

“中巴友谊比喜马拉雅山高！比印度洋深！”（@pakistanime9793 ）
“印度买法国阵风？中国J-10C在巴基斯坦打靶全胜！”（@Maxwell-t3o 这条下边评论都是J-10在阅兵式上只是喷彩条的表演机）
“承认吧！我们阅兵摩托叠罗汉，中国阅兵在组团踢正步”（@DE_EZY ）
“怕中国是真，但上海地铁比新德里干净也是真”（@Aarohanbaru_goku ）

莫迪这次到天津开会，也算是向中国示好了。但很可惜，没有参加阅兵活动。不过中印这关系，讲实在的，一时半会也很难彻底改善。

但印度网友在网上的评论倒是一如既往灌浆糊，有的一边怼“中国武器没实战”转头又问“怎样才能练成这样”。而巴基斯坦地网友，基本都是在评论中狂刷❤️🇨🇳。

值得玩味的是，当评论中涉及到美国时，印巴网友倒是能罕见达成共识：“美国挑拨中印关系，坐收渔利最可恨！”

总结

这次93阅兵，老T总体上感觉是具有极其重大历史意义的标志性事件。在看了各国网友的评价后，也深深感受到国家进步、民族昌盛带来的自豪感。

从1945到2025，中国这80年来真是太不容易了。

城楼上抗战老兵代表与各国领导人们逐一握手那一刻，也让老T不禁泪目。

沧海桑田，如今的中国已经不是1840年之后长达百年里任人宰割的中国。

正如柬埔寨网友 @FFuunnyymudP 写下的那句“中国最震撼的武器，是让阅兵场成为战场终点站。”

80年前我们用血肉筑起长城，80年后我们以强大科技和军事实力拱卫和平。

那响彻云霄的正步声，既是告慰英灵的安魂曲，亦是写给霸权者的止战书。

一次跌宕起伏的BUG修复——PVE节点出现Unknown状态故障

2025-09-02 18:30:00

周日下午，老T准备在 PVE 装个 RouterOS 测试，结果发现无法创建虚拟机。具体表现是，在虚拟机创建页面，节点处提示 “Node epson seems to be offline” ，然后 PVE 面板上，节点显示灰色问号，提示状态为 “Unknown”。由此，开始了老T一段跌宕起伏的 Bug 修复过程。

PVE 存储设备配置冲突

遇到 Bug 后，老T第一时间怀疑是不是节点配置冲突。因为节点内的虚拟机本身在正常运行，除了节点上有灰色问号，在节点中还有两个存储设备也同样显示黑色问号。

这两个存储设备实际就是主机中的两个机械硬盘。此前，老T将这两个机械硬盘挂载后，直通给了 100 号虚拟机使用。

但考虑到虚拟机中无法读取硬盘温度，便分离了存储，改用 PCI-E 硬件直通，将 SATA 控制器直通到虚拟机。故此遗留两个过期的存储设备。

于是老T在 PVE 面板中直接删除了两个存储设备，然后刷新，看到问题依旧。

老T在想，是否是因为集群状态还没更新，于是重启并强制刷新集群状态，同时检查存储挂载情况。

1
2
3



systemctl restart pve-cluster
systemctl restart corosync
pvesm status

果然，存储状态有点问题。PVE 配置中保留了两个 HDD 的 LVM 存储定义，但实际物理磁盘已经直通给 100 号虚拟机不可见。

1
2
3
4
5
6
7
8



root@epson:# pvesm status
Command failed with status code 5.
command '/sbin/vgscan --ignorelockingfailure --mknodes' failed: exit code 5
Name Type Status Total Used Available %
HDD1 lvm inactive 0 0 0 0.00%
HDD2 lvm inactive 0 0 0 0.00%
local dir active 98497780 13880408 79567824 14.09%
local-lvm lvmthin active 832888832 126265946 706622885 15.16%

于是老T 将无效存储配置进行清理，重新修复 PVE 集群状态。

1
2
3
4
5
6



pvesm remove HDD1
pvesm remove HDD2
systemctl restart pve-storage.target
pmxcfs -l # 重建集群配置文件
pvecm updatecerts --force
systemctl restart pve-cluster

顺便再 reboot，想着问题应该解决了。

但重启后发现节点依然显示灰色问号。

集群配置文件错误

如果说，上边检查 PVE 存储配置时发现错误尚且简单，接下来检查 PVE 集群配置时，就开始逐渐入坑了。

1
2

root@epson:~# pvecm status
Error: Corosync config '/etc/pve/corosync.conf' does not exist - is this node part of a cluster? Linux epson 6.8.12-9-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.12-9 (2025-03-16T19:18Z) x86_64

查看集群状态发现，corosync 配置文件丢失，一个稀奇古怪的 Bug。也不知道因何而起。

但在重建前，还有另一个小问题需要重视。

老T使劲查看了一遍 PVE 面板，发现除了节点显示灰色问号，还有另一个问题，就是节点上 CPU 和内存利用率这些基本信息也不显示，包括图表信息也都丢失，图标下方直接显示 1970 年 1 月 1 日。

系统时间

于是，老T开始怀疑是否是系统时间服务故障导致的这一系列问题。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10



root@epson:# timedatectl
Local time: Mon 2025-08--31 21:18:39 CST
Universal time: Mon 2025-08--31 13:18:39 UTC
RTC time: Mon 2025-08--31 13:18:39
Time zone: Asia/Shanghai (CST, +0800)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
root@epson:# hwclock --show
2025-08--31 21:19:03.141107+08:00

不过并未发现故障。系统时间都是正确的。

文件路径问题

没办法，只剩一条路，重建配置文件。

照旧，先检查一下 corosync 状态。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12



root@epson:~# systemctl status corosync
○ corosync.service - Corosync Cluster Engine
 Loaded: loaded (/lib/systemd/system/corosync.service; enabled; preset: enabled)
 Active: inactive (dead)
 Condition: start condition failed at Mon 2025-09-01 21:13:46 CST; 6min ago
 └─ ConditionPathExists=/etc/corosync/corosync.conf was not met
 Docs: man:corosync
 man:corosync.conf
 man:corosync_overview

Aug 31 21:13:46 epson systemd[1]: corosync.service - Corosync Cluster Engine was skipped because of an unmet condition check (ConditionPathExists=/etc/corosync/corosync.conf).
root@epson:~#

不检查不要紧，一检查状态又发现新问题。前边检查集群配置时，系统提示缺少 /etc/pve/corosync.conf ，但 corosync 状态却显示它在查找 /etc/corosync/corosync.conf，两个路径似乎不一致。

于是老T试图修复一下这个问题。结果并没有区别，corosync 依然提示无法查找到配置文件。

1
2
3
4



oot@epson:# mount | grep /etc/pve
/dev/fuse on /etc/pve type fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)
root@epson:# mkdir -p /etc/corosync
root@epson:# ln -s /etc/pve/corosync.conf /etc/corosync/corosync.conf

重建集群配置

终于开始重建配置。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39



root@epson:# systemctl stop pve-cluster pvedaemon pveproxy corosync # 停止服务
root@epson:# rm -rf /etc/pve/* # 删除原配置
root@epson:# rm -rf /var/lib/pve-cluster/* # 删除原配置
root@epson:# mkdir /etc/pve # 重建目录
root@epson:# mkdir /var/lib/pve-cluster # 重建目录
# 写入配置
root@epson:# cat > /etc/pve/corosync.conf <<EOF
totem {
version: 2
cluster_name: epson
transport: knet
crypto_cipher: aes256
crypto_hash: sha256
}
nodelist {
node {
name: epson
nodeid: 1
quorum_votes: 1
ring0_addr: 192.168.1.8
}
}
quorum {
provider: corosync_votequorum
expected_votes: 1
}
logging {
to_syslog: yes
}
EOF

root@epson:# chown root:www-data /etc/pve/corosync.conf
root@epson:# chmod 640 /etc/pve/corosync.conf
root@epson:# rm -f /etc/corosync/corosync.conf # 删除旧链接
root@epson:# ln -s /etc/pve/corosync.conf /etc/corosync/corosync.conf
root@epson:# systemctl daemon-reload
root@epson:# systemctl start corosync
Job for corosync.service failed because the control process exited with error code.
See "systemctl status corosync.service" and "journalctl -xeu corosync.service" for details.

一整套搞下来，过程都挺正常，但结果 corosync 还是崩了。查看日志发现，是缺少认证密钥文件 Could not open /etc/corosync/authkey: No such file or directory。

修复密钥文件

简单修复下密钥文件，并按照错误提示，将其链接到对应路径。

1
2
3
4
5



root@epson:# corosync-keygen
Corosync Cluster Engine Authentication key generator.
Gathering 2048 bits for key from /dev/urandom.
Writing corosync key to /etc/corosync/authkey.
root@epson:# ln -s /etc/pve/authkey /etc/corosync/authkey

重新检查 corosync 状态，发现这次终于没问题了。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13



root@epson:~# systemctl status corosync
● corosync.service - Corosync Cluster Engine
Loaded: loaded (/lib/systemd/system/corosync.service; enabled; preset: enabled)
Active: active (running) since Mon 2025-08-31 21:37:39 CST; 29s ago
Docs: man:corosync
man:corosync.conf
man:corosync_overview
Main PID: 18905 (corosync)
Tasks: 9 (limit: 18833)
Memory: 112.4M
CPU: 204ms
CGroup: /system.slice/corosync.service
└─18905 /usr/sbin/corosync -f

不过，corosync 虽然修复，但是最开始的 epson 节点上灰色问号问题依旧没能解决。也就是说，目前还是没能定位到实际问题所在。

重置配置

接下来开始进入深坑。

在开始重置集群配置前，照例先将 cluster 原本文件删除。结果，哦豁，PVE 彻底崩了。

1
2
3
4
5
6
7



root@epson:# systemctl stop pve-cluster corosync pvedaemon pveproxy
root@epson:# rm -rf /var/lib/pve-cluster/*
root@epson:# pvecm updatecerts -f
ipcc_send_rec[1] failed: Connection refused
ipcc_send_rec[2] failed: Connection refused
ipcc_send_rec[3] failed: Connection refused
Unable to load access control list: Connection refused

好在，此前在上一个环节中，还备份了文件，于是找到备份文件恢复过来。

想着起码不至于全崩吧，回到本次开局状态就行。

结果，问题依旧。查看日志，发现出了个奇奇怪怪的新问题，pmxcfs 无法打开数据库文件 ‘/var/lib/pve-cluster/config.db’。

1
2

[database] crit: splite3_open_v2 failed: 14#010
[main] crit: memdb_open failed - unable to open database '/var/lib/pve-cluster/config.db'

抱着破罐子破摔的想法，要么就彻底来次重配吧。

1
2
3
4
5
6



rm -rf /var/lib/pve-cluster/*
rm -f /etc/corosync/corosync.conf
rm -f /etc/pve/corosync.conf
rm -f /var/lib/corosync/*

apt-get install --reinstall --purge pve-cluster corosync

于是，老T将 cluster 和 corosync 干脆一并删了，重新来过。

但，依旧失败。PVE 面板此时已经没法恢复。由于虚拟机还在运行，老T也没继续折腾。等第二天再弄。

二次修复集群配置

第二天早上，老T 早早的就起来，想着趁上班前早点修复这个。

不得不说，睡了一晚，人也清醒多了。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17



# 检查备份现有文件
ls -la /var/lib/pve-cluster/
cp /var/lib/pve-cluster/config.db /root/config.db.bak.$(date +%Y%m%d)

# 停止进程
systemctl stop corosync pve-cluster pvedaemon pveproxy
pkill -9 pmxcfs

# 修复数据库
sqlite3 /var/lib/pve-cluster/config.db ".dump" > /root/dump.sql
sqlite3 /var/lib/pve-cluster/new_config.db < /root/dump.sql
mv /var/lib/pve-cluster/new_config.db /var/lib/pve-cluster/config.db
chown www-data:www-data /var/lib/pve-cluster/config.db
chmod 0600 /var/lib/pve-cluster/config.db

## 重启集群服务
systemctl start pve-cluster

不过，重启依然失败。查看日志，发现是 pmxcfs 无法挂载文件系统到 /etc/pve 。也是个稀奇古怪问题。

仔细检查 /etc/pve 路径发现，原来此前用的 rm -rf /etc/pve/* 命令，只是删除了目录中部分文件，对于以点（.）开头的隐藏文件并没有删除掉，导致目录实际不为空。

又重新来一遍，将 /etc/pve 目录移除，重新创建空目录。

然后将原来的两个虚拟机配置重新写入 /etc/pve/qemu-server/100.conf /etc/pve/qemu-server/101.conf。

总算是回到了起点。

即，PVE 中节点 epson 上显示灰色问号。折腾两趟，毫无起色。

远程把 PVE 干丢了

老T把这段过程，找 DeepSeek 复盘，看看中间到底哪里出了差错。结果它立马提醒，在恢复集群配置后，该立马更新网络配置。

也就是信了它的鬼，老T按照它提供方法，创建了网络配置，直接把远程 PVE 干离线了。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21



# 创建临时网络配置
cat << EOF > /etc/network/interfaces.tmp
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
 address 192.168.1.238/24
 gateway 192.168.1.1
 bridge-ports eno1
 bridge-stp off
 bridge-fd 0
EOF

# 应用配置
mv /etc/network/interfaces.tmp /etc/network/interfaces
chmod 644 /etc/network/interfaces
systemctl restart networking

拯救 PVE 网络问题

一波未平一波又起，被 deepseek 这样一搞，心态又崩了。只能找 Gemini 来挽救下。

排查发现，PVE 网络本身并没啥太大问题，能够正常联网。

只是因为此前在写入两个虚拟机配置时，错写了磁盘空间格式，应该写成 64G 被老T写成 64 GiB，导致 PVE 无法解析磁盘。因而在网络配置重启后，无法连接到虚拟机。

但也就是在排查这个网络问题过程中，让老T看到一个新的问题。

在运行状态中显示，这个节点的名称叫 2606:4700:3037::6815:3752 ，而在corosync 配置中，这个节点名称叫 epson 。

按道理，当 corosync 服务启动时，它会读取配置文件中的 name: epson。然后，它需要将 epson 这个名字解析成一个 IP 地址，以便在网络上进行通信。如果在这个解析过程中失败了，corosync 可能会“自暴自弃”，直接使用IP地址作为自己的名字。

经详细检查发现，是因为老T之前曾修改过 PVE 的主机名，正常情况下，节点应该解析到 192.168.1.238，但添加了自定义域后，节点被解析到 Cloudflare 的 IP 。将 Hosts 顺序调整后，算是修复了这个 Bug。

1
2
3



root@epson:~# getent hosts epson
2606:4700:3037::6815:3752 epson.fosu.cc
2606:4700:3031::ac43:91f8 epson.fosu.cc

结局

我重新看了下 PVE 面板各项功能，在将硬件状态监控面板时长从“天”调整到“月”后，终于是发现大问题。

原来，这个PVE节点故障，已经存在 10 来天了。按照 8 月 21 日的时间节点，有可能是因为当时安装 PVEtools 的缘故。

由于当时为了解决飞牛系统中硬盘显示温度问题，过程中曾一度安装过 PVEtools 更改面板设置，添加了温度监控。

在想起这茬事后，立即开始验证。

1
2
3
4



root@epson:~# dpkg --verify pve-manager # 验证文件改动情况
missing c /etc/apt/sources.list.d/pve-enterprise.list
??5?????? /usr/share/perl5/PVE/API2/Nodes.pm
??5?????? /usr/share/pve-manager/js/pvemanagerlib.js

毫无疑问，因为 PVEtools 的安装，导致 PVE 管理器后端 API 和核心 JS 库都被改动过。即便我印象中，安装 PVEtools 中相关组件后曾进行卸载，也不起作用。

于是重新安装 PVEmanager。这次终于是把 PVEtools 残留在面板上的温度显示给去掉了。

1
2

apt-get update
apt-get install --reinstall pve-manager

接着继续排查，PVETools 安装后可能给 PVE 带来的负面影响。

经查看 PVE 各种组件状态，在排查到 PVE 状态守护组件时，发现它一直在疯狂报错。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15



root@epson:~# systemctl status pvestatd # 验证PVE状态守护情况
● pvestatd.service - PVE Status Daemon
Loaded: loaded (/lib/systemd/system/pvestatd.service; enabled; preset: enabled)
Active: active (running) since Tue 2025-09-01 19:07:31 CST; 5min ago
Process: 1081 ExecStart=/usr/bin/pvestatd start (code=exited, status=0/SUCCESS)
Main PID: 1116 (pvestatd)
Tasks: 1 (limit: 18833)
Memory: 156.2M
CPU: 2.704s
CGroup: /system.slice/pvestatd.service
└─1116 pvestatd

Sep 01 18:11:50 epson pvestatd[1116]: node status update error: Undefined subroutine &PVE::Network::ip_link_details called at /usr/share/perl5/PVE/Ser>
Sep 01 18:12:00 epson pvestatd[1116]: node status update error: Undefined subroutine &PVE::Network::ip_link_details called at /usr/share/perl5/PVE/Ser>
Sep 01 18:12:10 epson pvestatd[1116]: node status update error: Undefined subroutine &PVE::Network::ip_link_details

最后，老T通过对 PVE 进行一次完整的组件升级，解决问题。

1

apt update && apt full-upgrade

问题回顾与总结

初始症状
- PVE 节点状态显示 unknown（灰色问号），无法创建虚拟机，节点性能图表丢失（显示 1970 年 1 月 1 日）。
弯路 1：误判存储配置冲突
- 怀疑直通硬盘遗留的无效存储配置（HDD1/HDD2）导致问题，清理后重启但问题未解决。
弯路 2：错误重建集群配置
- 发现 corosync.conf 丢失并尝试重建集群（包括修复路径、密钥文件），但节点状态异常依旧。
弯路 3：被误导修改网络配置
- 依据错误建议重写网络配置，导致 PVE 失联，后修复 hosts 解析（节点名误解析到 Cloudflare IP）但核心故障仍在。
初步怀疑
- 结合时间线（故障始于 8 月 21 日）和操作历史，怀疑 pvetools 脚本（曾用于添加温度监控）是根源。
关键证据 1
- dpkg --verify pve-manager 确认核心文件（Nodes.pm, pvemanagerlib.js）被 pvetools 修改。
第一次尝试
- 重装 pve-manager：恢复了被修改文件（温度监控消失），但节点状态异常仍未修复，表明问题更深层。
决定性证据 2
- 检查 pvestatd 日志发现致命错误：Undefined subroutine &PVE::Network::ip_link_details，明确指向库版本不匹配。
根本原因
- PVE 组件版本冲突：新版本 pve-manager 调用了旧版 Perl 库（如 libpve-common-perl）中不存在的函数。
最终解决方案
- 执行完整系统升级：apt update && apt full-upgrade，同步所有 PVE 组件至兼容版本，彻底解决问题。

8月说说: Folo RSS迁移医保药价断机油滤芯飞牛不显示硬盘温度

2025-08-30 20:30:00

这是老 T 在 8 月份的说说内容，这里将其一并提取发布，主要包括 Folo RSS 更换域名后的一些问题，医保用药问题，汽车滤芯损毁问题，以及在使用飞牛和群晖过程中遇到的一些问题等。

Github issue 作为博客说说发布页面的模板设置问题

在设置模板过程中，需要留意以下几个问题：

页面构建缓存。可能导致页面内容可能无法更新。

1
2
3
4
5
6



 {{ $url := "https://api.github.com/repos/user/moments/issues/1/comments" }}
 {{ $opts := dict
 "headers" (dict "User-Agent" "Hugo Static Site Generator")
 "cache" 300
 "cacheKey" (printf "gh-comments-%s" (now.Format "2006-01-02-15:04"))
 }}

内容排序。 github issue api 输出数据是最新的内容在后边，需要倒过来。

1
2
3
4



 {{ with resources.GetRemote $url $opts }}
 {{ if and .Content (ne .Content "") }}
 {{ $comments := .Content | transform.Unmarshal (dict "format" "json") }}
 {{ $sortedComments := sort $comments "created_at" "desc" }}

时间格式。github issue 默认使用 UTC 时间，中国的话，需要在基准上加8个小时。

1
2
3



<time>
 {{ (.created_at | time.AsTime).Add 28800e9 | time.Format "2006-01-02 15:04" }}
</time>

Folo 使用过程中的几个问题

最近在使用 Folo (follow) 过程中发现几个问题：

RSSHub 源失效问题

在我的中文博客列表中已有 28 个 RSS 源失效，占比 20% 左右，但这些都是个人站点，倒也正常。有时候换个域名或者换个程序原来的 RSS 链接就没法跟踪了。但 RSSHub 这边，像知乎这种大平台的 RSS 源失效，真是不能忍。输出结果都是 403，应该是知乎那边把 RSSHub 屏蔽了。

Error Message:

FetchError: [GET] "https://www.zhihu.com/people/rpwi/": 403 Forbidden

Route: /zhihu/posts/:usertype/:id

Full Route: /zhihu/posts/people/rpwi

RSS 源的图标缓存问题

我博客的 RSS 源是去年下半年添加的，当时正在更换域名，临时找了个 favicon 顶着，没过几天便换了新的、正式的 favicon。但没想到，Folo 现在依然使用的首次添加时的 favicon。

Folo 使用了 webp.se 的图片缓存服务，它在获取网站图标后，自动添加了一个回退源参数 ?fallback=true ，我看 webp.se 文档介绍，他们是每天更新一次缓存，但 Folo 这边似乎是定死了缓存图标，没找到哪里可以刷新，我试着在链接上使用常见参数来刷新，但都无效。事实上 webp.se 获取我博客图标毫无问题。

Folo 图标地址： https://unavatar.webp.se/lawtee.com?fallback=true

正常图标地址： https://unavatar.webp.se/lawtee.com

该问题经过一阵折腾，后来算是解决了。但我也不知道到底是哪个操作导致刷新成功的。

RSS 源迁移问题

我在去年将博客域名从 hyruo.com 更换到 lawtee.com 后，将原来的 RSS 链接作了 301 重定向。

https://hyruo.com/index.xml --> https://lawtee.com/index.xml

我看 Folo 是可以识别到这种迁移的。

但问题是，每次重置 RSS 源后，隔上几分钟，总会失效。链接地址又会从 lawtee.com 变回去 hyruo.com。

Folo RSS 页面地址：法律小茶馆

之所以存在这种问题，主要是因为 Folo 会自动在 RSS URL 后方加入机器校验。在迁移时，会自动为新的 RSS 源设置迁移标识，只有当访问 https://hyruo.com/index.xml#migrate-102195283873064960 这种链接能够正确进入到新的 RSS 源时才能成功。（不过folo那边始终有问题，经常在两个url中反复横跳，我也不确定是不是真的就能永久成功）

更换小米 14 手机

前两天，老婆跟我说她手机突然开始变卡了，微信动不动就没法下载图片，无法打开 Office 文件，无法打开别人发的视频，自己发图片出去也经常失败，打开微信视频号中的视频也无法观看，关机重启好一阵但没过多久又这样。我帮他清理了手机存储，清理了微信缓存，但总是没过多久又会出现故障。

我知道这个原因主要出在她微信上存储的东西太多，目前手机上两个微信已经占了500GB存储容量，但她什么东西都舍不得删，上万好友加上千个微信群，也是难为手机了。

她目前用的是 Vivo X100 Pro 1TB 的手机，鉴于她不肯删微信记录，重置手机又耗时耗力，我只好重新帮她买了个小米 14，由于是老款，价格也还不错，2700 多块钱 1TB 版本，应该足够她继续用一年微信不卡了吧。后续再出问题，只能麻烦点，再倒腾回 Vivo 了。

VIVO 手机APP迁移乌龙

昨晚在将 vivo X80 迁移到 vivo X100 Pro 时闹了个乌龙。第一次迁移时，手机设置和自带应用那些都成功迁移了，微信 QQ 也都正常迁移，但是大量手机应用程序 APP 却未成功。

此前，在将 vivo X100 迁移到小米 14 时，并没有发现这种问题。于是在想，是不是因为我大量的应用都是使用谷歌Play安装所导致。此前，vivo X100上所有的应用都是使用vivo自带应用商店安装的。

然后我下载了一款第三方迁移手机应用的软件，折腾了大半个小时，发现这个迁移也没办法做到把应用的数据部分同步迁移过去，只能迁移应用本身。

这可把我急坏了，因为我手机上 100 多款应用大多，很多都是从谷歌 play 或者 github 上面下载的，不少应用都没有账号同步功能，如果都要从头再来，这可是个巨大的工程。

我又使劲研究了一下这个 vivo 一键换机功能，最后发现是我在以前为了防止各种 app 胡乱读取我的 applist，将一键换机的应用也给限制读取 applist 权限。但很可惜，在使用一键换机过程中，vivo 并未提示应用权限缺失，而此前我在小米 14 上，印象中换机时该应用逐个提醒我打开了各种权限功能。

在找到问题后，我重新启动了一键换机，发现全部 APP 及数据都能正常迁移。包括 google play 本身都可以迁移，暂未发现任何使用问题。

医保用药是不是坑

医保集采后，我一直以为医院的药都很便宜。此前，我妈因慢病每两三个月都去医院开药，都是一二十块钱。但今天去医院复查时，我仔细看了下医生开的几个药，发现每个价格都不便宜。

首当其冲那就是那个高锰酸钾片，我此前在京东买了一盒，5块钱。

但医院这个，相同份量，居然要60块。我又在京东查了下同款高锰酸钾外用片，确实也卖60块。

然后我仔细看了下区别，京东买的这个5块钱高猛酸钾片，只有企业标准，连个“消字号”都没有，而医院同款的是 OTC 。

我进一步搜索发现，目前国内就两款 OTC 的高猛酸钾外用药。一个是上边图上的济南康福生“TXTY”牌，另一个是山东明仁福瑞达制药股份有限公司生产的。不过，目前在售的只找到"TXTY"牌的，而福瑞达这个，全网连个药盒子照片都找不到。

也就是说，目前这个"TXTY"牌的高锰酸钾外用片，几乎是个垄断药了。难怪卖的这么贵。

知乎回答首破8000赞

前几天在知乎看到甘肃庆阳市宁县一家长发视频质疑校服问题被拘留事件有关话题，看了几百个回答，感觉都是草草输出情绪为主，便试着写了个回答，花了一个晚上时间。结果第二天起来，发现收获了 5000 点赞。截至目前，已经超过 8000 赞和 2000 收藏。也算是在情绪价值上收获了回报吧。

老早就知晓，这种封闭平台的流量，是显著高过个人博客的，但定位不同，也不好比较。事实上，我早就把知乎上2019年之前的回答全部删除，主要也是公开平台确实更多输出的是一刹那的情绪，而博客这边反倒心态平和很多。

群晖中报废 SSD 一块

之前从群晖中移除两块硬盘格式化后放到了Epson ST190E主机里边用作飞牛NAS存储。

看到群晖硬盘仓空荡荡的，就从老电脑拆了块SATA口的SSD进去，想着也试试群晖+固态，看能不能提点速。

结果，在系统中没发现有 SSD 缓存功能，一查群晖网站，发现我这款NAS不支持 SSD 缓存。

既然不能当缓存，那当个软件盘总可以吧。于是把盘格式化成basic模式进去，安装了几个常用软件在上边。

直到8月12日那天，我打开群晖面板，才发现这块没放进去多久的硬盘已经彻底崩了。

从8月8日晚上，到8月12日，NAS无数次试图通过SMTP发邮件告诉我这回事，但因为SMTP配置已经过期，我显然没有到邮件通知。错过了最佳抢救期。事实上，8月8日错误次数还比较少，到8月11日，我看它一天内弹了600多次严重警告，估计就是系统在跟硬盘疯狂搏杀了，到8月12日，系统已经完全无法读到硬盘，此时硬盘也彻底报废了。

SMTP过期这种事情，确实很麻烦，群晖这个SMTP我起码设置有四五年了，估计是因为中途改过邮箱密码所导致，平常也想不起来这么多事情。例如，刚才我查看QQ邮箱的SMTP设置，发现有几个授权码莫名其妙，也不知道自己啥时候设置的，IP有的在美国，有的在马来西亚，还都在近期发过信，但我丝毫没印象。

飞牛相册 AI 识图调度策略差异

飞牛的AI相册调度策略有点看不懂。

我上周第一次用 AI 相册识别时，人脸识别和智能分类识别，都是用的GPU在干活。由于两个进程都在调度GPU，导致GPU运转过程中 Render 使用率都是峰谷交错，每隔几秒满载一下，导致 CPU 风扇也是跟着不断循环往复从 20% 转速到 100% 转速反复横跳，CPU 核心则处于闲置状态。

由于上周识别效果差，特别是我家四个人的人像都识别失败，抱着不死心的态度，我又重新测试一遍。但这次 AI 相册识别时调度策略明显不一样了。这周是人脸识别的进程在调动 CPU 运算，而图像智能分类识别，是调动 GPU 在运算，好处是 CPU 和 GPU 基本都是同步持续稳定输出，CPU 占有率 3 核 40% 左右，GPU 这边整理利用率 25% 左右，其中 Render 部分稳定在 95% 以上。

这个调度策略我还是相对满意的。CPU 和 GPU 同时预算，两者识别速度都差不多。此前，只用 GPU 时，人脸识别大概比智能分类识别快 2 倍。现在两者半斤八两，速度只差个一半左右。但还是带来另一个问题：散热。目前 CPU 基本就在温度墙附近游离，维持在 80 度上下。

机油滤芯断在发动机里边

昨天下午开车去京东养车做保养，遇到个稀奇古怪的事情。

小伙子在帮我换机油的过程中，发现机油滤清器整个散架断在里边。

他反反复复把车升降，从发动机舱上方和底盘下方伸手去掏，但有一截始终掏不出来。

由于我这个车的发动机设计太过于奇葩，机油滤清器所在的位置太过狭窄，无论是从上面还是从下面去掏，手指都很难发力。花了大半个小时，把他心态都给搞崩了。

我在抖音查询这种情况，并没有找到类似的案例。最后根据原本的滤清器结构，建议他用一根铁丝去勾。经过几次尝试才终于把这玩意弄出来。

搞出来之后，小伙子跟我说这次保养得加钱。

好在我立马反应过来，说上一次保养也是在这家店做的，并打开京东app给他看了上一次保养记录。言外之意，之前这个滤芯也是在京东养车买的，坏了也得京东养车负责，并且这滤芯坏在里边，搞不好就是上一次保养的安装问题，没理由让我承担责任。

小伙也机灵，见我拿出上次保养记录，也没说啥，加钱一说便作罢。

解决 PVE 安装飞牛后，飞牛系统中不显示硬盘使用时长、温度等信息问题

之前我一直没留意飞牛中两块机械硬盘 SMART 信息，今天看下才发现，居然没法检测。此前，飞牛上一直显示这两块盘使用时长 1H 温度 31℃ ，当是 Bug了。

今天在 AI 提示下，说我原来设置硬盘直通，用的 SATA 模式有问题，得改成 SCSI 模式。

1
2

qm set 100 -sata1 /dev/disk/by-id/ata-ST2000LM015-2E8174_WDZBN66Q #AI提示把sata改成scsi就行
qm set 100 -sata2 /dev/disk/by-id/ata-ST2000LM015-2E8174_WDZBN776

结果，这一改，飞牛里边存储空间全乱套了，无法修复重建，只能格式化从头再来。同时，硬盘温度那边压根就不显示了，连 1H 31℃ 都没有。

后来，我在想，之前在设置 GPU 直通时也是信了 AI 的鬼，用的命令设置，结果一直没搞通，是直接在 PVE 中添加 PCI 设备成功的，是不是这次也可以试一下，结果这一试，两个问题都一并解决。

在虚拟机添加 SATA 控制器后，原来飞牛中的存储空间恢复正常，之前的数据也没丢，硬盘 SMART 信息也能够准确读取了，压根不用添加硬盘。

Lawtee | 法律小茶馆修改