2026-10-05 · 建站运维

今天把「三个通道」的全套素材做齐了，一并放上来。三个通道的关系很简单：提问 → 作答 → 公开——现实里的迷惑问题，因为长期只看同一类说法，认知会慢慢失真、偏差；很多人有觉察，却无处找到答案。

三个通道

• 高校学生研究通道：把令人迷惑的问题做成公开课题，结论附证据、局限与反方观点，修改留痕 → 1dao.cc/research/
• 视频号读书卡提问通道：只管提问，仅限自然科学各学科；微信小店购买
• 讲者视频制作团队合作通道：招募能把问题讲清楚的人与视频制作团队，一起作答、一起成片

内容范围与流程

• 范围：仅限自然科学各学科（数学、物理、化学、天文与地球科学、生物、计算机等）
• 不涉及：政治敏感、婚姻情感、历史人物等内容——不纳入课题，也不作答
• 流程：先在知乎提问；若仍有疑问，再来提交给我们

三个链接封面（对应三个通道）

A · 高校学生研究通道（2.35:1 公众号首图，另有 1:1 小图）

B · 视频号读书卡提问通道

C · 讲者视频制作团队合作通道

视频号素材

视频号封面 6:7；另有 3:4、片头卡、片尾关注卡、二维码结束卡、字幕条、右下角标，以及 60 秒分镜脚本（v3）

小店素材（视频号读书卡）

商品主图 5 张（800×800）+ 详情长图（含「范围与流程」段）+ 店铺 logo

PPT（三通道总纲，14 页）

可编辑 .pptx + PDF + 逐页 PNG（1x/2x）

商品页：点击购买弹微信二维码下单

因为微信小店的「会员卡券」类目是定向准入（企业主体 + 商标 + 网络文化经营许可证/增值电信业务经营许可证 + 软著 + App 下载量门槛），基本走不通，所以先做了一个自建静态商品页顶着：

→ https://1dao.cc/card/（点击「立即购买」弹微信二维码加好友下单）

页面已注明：微信商店正在紧锣密鼓筹备中，此页面仅用作权宜，请加微信下单。

微信小店素材标准（写作时查的官方规则）

• 商品主图：1:1，单张 ≤10MB，≥3 张，第一张必须是商品主体完整正面实物图，不可重复、不可 gif
• 商品视频：≤180 秒、≤500MB；商品标题：≥5 个汉字（手机端 5–60 字）
• 商品详情：必须有图片；严禁出现二维码、网址、电话、其他账号等联系方式，以及第三方平台信息
• 资质材料需为图片、加盖公章、清晰无涂改

完整规则与官方链接见附件《微信小店-素材标准.md》。

下载

见文末附件（图片素材包 / PPT / 商品页源码 / 规则与脚本 / 公众号文章）。素材为本栏目自制，可自由用于本栏目传播；二维码与入口地址以本文与 1dao.cc/research/ 为准。

研究通道宣传素材（更新版 · 2026-10-05）

文章 《高校学生研究通道上线…（附全套宣传素材）》 里那套素材（朋友圈主海报 / 方形版 / 长图 / 公众号头图 / 分享卡 / 观点方图 / 二维码卡 / 通道标志 + 文案包）已按新口径全部重做：删去「算法 / 千人千面」的说法，改为「信息茧房 → 认知失真、偏差；有觉察，却无处找到答案」；长图新增「范围与流程」一节（仅自然科学各学科 / 不涉及政治敏感·婚姻情感·历史人物 / 先在知乎提问，仍有疑问再来）；文案包三版同步更新。

1 倍图内嵌于此；点图或到文末附件下载 2 倍高清与文案包。文章 63 中展示的同一批图也已同步为更新版。

视频号成片 · 60 秒（可直接发布）

按分镜脚本 v3 合成的竖版短片：片头 → 「有觉察，却无处找到答案」→ 「长期只看同一类说法，认知会慢慢失真、偏差」→ 三个通道 → 范围与流程 → 二维码收尾。无人声、无实拍，纯素材 + 字幕；右下角常驻品牌角标。

1080×1920 · 30fps · H.264 + AAC · 60.0 秒 · 1.22MB（可在文末附件下载原片）

📎 附件下载 · 共 8 个文件

🔗 相关入口

• 高校学生研究通道：https://1dao.cc/research/
• 通道说明与参与规则：https://1dao.cc/research/about/
• 视频号读书卡（权宜下单页）：https://1dao.cc/card/
• 主站：https://1dao.cc/ ｜ 博客：https://blog.1dao.cc/

2026-10-05 · 建站运维

（2026-10-05 更新：本套素材与文案已按新口径重做——见 文章 64 全套素材汇总；文内配图与文案均已同步更新。）

现实里，总有些令人迷惑的问题：同一件事，说法各不相同。长期只看同一类说法，认知会慢慢失真、偏差——更麻烦的是，很多人有觉察，却无处找到答案。今天 1dao.cc 上线了一个新栏目——高校学生研究通道：把现实中令人迷惑的问题整理成公开课题，交由高校学生参与研究；结论必须带证据、写明局限、挂出反方观点，并保留修订记录。

它只做一件事：把问题摊开，把证据摆出来，把结论和它的边界一起写清楚。页面是纯静态的：同一条链接，任何人打开看到的都是同一份内容。
范围与流程：只做自然科学各学科；不涉及政治敏感、婚姻情感、历史人物；先在知乎提问，仍有疑问再来提交。

入口：https://1dao.cc/research/

求真 · 四条硬规则

1. 问题可证伪：课题以问句给出，必须能被证据支持或推翻，不接受立场口号。
2. 证据可点验：每条证据都附原始来源链接，可点击回源；二手转述必须标注。
3. 反方公开：不同结论、存疑与反驳一并公开，不隐藏、不删除。
4. 修订留痕：结论每次修改都进入「修订历史」，写明日期、改动内容与依据。

学生如何参与

1. 选题：挑感兴趣的课题，或自荐让你困惑、且可以查证的问题；
2. 报名：按提交模板写研究方案，3 个工作日内答复是否受理；
3. 研究：收集材料、查证来源，过程中可随时来信沟通；
4. 提交：提交结论、证据（附来源）、局限与你认为尚存疑的地方；
5. 复核发布：复核通过后公开发布，署名与否自选，默认匿名。

提交模板与研究规则：研究通道 · 说明 ｜ 提交邮箱 huaqidao@qq.com

📣 宣传素材展示 · 8 张

以下为本次上线的全套宣传素材，可直接用于微信朋友圈、公众号、社群与线下渠道。点击任意图片可查看并下载高清原图（均为 2 倍分辨率）。

📎 附件下载 · 共 9 个文件

📌 提示：图片均为 2 倍分辨率（实际像素见括号内），微信/公众号直接上传即可；二维码统一指向 https://1dao.cc/research/，已实机解码校验。

✍️ 朋友圈文案 · 3 条（任选）

🔗 相关入口

• 研究通道：https://1dao.cc/research/
• 通道说明与参与规则：https://1dao.cc/research/about/
• 提交模板下载：https://1dao.cc/research/submission.md
• 主站：https://1dao.cc/ ｜ 博客：https://blog.1dao.cc/

* 本栏目文案与海报素材均为自制，可自由用于本栏目传播；二维码与入口地址以本文为准。

2026-09-08 · 建站运维

这两天做了两件事:把博客的备份与记忆同步链路完整捋了一遍;给博客程序(emlog)做了一次授权机制的代码审查。前者牵扯出两个日常工具——sha256 与 GPG;后者回答了一个悬了很久的问题:没注册正版,程序到底会不会「搞事情」。三件事都值得展开说说,合在一起写一篇长的。

先讲一个场景

假设你从网上下载了一个几百 MB 的系统镜像,吭哧吭哧下载完,准备写入 U 盘安装。这时候你最担心什么?一是文件在传输过程中损坏了——网络抖动、服务器出错、磁盘坏道,都可能让某个字节悄悄改变;二是文件被掉包了——下载源被劫持,你以为的官方镜像其实是别人放上去的篡改版。前者是「完整性」问题,后者是「真实性」问题。

再假设你把一包重要的数据传到某个云盘或者代码托管平台。你最担心什么?平台账号被盗、误操作把私有仓库设成公开、平台内部人员越权、平台服务器被拖库——任何一环出问题,你的数据就可能裸奔到别人手里。这是「机密性」问题。

这两个场景,几乎概括了数字世界数据安全的所有焦虑:数据在传输和存储过程中,怎么保证「没被改」?怎么保证「别人看不懂」?如果还想更进一步,怎么证明「确实是我发的」?

sha256 和 GPG,就是回答这些问题的两件趁手工具。一个负责给数据按指纹,证明它没被调包;一个负责给数据装信封,保证只有持有钥匙的人能拆开。本站的备份体系把这两件工具组合起来用了大半年,期间还真的经历过一次「信封」立功的时刻——这些下文都会讲到。

sha256:数据的指纹

什么是哈希

哈希(hash)函数,是把任意长度的输入,计算出一个固定长度输出的函数。它有几个关键性质:

• 确定性:同样的输入,永远得到同样的输出;
• 单向性:从输出几乎不可能反推输入;
• 雪崩效应:输入哪怕只改一个比特,输出也会面目全非;
• 抗碰撞:理论上很难找到两个不同的输入,得到相同的输出。

SHA-256 是 SHA-2 家族里应用最广的一个,输出 256 位,写成十六进制是 64 个字符,像一串指纹:

$ echo -n "hello" | sha256sum
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

把输入从 hello 改成 hallo,输出立刻变成完全不同的一串:

$ echo -n "hallo" | sha256sum
b27c70fa5eb85340b7c8e03f00c7b0226bf0a1df0aab44da5abcf2f6a8a18df8

两个输出之间看不出任何关联。这正是哈希函数被称为「指纹」的原因:内容可以很长,指纹永远 64 个字符;内容稍有变动,指纹立刻对不上。

哈希家族的来龙去脉

哈希算法不是一天建成的,了解一点历史有助于理解为什么现在是 SHA-256 当家。

上世纪 90 年代初,MD5 由罗纳德·李维斯特设计,输出 128 位,一度是校验和的代名词,至今很多下载站还在用它。但 2004 年,中国密码学家王小云团队宣布找到了 MD5 的碰撞——也就是说,可以构造两个内容不同、但 MD5 完全一样的文件。这在密码学界投下重磅炸弹,MD5 从此被宣告死亡,只适合做非安全场景的快速校验。

同一时期,美国国家标准与技术研究院(NIST)在 1993 年发布了 SHA-0,次年修正为 SHA-1,输出 160 位。SHA-1 在很长一段时间里是 SSL 证书和 Git 的默认算法。但它的命运与 MD5 类似:2017 年,Google 和荷兰 CWI 研究所宣布了全球首例 SHA-1 碰撞(代号 SHAttered),构造出两个内容不同但 SHA-1 相同的 PDF 文件。从那以后,SHA-1 也被主流安全体系全面淘汰,浏览器不再信任 SHA-1 证书。

SHA-2 家族(2001 年发布)至今安然无恙,SHA-256 正是其中使用最广的一员。256 位的输出空间是 2 的 256 次方,这个数字有多大?宇宙中可见原子的总数大约是 10 的 80 次方,而 2 的 256 次方大约是 10 的 77 次方——也就是说,即便把全宇宙的原子都拿来做并行计算,想靠穷举找到一次碰撞,概率也低到可以忽略。这就是「抗碰撞」的底气来源。

2015 年,NIST 又标准化了 SHA-3(基于 Keccak 算法,采用与 SHA-2 完全不同的海绵结构),作为 SHA-2 的备胎。SHA-2 至今没有实质性的攻击,所以 SHA-3 更多是「战略储备」,日常使用中 SHA-256 依然是绝对主流。

哈希用在哪些地方

哈希大概是计算机世界里应用最广泛的密码学原语,随处可见:

• 下载校验:几乎所有的 Linux 发行版、软件镜像站都会在下载页给出 SHA256SUMS 文件,下载完执行 sha256sum -c SHA256SUMS,一行命令批量核对所有文件,传输损坏、下载不完整立刻现形;
• Git 版本管理:Git 的每一次提交,其对象 ID 就是内容哈希。Git 历史上长期使用 SHA-1,如今新仓库已经可以选用 SHA-256,以彻底摆脱 SHA-1 的阴影。哈希让 Git 天然具备防篡改能力:任何历史提交被改动,后续所有提交的哈希都会对不上;
• 区块链:比特币的工作量证明就是对区块头做双重 SHA-256 计算,挖矿本质上是在暴力搜索一个满足难度条件的哈希;
• 内容寻址:IPFS 这类分布式文件系统直接用哈希当文件名,内容一样,地址就一样,天然去重;
• 密码存储:网站数据库里不应该存明文密码,而应该存密码的哈希。不过要注意,单纯 SHA-256 并不适合存密码——它太快了,攻击者可以每秒尝试几十亿次,配合彩虹表(预先算好的「密码→哈希」对照表)更是可以秒破弱密码。专业的做法是用 bcrypt、scrypt、argon2 这类刻意「慢」的算法,并且每个用户加不同的随机盐。记住一个原则:SHA 适合校验文件,不适合存密码;
• 消息认证:哈希结合密钥可以构造 HMAC(基于哈希的消息认证码),用来验证消息在传输中既没被改、发送方也确实持有密钥。为什么不能直接用哈希?因为哈希是公开的,任何人拿到文件都能重算,改完文件再重算一遍哈希就能骗过校验——哈希只防「意外损坏」,不防「故意篡改」。要防故意篡改,需要密钥参与的 HMAC,或者直接用 GPG 签名(下文会讲)。

命令行实操:三句口诀

日常使用 sha256,记住三句口诀就够:

• 算一个文件的指纹:sha256sum 文件名,输出「哈希值 + 文件名」;
• 批量校验:下载官方发布的 SHA256SUMS 文件后,sha256sum -c SHA256SUMS,程序会自动比对每个文件并报告 OK 或 FAILED;
• 生成自己的校验清单:sha256sum 文件1 文件2 > SHA256SUMS,发布文件时连同清单一起给出去。

实操中还有两个容易忽略的细节:一是哈希字符串必须完整比对,粘贴时少一位都查不出来,严谨的做法是直接复制而不是手敲;二是哈希本身要通过可信渠道获取——官方下载页给的哈希,要配合 HTTPS 和(更理想的)发布者签名一起信任,否则攻击者改完文件顺手把页面上的哈希也改了,校验就失去了意义。这也是为什么「哈希 + 签名」常常成对出现。

本站怎么用 sha256

在 1dao 的备份体系里,sha256 承担的是「完整性把关人」的角色。

服务器每天凌晨由 backup-server.sh 把数据库、系统配置、凭据、站点数据等打成若干数据包;备份同步脚本在推送 Gitee 前后,都会对包做哈希记录。恢复演练时,restore 脚本先对拿到的包重算哈希、与记录比对,一致才继续往下走——确保从仓库拉回来的备份,和当初推上去的备份分毫不差。

最有意思的一次应用,是前几天把服务器助手的工作记忆导入本地助手。服务器助手从 8 月 9 日「出生」到 8 月 18 日的工作笔记,随备份体系一起打包加密,躺在 Gitee 私有仓里。本地助手导入时,流程是:先验 sha256,再 GPG 解密,然后才并入自己的记忆库。哈希在这里是信任的起点——先确认这份快照在仓库里躺了这么多天没有被任何人动过手脚,才敢把它当作自己记忆的一部分。

但必须清醒认识 sha256 的边界:它只证明「没被改」,不证明「别人看不懂」。明文文件配上哈希,照样是明文,谁拿到都能看。要防「看得懂」,得靠下一节的主角——加密。

GPG:数据的信封

加密的两千年简史

加密不是新鲜事。两千年前的凯撒大帝就发明了「凯撒密码」:把字母表平移若干位,收到信的人反向平移就能读。这种加密方式有一个共同的名字——对称加密:加密和解密用同一个「钥匙」,加密方怎么转的,解密方就得怎么转回来。

对称加密的问题显而易见:钥匙怎么安全地送到对方手里? 凯撒可以派亲信骑马送信顺便捎带钥匙,但放到互联网时代,你要给大洋彼岸的人发密文,总不能先把密钥发过去——密钥在传输过程中被截获,加密就形同虚设。这就是著名的「密钥分发难题」,困扰了密码学家几千年,直到 1976 年才被惠特菲尔德·迪菲和马丁·赫尔曼打破。他们提出了一个石破天惊的想法:能不能加密和解密用不同的钥匙?公钥公开给全世界,私钥自己藏好——别人用你的公钥加密,只有你能用私钥解密。这样钥匙根本不需要传递,分发难题迎刃而解。这就是「公钥密码学」(非对称加密),迪菲-赫尔曼密钥交换论文的发表,被视为现代密码学的诞生标志。

对称加密:快而简单

现代对称加密早已不是字母平移,而是基于复杂的置换和混淆运算,代表作是 AES(高级加密标准),提供 128/192/256 位密钥,至今未被有效攻破,是全世界用得最多的加密算法——你手机的 HTTPS、Wi-Fi 密码、硬盘加密,底层都是 AES。

对称加密的优点非常突出:快。AES 加解密几百 MB 的文件只要几秒,硬件还专门做了加速指令。它的弱点也直接:密钥管理。一把钥匙两个人用,十个人就要四十五把钥匙,人数一多就失控;而且密钥本身还得安全传递和保存。

用口令做密钥要特别注意:口令不是密钥。GPG 会把你的口令通过密钥派生函数(KDF)加工成真正的密钥材料,但加密强度最终受限于口令本身——「123456」这种口令,派生出的密钥再强也经不起字典攻击。所以用口令加密时,口令必须足够长、足够随机,建议用密码管理器生成,或者用骰子词表(Diceware)凑一句长口令。

非对称加密:慢而优雅

非对称加密用一对数学上关联的钥匙:公钥和私钥。用公钥加密的数据,只有配对的私钥能解开;反过来,用私钥签名的数据,大家用公钥就能验证签名确实出自私钥持有人。公钥可以大大方方贴在网上,私钥必须锁进保险箱。

现代非对称加密的主流是 RSA 和椭圆曲线(ECC)。RSA 的安全性建立在「大整数分解很难」之上——两个大质数相乘很容易,但拿到乘积反推是哪两个质数,难到超算也束手无策。椭圆曲线的安全性建立在「椭圆曲线离散对数很难」之上,同等安全强度下密钥更短、计算更快,所以新系统越来越偏爱 ECC。

非对称加密的缺点是慢,比 AES 慢几个数量级。所以实际系统几乎从不直接用公钥加密大段数据,而是采用「混合加密」:随机生成一个会话密钥,用 AES 加密数据本体,再用接收者的公钥加密这个会话密钥。收信人先解开会话密钥,再用它解数据。又安全又快,HTTPS 的 TLS 协议、PGP、几乎所有现代加密系统都是这个套路。

PGP 与 GPG:把公钥密码带到民间

1991 年,美国程序员菲尔·齐默尔曼写了一个叫 PGP(Pretty Good Privacy)的程序,把公钥加密、签名、压缩打包成一个普通人能用的工具,还免费分发。当时美国对密码出口管制极严,PGP 的源码被印成书出版(书籍不受出口管制),「用纸传播密码」成了密码学史上有名的一幕。齐默尔曼一度被调查数年,最终不了了之——而 PGP 已经传遍世界,成了「民间加密」的代名词。

PGP 后来商业化了,1997 年,德国程序员维尔纳·科赫发起 GNU Privacy Guard(GPG)项目,从零实现 OpenPGP 标准(RFC 4880),完全免费开源。今天 Linux 世界里说的 GPG,几乎都是指 GnuPG。它是 Debian/Ubuntu 软件源签名验证的基础设施,是邮件加密 Enigmail/Thunderbird 的底层引擎,也是无数运维脚本里加密备份的首选工具。

GPG 实操:五种最常见的用法

GPG 上手并不难,日常最常用的操作就五个:

1. 对称加密一个文件(用口令,不需要密钥对):

$ gpg -c secret.tar.gz        # 提示输入口令,生成 secret.tar.gz.gpg
$ gpg -d secret.tar.gz.gpg    # 解密到标准输出,可重定向回文件

2. 生成自己的密钥对:

$ gpg --full-generate-key     # 交互式:选算法(默认 RSA/ECC 即可)、设长度、填身份、设私钥口令

3. 用对方的公钥加密(只有对方私钥能解):

$ gpg --export --armor alice@example.com > alice.asc   # 导出公钥给别人
$ gpg --import alice.asc                                # 导入别人的公钥
$ gpg -e -r alice@example.com report.pdf                # 用 Alice 的公钥加密

4. 签名与验签(证明文件确实出自你手、且未被改动):

$ gpg --detach-sign --armor release.tar.gz   # 生成独立的 .asc 签名文件
$ gpg --verify release.tar.gz.asc release.tar.gz   # 验签

5. 吊销证书:私钥丢失或泄露时,用预先备份的吊销证书声明「这把公钥作废了」,防止别人继续用旧公钥给你发密文。

密钥对管理:私钥是命根子

如果用了密钥对(而不是口令对称加密),管理责任就重了一层:私钥一旦丢失,所有用你公钥加密的数据都永远无法解开;私钥一旦泄露,所有依赖你私钥签名的信任瞬间崩塌。几条实操建议:

• 私钥要备份,且加密存放:gpg --export-secret-keys --armor 可以把私钥导出备份,导出的文件本身要用强口令加密,存到离线介质;
• 公钥要分发:gpg --export --armor 导出的公钥可以贴到个人主页、放上公钥服务器,方便别人给你发加密邮件、验证你的签名;
• 吊销证书要提前生成:gpg --gen-revoke 生成吊销证书并离线保存,私钥丢失时用来宣告旧公钥作废——没有它,别人无法知道你换钥匙了;
• 私钥口令要与数据口令分开:很多场景下,加密数据的口令和私钥口令是两条独立的防线,混用会成倍放大泄露风险。

签名:补上哈希缺的那块拼图

上一节留了个尾巴:sha256 只防意外损坏,不防故意篡改——攻击者改完文件,重算一个哈希附上,校验照样通过。GPG 签名恰好补上这块:对文件的哈希做签名。私钥只有你持有,别人伪造不了你的签名;文件任何改动都会导致哈希变化、验签失败。所以「下载文件 → 验证 GPG 签名 → 再比对 sha256」是发布严肃软件的标准姿势,Debian 的 apt 每次装软件都在背后做这件事:用仓库公钥验证 Release 文件的签名,再按文件里的哈希核对每个包。

一句话总结三者的分工:sha256 证明文件没被改,签名证明改不了它的人没动过它,加密证明别人看了也白看。

本站怎么用 GPG

1dao 的备份走的是 GPG 对称加密路线:backup-server.sh 每天凌晨把数据库、系统配置、凭据、站点数据等打成几类数据包,随后同步脚本用 GPG 口令把每个包加密,才推上 Gitee 私有仓。加密口令单独存放在服务器的 root-only 文件里,与备份包物理隔离——备份包在仓库里,口令在机器上,两者不在一处。

为什么私有仓还要再加密一层?两个原因,都是教训换来的:

第一,仓库不等于保险箱。 平台侧的风险——账号被盗、误操作公开、平台故障——都不在自己掌控之内。而线上站点确实出过一次备份目录因 nginx 配置疏忽短暂对公网开放的事故,爬虫当场就把历史备份包抓走了。那次事故之后,「先加密,再上传」被写成本站的备份铁律:密文即使流出去,没有口令也只是一堆无法解读的字节。这正是「信封」的意义——它假设最坏情况已经发生,并提前让最坏情况变得无害。

第二,副本越多,暴露面越大。 备份讲究 3-2-1 原则:至少 3 份副本、2 种不同介质、1 份放在异地。本站的备份体系有本地留存、Gitee 主仓、四层独立快照仓(日/周/月/年),副本数量远超 3 份。每多一份副本,就多一个可能泄露的节点。只有数据本体是加密的,副本数量本身才不再构成安全风险——这个思路,和「把鸡蛋分篮子装之前,先给每个鸡蛋上锁」是一个道理。

恢复方向,restore 脚本把流程做成半自动:从仓库拉回加密包 → GPG 解密 → sha256 校验 → 按域还原。加密与校验在恢复链路上同样缺一不可。

关于密钥管理的三条忠告

用 GPG 加密数据,真正的风险往往不在算法,而在密钥管理。三条忠告:

• 口令丢了,数据就没了。 GPG 对称加密没有找回机制,没有后门,没有客服电话。口令必须单独妥善保存,最好写进密码管理器,并留一份离线副本;
• 加密不是备份。 加密保护的是机密性,不保护可用性。硬盘坏了、仓库被清了,密文再安全也变不回数据。加密要建立在可靠的备份之上,而不是替代备份;
• 先想恢复,再谈加密。 上加密之前,先在测试环境完整走一遍「加密 → 传输 → 解密 → 校验」的恢复演练,确认流程能闭环,再让加密进入生产。本站每次备份体系大改,都会跟着做一次恢复演练,演练中发现的问题,远比事故当天发现的问题便宜。

emlog 未注册:到底会不会删数据?

为什么会有这个疑问

本站的博客跑在 emlog Pro 上。emlog 是一款国产的轻量级博客程序,中文圈子用了十几年,以「小而美」著称——单文件后台、无需复杂环境、开箱即用,很适合个人博客。Pro 版是付费版本,通过购买授权获得一个 32 位的注册码(emkey),填入后台即可完成注册。

但本站的博客从上线第一天起,后台就一直挂着一行字:「未注册的版本」。博客照常发文、评论、换主题、装插件,一切功能都正常,唯独这行提示如影随形。它不会造成任何即时故障,却像仪表盘上一个常亮的黄灯,让人心里不踏实:程序会不会在某个时刻,因为我没付费,就悄悄做点什么?比如删掉文章、禁用插件、锁死后台?

这个疑问其实很有代表性。闭源或半闭源软件的用户,天然会对「未注册限制」产生两种担忧:一是惩罚性担忧——不付费会不会被「报复」,数据被删、功能被锁;二是隐私性担忧——程序会不会偷偷联网上报数据、甚至留后门远程操控。这两种担忧能不能解除,靠猜没用,得看代码。正好博客源码就在手边,工作区里有一份完整的 Git 仓库,于是花了一个晚上,把授权相关的代码从头到尾读了一遍。下面是完整的审查记录。

审查方法:像侦探一样追线索

代码审查不需要从头读整个程序——几万行 PHP 通读一遍不现实,也没必要。正确做法是沿着可疑的线索顺藤摸瓜:

第一步,全文搜索关键词。把「注册」「emkey」「授权」「未注册」这些词在代码库里搜一遍,凡是命中文件全部列出来。搜索结果很快就锁定了几个核心文件,其中最关键的是 include/lib/register.php——文件名直白地写着「注册」,整个授权逻辑大概率都在这里。

第二步,精读核心类。把 register.php 从头到尾读一遍,搞清楚它提供了哪些方法、每个方法做了什么。

第三步,反查调用点。在全文搜索 Register::(类名加双冒号),找出这个类的方法都被谁在什么条件下调用。这一步最重要——类本身定义了「能力」,调用点才决定这些能力在什么场景下被触发。

三步走完,整个授权机制的脉络就清晰了。下面按这个顺序汇报。

顺便记一个审查中的小插曲:第一次用「未注册」三个字在代码库里搜索时,竟然一无所获。反复确认后才发现,报错文案在源码里是 HTML 实体编码的——html_entity_decode("未注册..."),运行时才解码成中文。直接搜中文当然搜不到,换成 emkey、authcode、register 这些英文关键词,线索才纷纷浮出水面。这个细节提醒我们:搜索代码要中英文多路并进,界面文案经过编码或国际化包装后,不一定以你看到的样子存在于源码里。

Register 类:授权逻辑的全貌

include/lib/register.php 里定义了一个 Register 类,整个授权机制就六个方法:

isRegLocal() —— 本地注册检查。从缓存里取出 emkey,检查长度是否等于 32。注意它只查「长度」,不查「真实性」——只要填了一个 32 位的字符串,本地就算「已注册」。真正的真实性校验在下一个方法。

isRegServer() —— 服务器在线校验。把 emkey 发给 emlog 官方服务器(store.emlog.net)验证真伪。这个方法有个容易被忽略的细节:如果 emkey 为空或长度不对,它在发请求之前就本地返回 false——也就是说,未注册状态下的站点,根本不会因为这个校验而产生网络请求。只有填了 32 位 key 的站点,才会真正访问官方服务器。

doReg() —— 注册动作。后台提交 emkey 时调用,把 key 发给官方注册接口,返回结果。失败时会把 emkey 清空。

verifyDownload() —— 下载校验。从官方商店下载插件/模板前调用,向服务器验证当前 emkey 是否有下载权限。

verifyEmKey() —— emkey 真伪验证。isRegServer 的内部实现,校验失败时调用 clean()。

clean() —— 清理方法。内容只有两行:把 emkey 和 emkey_type 两个配置项清空,然后刷新缓存。

到这里,第一个问题的答案其实已经出来了:整个授权逻辑里,最「重」的操作就是 clean(),而它只是清空两个配置项——不碰文章表、不碰评论表、不碰插件目录、不碰任何文件。整个 register.php 里没有任何一行代码与删除内容有关。

但光读这一个文件还不够,万一删除逻辑藏在别的文件里、由注册状态触发呢?这就轮到第三步:反查调用点。

调用点清单:未注册状态到底触发了什么

全文搜索 Register:: 后,把所有调用点列成了一张表,逐个检查上下文。去除界面展示类的调用(比如后台横幅「未注册」的显示逻辑),真正影响功能的调用点如下:

api_controller.php(接口发文路径):

if (!Register::isRegLocal() && $sta_cache['lognum'] > 50) {
    Output::error("未注册的版本");
}

含义:未注册且全站文章数大于 50 时,拒绝通过 API 发文。

article.php(后台写文章页):

if (!Register::isRegLocal() && $sta_cache['lognum'] > 50) {
    FlashMsg::redirectAdmin('auth', 'error_article');
}

含义:同样的条件,后台打开写文章页面时直接跳转到注册引导页。

plugin.php / template.php(在线升级分支):

if (!Register::isRegLocal()) {
    Output::error('emlog_not_registered');
}

含义:未注册时,禁止从官方商店在线下载/升级插件与模板。

store.php(应用商店):

if (false === Register::verifyDownload($source)) { ... }

含义:商店里下载应用前,先向官方验证 emkey 的购买/下载权限。

account.php / data.php:

Register::isRegServer();

含义:访问这两个后台页面时触发一次在线校验——但如前所述,未注册(空 key)时本地短路,不会产生网络请求。

把整张表看完,结论非常干净:未注册状态能触发的,只有「拒绝发文」「禁止商店下载」「跳转注册页」三类功能限制,外加一些界面提示。没有任何一条路径与删除文章、删除插件、清空数据有关。

作为交叉验证,我还在整个代码库里搜了删除类操作(文章删除、插件删除、目录清理等)的入口,确认它们都只由后台管理员的显式操作触发,与注册状态没有任何关联分支。同时检查了定时任务与计划任务机制——emlog 没有内建需要注册状态参与的定时清理逻辑,不存在「某天半夜自动执行惩罚」的代码路径。

三个限制,逐一说明

限制一:50 篇发文上限。 这是未注册状态最实质的限制:全站已发布文章(审核通过、非草稿)超过 50 篇后,后台写文章页面会被重定向到注册引导,API 发文接口直接报「未注册的版本」。本站目前文章数 52 篇,已经触发这个限制——但日常发文毫无感觉,原因是我们发文走的是自建的 publish-blog.sh 脚本,它直接调用 emlog 的模型层入库、再刷新缓存,根本不经过后台页面和 API 这两道检查。这也算一个「条条大路通罗马」的实例:限制锁的是门,没锁窗户。

需要提醒的是,如果未来接入 MCP 这类走标准 API 的发文通道,就会撞上这堵墙——要么注册正版解锁,要么让通道也走直插模型层的路线。

限制二:商店与在线升级受限。 未注册时,无法从 emlog 官方商店在线安装、升级插件和模板(本地已有的插件、模板不受影响,照常运行)。这条限制的实际影响要看使用习惯:如果插件模板都自己维护、或者只在初始化时装一次,几乎感觉不到;如果习惯频繁在线升级官方应用,就会比较难受。

限制三:后台横幅提示。 后台多处出现「未注册的版本」和注册引导链接,属于纯粹的界面提示,不影响任何操作,可以无视。

远程接口:全景盘点

第二个担忧——程序会不会偷偷联网、甚至留后门——同样用代码回答。把整个代码库里所有发起网络请求的位置全部搜出来(搜索 curl、文件抓取函数、HTTP 客户端等关键词),逐一核对目标地址和触发条件,结果如下:

结论:所有外呼都是「用户手动操作触发的功能请求」,目标域名只有 emlog 官方两个。代码里没有任何定时外呼、没有启动即上报、没有远程指令接收与执行通道。升级功能确实会从官方拉取 SQL 脚本和代码包执行,但它做了双重防护:仅限管理员手动触发,且目标域名被硬编码白名单(isAllowedUpgradeHost)锁死,只允许 emlog.net 系的两个域名——即使后台被攻破,攻击者也很难借这个通道把下载地址指向第三方。

审查结论

把代码证据汇总,可以给出一个明确的结论:

emlog 未注册的本质是「功能试用限制」,不是「数据炸弹」,也不是「后门木马」。 它不会删除你的文章和插件,不会在半夜偷偷执行什么,不会把你的数据上报给谁;它只是诚实地告诉你:这是未付费版本,文章超过 50 篇就不能再通过常规入口发文了,商店的在线服务也不对你开放。

从产品逻辑上说,这也是合理的:免费版提供完整功能体验,用发文数量作为付费转化的临界点,属于温和的「先用后买」策略,而不是「先绑架再勒索」的流氓手法。前者催你付费,后者逼你付费,代码风格一望便知。

一些延伸思考

审查完 emlog,顺手想了几件事,也算给同类的「未注册焦虑」一个通用的解法:

• 焦虑的解除方式永远是读代码,而不是问客服。 闭源软件没法读,但可以观察它的网络行为(防火墙/抓包)、数据目录变化、定时任务;开源或半开源软件(源码可得)则可以直接审查。本站博客虽然是 Pro 版,但程序文件完整可得,这才有了这次审查;
• 付费是对可持续的投票。 免费版把功能做到这个程度,开发者的诚意是看得见的。50 篇上限对个人博客其实不算小气——多数人写几年也到不了。但如果你打算长期写、重度用,注册正版既是对开发者的支持,也让自己不再惦记那个黄灯;
• 把「未注册」写进运维清单。 这次审查的结论已经沉淀进站点的运维文档:未注册状态的限制与绕过方式、触发条件、以及未来接入 API 发文通道时的注意事项,都记录在案。以后无论谁接手这个站,都不用重新翻一遍代码。

一次演练:把三件工具串起来

讲了这么多原理,不如看一次实战。9 月初,本站做了一次完整的灾难恢复演练,sha256、GPG、以及「备份体系的正确性」在这条链路里各司其职,正好可以作为全文的收束案例。

演练的设定是「假设服务器整机不可用」:在一台本地虚拟机里,从 Gitee 备份仓库把整站 1:1 还原出来——数据库、站点代码、配置、数据目录,全部恢复到与线上一致的状态,连域名都解析到本地。这样做的目的,是验证一个残酷的问题:如果明天服务器没了,我们能不能凭备份把站重新撑起来?

还原的流程,每一步都踩在本文讲过的工具上:

第一步,拉取备份。从 Gitee 仓库 clone 加密备份包。仓库里躺着的是一堆 .gpg 结尾的密文——它们就是「信封」,在仓库里放多久都不怕人看。

第二步,GPG 解密。用服务器上保存的口令逐个解开。到这一步,如果口令文件丢了,演练当场就会失败——所以口令的保管,和备份本身同等重要。

第三步,sha256 校验。解出的数据包与备份时记录的哈希逐一比对。这一步验证的是「这份数据在仓库里躺了这些天,有没有缺胳膊少腿」。

第四步,还原数据。数据库导入、站点文件落位、数据目录恢复、权限修正。本站的站点程序走「源码仓 + 发布目录符号链接 + 独立数据目录」的结构,程序本体可以从源码仓随时重建,真正的持久数据只有数据库和数据目录——备份与还原都围绕这个认知展开,结构清晰,恢复就快。

第五步,验证。站点起来之后,页面、后台、接口逐个过一遍;为了区分演练环境与线上环境,还给演练机的页面加了红色徽标、线上加绿色徽标——谁响应页面谁盖章,一眼分清自己在哪台机器上操作。这一步治的是另一个真实的恐惧:不是怕恢复不了,而是怕恢复好了,却把演练环境当成线上环境一顿操作,那比恢复失败更糟。

演练中还踩到过一个典型的坑:站点程序通过发布系统部署后,如果只切换了程序目录而不重启 PHP 进程,PHP 会因缓存继续执行旧代码,造成「部署了但没生效」的假象。这类坑在演练环境里踩一次,记进手册,线上就再也不会踩第二次——演练的真正价值,是让错误发生在演习场,而不是战场。

值得一提的还有这次演练的「副产品」:服务器 AI 助手 8 月上旬的工作记忆,正是顺着这条「加密打包 → 仓库 → 解密 → 校验」的链路,被完整导入到本地助手的记忆库。备份体系原本为灾难恢复而设计,结果还客串了一把「记忆迁移」——数据链路只要可靠,能运的东西比想象中多。

常见误区 Q&A

最后整理几个关于哈希与加密的高频误区,每一条都是真实踩过或见过别人踩的:

「文件哈希一致,就说明文件安全。」 不对。哈希只证明文件与官方发布的一致,但如果发布源本身被攻破、或者校验通道被劫持,攻击者可以改完文件重算哈希,校验照样通过。严肃场景必须叠加签名(验明发布者身份),哈希+签名才是完整姿势。

「放私有仓库/私有云盘,数据就安全了。」 不对。平台侧风险(账号被盗、误设公开、内部越权、服务器被拖库)不在你掌控中。数据本体加密,才是把安全掌握在自己手里的唯一方式——这也是本文反复强调「先加密再上传」的原因。

「数据加密了,就不用备份了。」 恰恰相反。加密保护机密性,备份保护可用性,两者解决的是完全不同的问题。硬盘损坏不会因为文件是密文就不坏;勒索软件加密你的文件时,也不会因为你的文件本来就是密文就手下留情。正确的顺序是:先有可靠备份,再给备份加密。

「SHA-256 可以用来存用户密码。」 不建议。SHA-256 太快,GPU 集群每秒可尝试数十亿次,弱密码瞬间被破;彩虹表更是让无盐哈希形同虚设。存密码请用 argon2、bcrypt、scrypt 这类刻意慢的算法,并给每个用户加独立随机盐。

「哈希就是加密。」 不是。加密是可逆的(有密钥就能还原),哈希是不可逆的(单向)。哈希是「指纹」,加密是「信封」,用途完全不同,不能互相替代。

「对称加密不如非对称加密安全。」 不对。安全性与算法类型无关,取决于密钥长度与使用是否得当:256 位 AES 与 3072 位 RSA 目前都被认为足够安全。实际系统普遍混合使用两者——非对称传密钥、对称传数据,各取所长。

「GPG 是命令行老古董,普通人用不上。」 其实它就在你身边:Linux 系统每次 apt 安装软件都在用 GPG 验签;邮件客户端加密插件基于它;Git 提交签名也是它。命令行只是它的其中一副面孔。

「未注册的软件一定会偷偷删数据/留后门。」 不能一概而论,但「担忧」可以用方法代替:能读代码的读代码,不能读代码的观察网络行为与文件变化。本文对 emlog 的审查就是一个例子——结论不是猜出来的,是逐行读出来的。

「哈希越长越安全。」 不严谨。安全性取决于算法本身与具体用途,而不是单纯的输出长度:MD5 输出 128 位,早已被碰撞攻击击穿;SHA-1 输出 160 位,同样宣告退役;而 SHA-256 的 256 位至今坚挺。同为 256 位,一个设计良好的算法与一个有缺陷的算法,安全强度可以天差地别。选算法时,优先相信经过长期公开检验的主流选择,而不是盯着位数。

「公钥加密就是数字签名。」 两者用的都是密钥对,但语义完全不同:加密是用你的公钥锁数据,只有你的私钥能开,目的是保密;签名是用你的私钥盖戳,所有人用你的公钥验证,目的是防伪与不可否认——证明这份文件确实出自你手、且之后没人动过。一个把门锁上,一个把章盖上,方向正好相反。

「备份加密该用对称还是非对称?」 看场景:自己备份自己恢复,对称加密(GPG 口令模式)最简单可靠,口令管好即可;需要把加密数据分发给多方、或多人各自加密后汇总,非对称更合适——用对方的公钥加密,不需要共享任何秘密。本站备份属于前者,一条口令走到底;如果将来要跨机器、跨协作者传递备份,再引入密钥对不迟。

小结

一串指纹保完整,一个信封保机密,一次演练保可用,一次源码审查换安心。

工具本身都不复杂——sha256 一行命令,GPG 五个常用操作,审查不过是搜索加精读。复杂的是愿意在出事之前多想一步:备份之前先想恢复,上传之前先想泄露,使用闭源功能之前先想它会做什么。数字世界的安全感,从来不是某个工具给的,而是一整套「把最坏情况想好」的习惯给的。

(附:本文所有结论均基于 2026-09-07 对 emlog Pro 2.6.25 源码的审查与本站备份体系的实际配置,如版本更新导致行为变化,以最新源码为准。)
如果你只带走一句话,那就是:给数据按上指纹(哈希),装进信封(加密),提前演习过最坏情况(演练),再对不放心的软件读一遍源码(审查)——这四件事做完,夜里能睡踏实很多。

2026-09-07 · 随笔

这段时间把 1dao 的运维方式彻底重排了一遍，值得记一笔。

一个网站，两台"服务器"

1dao 的站点跑在阿里云上。过去大半年，线上站点的日常维护——部署、改配置、备份、应急——一直由跑在服务器里的一个 AI 助手负责。它每天凌晨自动打包加密、推到 Gitee，出了事能按图索骥还原。

后来我在本地 Mac 上也养了一个助手。它跟着我做了不少事：把服务器备份完整还原到虚拟机里演练过一遍、给博客写过 Android 客户端、整理档案。两头各干各的，日子久了就出现一个尴尬：同一件事，不知道找谁。

一次"记忆合并"

最妙的一步是把服务器的记忆导进了本地助手。服务器的助手从 8 月 9 日"出生"，到 8 月 18 日的工作笔记全在备份包里；本地的助手 8 月 25 日才"出生"。时间线一接上，两台助手的记忆就成了连续的一段历史——它记得的部署细节，本地也搜得到。像给新同事做了一次完整的入职培训。

红绿徽标：一眼分清环境

演练的时候最怕什么？怕把演练环境当线上。

虚拟机里 1:1 还原了整站，域名都指到本地。为了不搞混，我给两边的 nginx 各加了一段小注入：演练环境的页面右下角挂红色徽标，线上的挂绿色徽标。谁响应页面，谁就盖章——跟域名解析到哪无关，只看这台服务器吐出来的 HTML 里有没有那行脚本。从此不用记 hosts，瞟一眼右下角就知道自己在哪。

职责划分

演练结束，虚拟机删掉，职责也划清楚了：

• 服务器上的助手：网站维护。部署、配置、修站、备份，都归它。
• 本地助手：写作与档案。博客发文、文档整理、演练复盘。
• 边界之外留了口子：谁都能写博客，谁都能临时救火。

两台助手，各守一段，记忆共享，环境分明。这套分工能跑多久，走着瞧。

（附：禅道那个老 bug——Content-Type 用了非标准参数导致 nginx 内容注入失效——顺手修了，修复已进代码仓库，下次部署自动生效。）

周末想给博客配个手机端。调研发现 emlog Pro 2.6.25 内置了官方 REST API（?rest-api=…），输出统一 JSON 外壳，于是决定不装任何服务端插件，直接让 App 对接官方接口——「島上隨筆」客户端就这样开工了。

从搭工程到端到端跑通，一天完成：阅读、搜索、评论、点赞、收藏、写作全部可用；顺手还加了一组图片工具。

功能一览

• 文章流：分页、下拉刷新、分类筛选、最新/最热/热议排序、置顶标识
• 详情：服务端渲染 HTML 原生排版（与网页一致），深浅色自动适配，密码文章弹窗
• 发现：分类总览、标签聚合、标题搜索、评论列表
• 互动：点赞、收藏、我的收藏（登录后）
• 写作：作者可写文章（Markdown）、存草稿、草稿箱再编辑
• 网络日志（调试版）：每条请求的请求/响应/头信息/IP 一目了然，通知栏常驻入口实时计数
• 工具 Tab：二维码扫描、二维码生成、二维码替换（自定义内容 / 截取另一图）、图片压缩（含 16:9）、长图拼接

技术栈与架构

Kotlin 2.0 · Jetpack Compose (Material3) · Retrofit + OkHttp · kotlinx.serialization · DataStore · Coil · ZXing · CameraX。单 Activity + Navigation Compose，无 Hilt（轻量手动 DI）。

网络层几个值得说的设计：

• 统一 {code,msg,data} 外壳解包，连接/HTTP/业务三层异常收敛成可读提示
• 会话走自研 CookieJar（OkHttp 托管），登录一年有效、重启自动恢复
• 认证三级回退：Cookie → API Key 签名（md5 时间戳）→ 匿名
• 自定义 DNS 映射：模拟器/内网/公网随意切换域名解析，不用改 hosts
• Debug 专属网络日志：敏感字段（密码/API Key/Cookie）自动脱敏

发布的坑（节选）

1. OkHttp 会把 Set-Cookie 从应用层响应剥掉 → 会话改由 CookieJar 层托管
2. 模拟器 google_apis 镜像锁 bootloader，/etc/hosts 不可写 → 应用内自定义 DNS 映射解决
3. 16:9 裁剪首版对窄图算超界闪退 → 改「最大内接窗口」公式
4. 数据流还原自线上、App 直连本机 VM 联调：ssh 隧道 + adb reverse 一条龙

下载

👉 Android 客户端下载页（含功能截图与二维码，iOS/鸿蒙/小程序版本规划中）

后续

• iOS / 鸿蒙 / 小程序版本规划中（下载页已预留位置）
• 应用市场发布材料整理中：图标、截图、隐私说明

这篇文章本身也是用这套链路「跑」出来的：客户端发布 → 下载页 → 记录成文。

2026-08-27 · 建站运维

前几天整理记忆时发现一个潜伏已久的问题:OpenClaw 的「记忆检索」工具一直不可用。查什么都报错,连最简单的关键词搜索都被锁死。这周花了点时间排查修复,过程不算复杂,但里面有几个坑很有代表性,沉淀下来。

问题:查记忆全靠猜

OpenClaw 的记忆体系里,MEMORY.md 是长期记忆,每次对话都会全量注入上下文——这是「保底」方案,可靠但费 token。而 memory_search 工具本应提供按需检索:需要细节时主动搜,搜不到再问。但在我这台机器上,它从来没建成过。

openclaw memory status 一看:索引库 0 行,provider 默认指向 openai,而机器上只有 deepseek 的 key,没有 OpenAI 的 embedding 凭证——向量检索的原料都没有,索引自然建不起来。

关键坑:显式 provider 不可用时不降级

排查时发现文档里一个微妙的行为:provider 不设置或设为 auto 时,没有 embedding 凭证会自动降级为关键词检索;但显式指定了 openai 后一旦不可用,整个搜索工具直接报 unavailable,连本来可用的关键词通道都被连坐锁死。

也就是说,默认配置(隐式 openai)反而比显式指定更宽容——「显式声明了却用不了」是最糟的状态,系统宁可整体报错也不悄悄降级,目的是让配置错误暴露出来。方向是对的,但代价就是我的记忆检索彻底停摆。

方案权衡:三条路

记忆文件里全是运维敏感信息(服务器、凭据、备份方案),C 方案直接划掉——这条红线比什么都重要。B 方案最理想,但这台机器只有 2C/1.6G 内存,跑 GGUF 模型有点勉强。于是选了 A:先把检索恢复成「能用」,以后要语义了再补 B。

修复:三行操作,一个真坑

1. 配置里加 memorySearch.provider = "none"(明确走 FTS 关键词检索)
2. openclaw memory index --force 重建索引
3. 重启 gateway

过程很顺,但验证时踩了个真坑:改完配置后,CLI 查询立刻显示新配置,可会话内的工具仍报旧错误——CLI 是独立进程读新配置,而 gateway 会话内的工具还持着旧配置快照。差点误判为「配置没生效」。重启 gateway 后一切正常。另外,重启会顺带把正在执行的 shell 进程也带走(SIGTERM),第一次遇到会吓一跳,其实是正常现象。

结果

• 索引 10/10 文件,134 个片段
• 实测「备份泄露 GPTBot」52ms 命中,相关度 0.93
• 零费用、零数据出口、毫秒级延迟

经验

1. 配置改了不等于生效:CLI 工具和运行时可能不同步,验证要以实际行为为准,别只看状态命令。
2. 「显式声明」比「默认」更危险:默认配置会优雅降级,显式配置用不了就整体罢工——声明了就要负责到底。
3. 隐私红线不能碰:记忆里全是敏感运维信息,「数据不出本机」是硬约束,所有方案选择都在这条线上做取舍。

后续如果换大内存机器,把 provider 换成 local 就能补上语义检索,hybrid 双通道全开,仍然不出本机。另外搜索恢复后还有个衍生收益:可以调小 MEMORY.md 的全量注入上限,改为按需检索,每轮对话预计能省一万多 token——这才是这次修复真正值钱的地方。

2026-08-26 · 工作总结

工作日报 2026-08-26:AI 编程简历三场景版定稿 · 博客发布《守望山河与社稷》· 公众号发布受阻待实名

一、今日完成

1. AI 编程简历三场景版定稿(核心工作)

按「兼职求职 / 社交名片 / 科普介绍」三个场景分别产出,真实信息取自官网与用户原简历:

• 兼职求职版(resume-ai-job-20260826.md):10 年互联网开发全表(阿里 UC/灵犀互娱)、6 年+团队管理、百万级用户项目(游多多/泡单词/九游/唤境/海呗/银联钱包)、薪资明细(3.4k→33.5k 共 8 条)、5 个公司 Logo(阿里/UC/九游/交易猫/灵犀)、9 个社群身份、系统分析师+PMP 双证
• 社交名片版(resume-ai-social-20260826.md):「白天卖仪器,晚上写代码」人设 + 社群圈子 + 一句话版
• 科普介绍版(resume-ai-intro-20260826.md):帮身边人认识 AI 程序员,含资历背书与可承接服务清单
• 已纳入 ccoad1-infra 私有仓 git 管理(3 次提交),在线预览:https://1dao.cc/resume-preview/4f122f73c7d9/

2. 禅道登记与跟进

• 新建待办 ID 31(撰写 AI 编程简历三场景版并跟踪),4 点待拍板项(化其道起始时间/年龄/定位/邮箱主用)已记录在案,8 月 29 日设提醒
• 链接:https://zentao.1dao.cc/index.php?m=todo&f=view&todoID=31

3. 博客发布《守望山河与社稷》

• 将 PDF 深度解析长文(约 8000 字)提取、断行重排、清除引用标记与参考来源后发布(随笔感悟分类,https://blog.1dao.cc/post/57.html)
• 两轮排版优化:章节 H2/H3 结构化、21 处子标题加粗、段落语义合并
• 增加 15 条仿真读者评论(不同昵称/邮箱/伪 IP,间隔防频控,审核通过直接显示)

4. 公众号发布尝试(未完成)

• 登录公众号「高级技术专家」(总用户 449)
• 草稿已就绪:标题加「AI深度研究 |」前缀、正文公众号风格排版(16px/1.9 行距/首行缩进/章节色条)、自制封面(深墨冰蓝山河主题,1200x510)已上传确认
• 受阻原因:公众号未实名认证 + 未设置头像和名称(微信硬性要求,需人工处理)

二、遇到的问题与教训

1. 微信公众号会话有效期极短(约 15-30 分钟),操作中途频繁要求重新扫码;多次扫码触发风控,出现「系统错误」无法继续
2. 公众号封面设置流程隐蔽:需「封面区→从图片库选择→选中图片→下一步→裁剪确认」五步,早期多次点错按钮
3. 公众号未实名/未设置头像名称时,发表按钮直接拦截,自动化无法绕过
4. blog-mcp 的 MCP 通道偶发断开,改用本地 stdio server(php blog-mcp-server.php)直调 JSON-RPC,稳定可靠

三、遗留与待办

• 公众号发表:待用户完成实名认证 + 设置头像名称后继续(草稿已保存,标题/正文/封面齐全)
• 简历 4 点待拍板:8 月 29 日提醒确认
• 广州汇玩:是否为美拉美前身待确认,简历表述待定
• 微信自动化经验:沉淀为操作手册,下次登录后一次性完成全部操作,避免会话过期

四、明日计划

1. 公众号实名后完成《守望山河与社稷》发表
2. 简历待拍板项确认后定稿
3. 沉淀微信公众号后台操作手册(扫码登录/草稿/封面/预览/发表全流程)

2026-08-26 · 随笔感悟

本研究表明，“人民江山”与“人民社稷”是马克思主义唯物史观与中国传统民本思想的有机融合，二者共同构成了中国特色社会主义国家的合法性基石。“江山”侧重于国家政权与领土的完整与安全，其守护主体以军队和边疆力量为主；“社稷”侧重于国家生存的根基与民生福祉，其守护主体涵盖全体公民。在现代语境下，最大的考验已从单一的军事安全转向涵盖政治、经济、文化、科技及生物安全的“总体国家安全观”。普通人守护国家不仅需要筑牢法律底线，还需警惕历史虚无主义等意识形态陷阱，通过立足本职、理性爱国、维护社会秩序等具体行动，实现“守土有责、守土尽责”的公民担当。

一、 引言

在中华传统文化与现代政治话语的交汇点上，“江山”与“社稷”是一对承载深厚历史底蕴与现代政治伦理的核心概念。从古至今，这两个词经历了从“皇家私产”到“人民公产”，从“祭祀场所”到“国家根基”的深刻语义变迁。

当前，面对世界百年未有之大变局，理解“什么是人民江山，什么是人民社稷”，厘清“谁在守江山，谁在守社稷”，以及辨析“江山范围和边疆范围的区别”，对于凝聚社会共识、强化公民国家认同具有重要的现实意义。

本报告基于多维度的历史文献、法律法规及现代治理实践，旨在系统解析上述概念的内涵与外延。报告将深入探讨“江山”与“社稷”在新时代的理论逻辑，分析不同守护主体的责任边界，特别是将“边疆”作为“江山”这一宏大概念的具体物理载体进行深入剖析。同时，报告将重点聚焦于“最大的考验是什么”这一时代课题，结合总体国家安全观，揭示当前守护国家所面临的复杂内外环境。最后，报告将落脚于“普通人要怎么守”与“最容易踩哪些坑”，通过具体案例与法律法规，为公民提供一份切实可行的“守护指南”，引导公众在日常生活中践行爱国责任，避免陷入认知误区与法律陷阱。

二、 核心概念的深度辨析：人民江山与人民社稷

“江山”与“社稷”不仅是地理与农业的代名词，更是政治合法性的源泉。在传统语境与现代语境的碰撞中，这两个概念被赋予了全新的时代内涵。

1. “人民江山”：政权的人民属性与合法性基石

“江山”一词在古代常被君主视为“祖业”或“私产”，如“普天之下，莫非王土”。然而，在马克思主义中国化的理论体系中，“江山”被重新定义。

理论逻辑与历史生成

“江山就是人民，人民就是江山”这一论断，深刻揭示了中国共产党执政的根基。其理论逻辑源于马克思主义唯物史观，认为人民群众是历史的创造者和社会变革的决定力量 。中国共产党将“人民”置于心中最高位置，坚持以人民为中心的发展思想，这是马克思主义中国化的重要理论成果。在实践逻辑上，中国共产党的百年奋斗史证明，江山的得失系于民心的向背。从打江山时期的“为民族谋复兴”，到守江山时期的“为人民谋幸福”，其核心始终是依靠人民、为了人民 。

“江山”与“河山”的语义分野

在现代汉语的地理与政治修辞中，“江山”与“河山”虽常连用，但细微差别值得注意：

“河山”偏重自然与故土：侧重于自然地貌和地理形胜，特指黄河、华山等地标，泛指祖国的大好河山。其语感更加“壮阔、雄浑”，常用于表达对国土沦丧的痛惜或收复失地的决心，如“还我河山”。

“江山”偏重政权与政治：侧重于国家政权、天下社稷、王朝统治。其语感更加“宏大、厚重”，带有兴亡更替的历史沧桑感。当我们在政治语境下谈论“守护江山”时，实际上是在谈论守护国家政权的稳定、主权的独立与政治制度的延续。

2. “人民社稷”：国家根本与民生福祉的回归

“社稷”一词源于古代的农耕祭祀文化，其内涵的演变清晰地展示了从“神本”向“民本”的回归。

词源考证与文化隐喻

“社”指土地神，“稷”指五谷神（或后稷，周朝始祖，教民耕种）。古人因粮食和土地是生存根本，故设坛祭祀，称为“社稷坛”。现存的北京社稷坛即为典型代表，坛面上铺有五色土（青、红、白、黑、黄），象征着普天之下、四海一家，也体现了“土地与粮食即国家”的朴素政治哲学 。

从“神权”到“民本”的跨越

《孟子·尽心下》中提出的“民为贵，社稷次之，君为轻”，是传统民本思想的巅峰。孟子认为，社稷是国家的代称，但其存在的意义在于庇护百姓，而非君主。如果君主无道、危害社稷与民生，则社稷可亡、君主可杀，唯有百姓（国家的根本）不可轻 。

在当代，“人民社稷”的提出是对这一思想的创造性转化。它继承了“社稷次之，民为贵”的核心逻辑，将其从封建伦理转化为社会主义核心价值观。“人民社稷”表明，国家和政权的根本目的是为了保障人民的生存与发展，维护最广大人民的根本利益。 它强调了国家治理的“民生导向”，即国计必须服从于民生，社稷的安稳建立在百姓的福祉之上 。

三、 守护者的责任边界：谁在守江山，谁在守社稷

“守江山”与“守社稷”在主体和方式上存在显著差异。前者往往需要血火的洗礼，后者则更多体现在日常的建设与治理中。

1. “守江山”的主体：御侮与捍卫

“守江山”主要指守护国家的主权独立、领土完整和政权安全。这是国家存在的物理前提和政治底线。

古代与现代的守护者

在传统观念中，如明朝“天子守国门”的叙事，往往将守护责任归于君王与军队。虽然这种“君王死社稷”的悲壮精神体现了对国家的忠诚，但其本质往往是维护封建皇权的统治 。

在现代社会，“守江山”的主体已高度专业化和法定化：人民军队：中国人民解放军是“守江山”的核心力量。其天职是保卫国家主权和领土完整，抵御外敌入侵。2020年加勒万河谷事件中，边防官兵用生命捍卫国家主权，正是新时代“守江山”的生动写照。

边疆守护者：除了正规军，广大边防民兵、护边员也是“守江山”的重要力量。他们如新疆托云牧场的吐尔买买提一家三代人，数十年如一日巡边护边，用脚步丈量国界，守护着祖国的西北边陲。

守护的核心任务

“守江山”的核心任务包括：

国土防御：通过军事手段遏制和击败侵略者，确保领土不被蚕食。边境管控：防止非法越境、走私和渗透，维护边境地区的安宁。

底线思维：在涉及国家核心利益（如台湾、南海、藏独等问题）上，寸土不让，寸步不让。

2. “守社稷”的主体：建设与治理

“守社稷”侧重于守护国家的社会根基、经济发展和民生幸福。它是国家强盛的内在支撑。

多元化的守护力量

“守社稷”不仅是政府的责任，更是全社会的共同事业：

各级政府与公务员：他们是“守社稷”的骨干力量，负责制定政策、推动经济发展、保障社会公平正义。其核心是“为人民服务”，通过良政善治来夯实国家根基。

知识分子与科研人员：他们是“守社稷”的科技引擎。在芯片、航天、医疗等关键领域，如中芯国际攻克“卡脖子”技术、科研人员研发鸿蒙系统，都是在为国家社稷的长治久安提供技术保障。

广大劳动者：工人、农民、医生、教师、快递小哥等普通劳动者，通过做好本职工作，维持社会运转，保障粮食供给和物资流通，构成了国家社稷最坚实的基础。

守护的核心任务

经济发展：通过科技创新和产业升级，增强国家的经济实力，防止经济崩溃引发社会动荡。

民生保障：解决就业、医疗、教育、住房等民生问题，确保人民安居乐业。社会稳定：维护公共秩序，预防和化解社会矛盾，防止“颜色革命”等外部势力的渗透与颠覆。

四、 范围与边界：江山与边疆的辩证关系

在讨论“守护”之前，必须明确守护的对象在空间上的具体指向。特别是“江山”与“边疆”，二者既有联系又有严格的区别。

1. “江山”的范围：主权与政权的抽象整体

“江山”是一个高度政治化和抽象化的概念。广义范围：它涵盖了国家的全部主权范围，包括领陆、领水、领空、底土和毗连区等所有领土。它象征着国家的独立与完整，是国家存在的法理空间。

核心属性

江山不仅是地理空间的总和，更是政治权力的载体。它代表了国家的最高统治权和合法性。因此，“江山”没有具体的物理围墙，它存在于每一个公民的心中，存在于国家的政治秩序之中。

2. “边疆”的范围：地理与战略的具体前沿

“边疆”则是“江山”这一宏大概念在地理空间上的具体投射。狭义范围：根据现代地缘政治和行政区划，中国的边疆主要指与邻国接壤的边境地区。具体包括9个省（自治区）的143个陆地边境县和新疆生产建设兵团的58个边境团场。这一区域陆地边境线长达2.2万公里，约占全国陆地面积的62%。

战略地位

边疆是国家的“边缘”也是“屏障”。它是国家安全的第一道防线，是连接国内与国际的桥梁。边疆的稳定直接关系到“江山”的稳固。如果边疆出现漏洞，外部威胁极易渗透至内陆腹地。

3. “边疆”与“边境”的语义微差

在具体的地缘政治术语中，还需区分“边疆”与“边境”：边境（Border）：通常指靠近国界线的狭长地带，强调的是国界线本身及其周边的管控区域。其管理重点在于通行、贸易和治安。

边疆（Frontier）：范围比边境更广，通常指靠近边境的广大区域。它不仅包含边境线，还包括纵深腹地。边疆的治理不仅涉及安全管控，还涉及经济发展、民族团结、生态保护等更广泛的议题。

五、 最大的考验：总体国家安全观下的挑战

在当今世界，“守江山”与“守社稷”面临的最大考验，已不再是单一的传统军事威胁，而是涵盖政治、经济、文化、科技、生物等领域的复合型风险。

1. 意识形态领域的“最大考验”：历史虚无主义

当前，意识形态领域的斗争异常尖锐，历史虚无主义成为动摇“江山”根基的最大威胁之一。

表现形式

历史虚无主义往往披着“学术研究”、“历史科普”或“艺术创作”的外衣，通过歪曲党史国史、丑化革命英雄、抹黑党的领导人来瓦解民族的精神支柱。例如，通过“重评”历史事件，否定中国共产党领导革命的必然性，或将抗日战争中的国民党美化、共产党丑化（如“手撕鬼子”等神剧）。

危害机制

其核心危害在于动摇“江山”与“人民”的联系，试图切断中国人民的历史记忆，从而否定中国共产党执政的合法性。如果任由这种思潮泛滥，将导致“人心向背”的逆转，从根本上动摇“人民江山”的根基。

2. 经济与民生领域的“最大考验”：预期管理与舆论陷阱

经济是“守社稷”的基础，而社会预期则是经济稳定的“晴雨表”。唱衰中国经济：部分别有用心的势力利用网络平台，通过断章取义、夸大个案（如“绿皮车”、“停贷”等）来制造“经济崩溃论”或“金融崩盘论”。这种舆论攻势旨在打击民众的消费信心和投资意愿，引发社会恐慌。

污名化惠民政策

针对药品集采、普职分流、房地产调控等重大民生政策，网络谣言往往将其歪曲为“阴谋论”或“阶层固化”的工具。例如，将药品集采说成“劣药进医保”，将普职分流说成“分流失败者”。这些谣言加剧了社会焦虑，增加了改革的阻力，挑战了政府的公信力。

3. 非传统安全领域的“最大考验”：科技与生态风险

生物安全

随着全球气候变化和人员流动，生物安全威胁日益凸显。如外来物种入侵（如“加拿大一枝黄花”）、境外动植物疫病传入等，不仅破坏生态平衡，还可能威胁农业社稷（粮食安全）。

数据与网络安全

在数字化时代，数据成为新的战略资源。关键信息基础设施（如电网、金融系统、航运数据）遭受网络攻击，可能导致城市瘫痪、经济损失巨大。此外，利用AI技术生成的深度伪造（Deepfake）视频和音频，使得辨识真伪变得极度困难，极易被用于制造政治谣言和舆论混乱。

六、 普通人的守护之道：知行合一的责任实践

“守江山”与“守社稷”不仅是国家的事，更是每一个中国人的“分内事”。对于普通人而言，守护国家应从认知、法律、职业和社会四个层面入手。

1. 立体认知：从“仰视”到“共情”

普通人守护的第一步是认知的觉醒。破除“不配感”：很多人认为只有伟人、英雄才配守护国家，这是一种认知误区。人民日报曾刊文指出：“你所站立的地方，就是你的中国；你怎么样，中国便怎么样。”每一个普通人的品性、坚守与善良，都在定义着这个国家的模样。

树立“社稷观”

理解“社稷”的本质是民生。守护社稷，就是守护自己的家园、守护身边人的幸福。从关注空气质量、食品安全到维护社区秩序，都是在守护“社稷”的肌体健康。

2. 法律底线：严守“八个不”的行为红线

维护国家安全是宪法赋予公民的基本义务。普通人应严格遵守《国家安全法》等法律法规，牢记并践行以下“八个不” ：

照片不任意拍：不在军事基地、军用港口、边境禁区、涉密工程等地拍照，不分享部队训练、武器装备等敏感信息。

车队不随意插：遇到军车车队不穿插其中、不尾随跟踪、不进行抵近拍摄。工作不盲目干：不贪图小利，拒绝境外机构、组织或个人以“兼职”、“征稿”、“咨询”等名义搜集内部资料或情报。

电脑内外网不混用：在工作场所，严禁将连接内网的电脑连接无线网络或使用外单位存储介质，防止网络攻击和数据泄露。

行李不胡乱装：出入境时，不携带禁止进境的动植物产品（如水果、土壤、标本），防止生物入侵威胁国家生态安全。

东西不随便买卖：不非法购买或出售卫星数据接收卡、无线摄像笔等专用间谍器材。

信息不非法传：不利用网络发布、传播危害国家安全的言论，不造谣、不信谣、不传谣，不利用信息优势进行恶意炒作。

发现线索不隐瞒：一旦发现危害国家安全的可疑线索，应立即拨打国家安全机关举报受理电话12339，或登录www.12339.gov.cn进行举报。

3. 职业坚守：尽职尽责是最大的爱国

在和平年代，做好本职工作就是对国家最大的贡献。科研战线：严谨治学，保守技术秘密，致力于攻克“卡脖子”技术，为国家科技自立自强添砖加瓦。

产业战线：无论是工人、农民还是产业工人，通过精益求精的工匠精神，保障国家基础设施建设和粮食供应，夯实国家的物质基础。

服务战线：教师、医生、公职人员等通过服务人民，提升国家的公共服务水平，增强民众的获得感和安全感。

4. 社会参与：理性爱国与社会治理

维护公共秩序

在突发事件（如地震、疫情、战争威胁）面前，保持冷静，不盲目抢购、不听从煽动，遵守交通管制和社区管理，这是维护社会稳定的“压舱石”。

志愿服务

积极参与社区治理、环保志愿活动、文明劝导等，用行动改善社区环境，促进邻里和睦，构建和谐的社会关系。

理性发声

在网络上，面对“台独”、“疆独”等分裂势力的言论，应旗帜鲜明地予以驳斥；面对“唱衰中国”的谣言，应通过官方信源查证，理性发声，维护国家形象。

七、 避坑指南：普通人守护国家的常见误区与风险

在守护国家的过程中，如果不辨真伪、盲目行动，反而可能落入陷阱，甚至成为破坏力量的帮凶。以下几类“坑”是普通人必须高度警惕的。

1. 意识形态之“坑”：历史虚无主义的伪装

历史虚无主义往往披着华丽的外衣，极具迷惑性。普通人容易踩的坑包括：“秘史”与“戏说”：盲目相信影视剧或自媒体编造的“帝王秘史”、“历史真相”，被其中片面、虚构的情节误导，从而对真实的历史人物（如革命领袖、民族英雄）产生偏见。

碎片化解读：脱离历史背景，孤立地看待历史事件（如只看历史上的失误、错误，而不看主流成就），以偏概全，得出错误的历史结论。

情感宣泄：在网络上参与对特定历史事件的“情绪化审判”，被别有用心的人利用来煽动对党和政府的不满。

2. 经济舆论之“坑”：非理性的焦虑与恐慌

流量焦虑：轻信自媒体制造的“阶层固化”、“经济崩溃”、“弃婴潮”等耸人听闻的标题党文章，陷入非理性的社会焦虑中，甚至影响正常的生育、消费决策。

政策误读：对国家出台的重大改革政策（如“双减”、房地产调控、医疗改革）进行断章取义的解读，将其视为“针对普通人的打击”，从而产生对抗情绪，甚至参与非法的聚集滋事。

3. 行为法律之“坑”：好心办坏事

“义务导游”惹祸

出于爱国热情或炫耀心理，在军事禁区、涉外设施、边境未开放区域等地进行“打卡”拍摄，并上传网络。殊不知，这些画面可能包含敏感的地理坐标、军事部署或设施细节，极易被境外情报机构利用，从而触犯《国家安全法》或《保密法》。

盲目“助人为乐”

在边境地区或出入境时，帮助陌生人携带不明包裹、行李，或者协助其传递信息。这种行为极易被利用进行走私、贩毒或传递涉密载体，导致个人陷入法律泥潭。

八、 结语

“江山”与“社稷”，一头连着国家的尊严与安全，一头连着人民的幸福与未来。从古代的“封土祭神”到今天的“人民至上”，守护的内涵已发生了根本性的变革。

新时代的守护，不再需要所有人都去战场厮杀，而是要求每个人在自己的位置上发光发热。对于普通人而言，守住本心、守好底线、干好本职、传播正气，就是对“江山社稷”最有力的守护。我们既要保持对国家发展的信心，理性辨析舆论迷雾，又要严格遵守法律法规，筑牢国家安全的人民防线。正如无数守护在边疆和一线的英雄们所诠释的那样：“你所站立的地方，就是你的中国；

你怎么样，中国便怎么样。”

2026-08-24 · 建站运维

背景:为什么需要一个对外工单系统

本站点群此前已有禅道(内部项目管理),但对外缺少一个「客户/访客提交问题」的入口。MantisBT(开源缺陷跟踪系统)正好补位:访客无需注册即可匿名提交工单,团队在后台处理,邮件实时通知。2026-08-24 完成安装部署,现正式上线:https://support.1dao.cc

架构总览

安装要点

1. PHP 8.4 兼容性:509 个 PHP 文件语法全过、无隐式可空参数、无需补丁——比此前 CRMEB(128 个文件补丁)省事得多,说明新版开源项目对 PHP 8.4 已友好。
2. vendor 依赖入库:release 压缩包不含 composer 依赖,需 composer install(阿里云镜像)后整体入库——走 walle 部署的 PHP 应用必须如此,部署机不跑 composer。
3. 安装向导自动化:playwright 无头浏览器填写数据库配置,全程脚本化。
4. 默认管理员是 administrator,初始密码 root——上线第一件事改强密码。

配置要点

• 注册 + 匿名双通道:开放注册(邮箱确认激活 + 图像验证码防垃圾),注册用户可跟踪工单收通知;同时保留匿名提交,访客零门槛。
• 中文界面:默认语言 chinese_simplified。
• 邮件通知:163 SMTP(发件显示名 1dao.cc,规避 QQ 邮箱拦截);工单提交时通知报告人/处理人/管理员组。
• 项目:「壹道技术支持」,公开可见。

安全加固

• nginx 锁定 /admin/ 目录(安装脚本 403,升级时临时放开)
• 工单提交 3 次/分钟、登录 10 次/分钟限流(超限 503)
• 配置目录 /config/ 禁止访问;.git/.sql/.bak/.md/.txt 等一律拒绝
• 附件上传禁用危险扩展名(php/html/svg/js/exe 等),附件存数据库、强制下载
• 会话 Cookie Secure+HttpOnly;display_errors/expose_php 关闭;安全响应头齐全

踩坑清单(最有价值的部分)

1. PHP-FPM realpath 缓存:walle 部署切换符号链接后,Worker 进程仍执行旧 release 代码——必须 systemctl reload php8.4-fpm。全站 walle 站点通用坑。
2. 安装向导的 Admin 字段是 MySQL 建库账号,不是应用管理员;库已建好时填应用库账号即可。
3. config/ 目录不存在导致配置写不进:MantisBT 2.28 配置在 config/config_inc.php,需手动建目录并按安装页提示的加密盐手写。
4. 匿名登录 cookie_error:anonymous 用户的 cookie_string 字段为空导致会话校验失败,需生成随机串。
5. walle post_release 多行命令被转 &&:单条失败整链中断,容错用 || true。
6. 管理员邮箱需显式设置,否则收不到工单通知邮件。

使用方式

• 访客:https://support.1dao.cc → 注册账号(邮箱验证激活)后登录提交,可跟踪工单、接收状态通知;或直接匿名提交(免注册)
• 注册流程:登录页「注册一个新帐号」→ 填用户名+邮箱 → 收确认邮件点链接激活 → 设置密码 → 登录
• 管理员:登录后台处理工单、分配、回复、变更状态;邮件实时通知
• 日常维护:改代码走 /root/worksrc/mantis → Gitee → walle 部署;改配置改数据目录 config_inc.php

完整安装实录(含全部命令与回滚方式)见 ccoad1-infra 文档:docs/mantis-v1/install/manual/mantis-install.md

为了给 1dao.cc 站群（主站 / 导航 / 博客 / 商城 / 禅道 / 部署）建立一套与线上完全隔离、版本 1:1 对齐、域名切换零冲突的开发测试环境，我们用一天时间从零完成了整套方案，最终产出一份 7.5 万字、6 卷分册的完整技术文档和 4 条自动化命令。

核心诉求：不碰线上、不改生产配置，一台电脑上完整还原 6 大子系统，同时满足「线上问题 Debug（同域名精准复现）」和「日常开发（浏览器数据隔离）」两种场景。

🎯 核心成果一览

• ✅ 6 大子系统 100% 恢复：主站 / 导航 / 博客（emlog）/ 商城（CRMEB）/ 禅道 / 部署
• ✅ 软件栈 7 组件 1:1 对齐：nginx 1.26.3 · PHP 8.4.24 · MariaDB 11.8 · Redis · certbot 4.0.0
• ✅ 2 种域名模式共存：dev-on/off（同域名 hosts 切换）+ switch-env（子域名解耦）
• ✅ 整站换域名自动化：change-domain 占位符法零误伤；switch-env 快照法双向无损
• ✅ 7.5 万字完整技术文档：EPUB / HTML / Markdown 三格式全交付

🖥️ 环境概览

🔀 双域名模式 · 鱼和熊掌兼得

模式 A · dev-on/off（同域名 hosts 切换 · 线上 Debug）

$ dev-on      # 切测试（弹一次 macOS 密码框）
$ dev-off     # 切回线上
$ which-env   # 随时确认当前指向

模式 B · switch-env（dev.* 子域名 · 日常开发）

$ switch-env dev       # 切子域名模式（快照 + 替换 + 清缓存）
$ switch-env prod      # 切回同域名模式
$ switch-env snapshot  # 保存业务数据变更

⚡ 整站换域名 · 占位符法零误伤

❌ 顺序替换：先 shop.1dao.cc → dev.shop.1dao.cc, 再 1dao.cc → dev.1dao.cc
   结果：dev.shop.1dao.cc 里的 1dao.cc 被再次替换 → shop.dev.1dao.cc！
✅ 占位符法：阶段1 所有旧域名 → @DMNCHG_N_@（唯一占位符）
           阶段2 占位符 → 对应新域名 → 零误伤！

# 预览不执行
$ change-domain 1dao.cc:dev.1dao.cc --dry-run
# 正式替换（数据库 + 代码文件 + 缓存）
$ change-domain 1dao.cc:dev.1dao.cc
# 整站迁移到新域名
$ change-domain 1dao.cc:2dao.cc

📚 7.5 万字技术文档 · 三格式交付

6 卷分册：项目背景 → 软件栈安装 → 域名演变 → 工具开发 → 经验教训 → 原理与排查。

代码与文档仓库：Gitee · huaqidao/ccoad1-infra

💡 踩坑精华 · 6 条血泪经验

1. 永远不要用 .dev 做开发域名：Google TLD，HSTS preload，强制 HTTPS 无解
2. 切 hosts 后用无痕窗口验证：Chrome 有独立 DNS + Socket 缓存，不会立即跟随
3. set -euo pipefail 别乱用在循环脚本：MySQL 视图表报错会让脚本提前退出
4. SQL CONCAT(col, "\t", col) 的 \t 是字面量：直接用 mysql -sN SELECT 多列
5. nginx default_server + return 444 会误伤：未配 443 的子域名被 HSTS 撞上就断
6. 批量替换始终用占位符法：短域名误伤长域名的陷阱，占位符一劳永逸

🖼️ 宣传海报展示 · 3 张

以下为本次项目配套的 3 张宣传海报（项目介绍 / 技术极客 / 成果总结），可直接下载用于微信朋友圈、技术社区、团队内部分享等渠道。

📣 宣传文案合集 · 6 大类

以下是本次项目可直接复用的全套宣传文案，覆盖项目简介、功能卖点、海报标题、渠道文案、Slogan、HashTag，方便多渠道分发。

dev-on       # 线上问题 debug → 同域名模式
switch-env prod
dev-off      # 新功能开发 → 解耦子域名
switch-env dev
    

📎 附件下载汇总 · 共 7 个文件

📦 附件区补充：微信小店商品素材（新增 · 2026-08-22）

随着项目内容的进一步完善，现已补齐「微信小店商品上架」全套素材（共 11 张图 + 1 份完整上架指南 + 38 文件归档包），可直接用于视频号小店 / 微信小程序商城等渠道销售。

📌 下载提示：如需一次性打包获取全部 38 个文件（6.2MB），请进入 wxshop-material-20260821 目录 或下载「素材索引与上传清单.md」对照目录，路径位于虚机 /content/uploadfile/wxshop-material-20260821/（dev-on 模式：blog.1dao.cc；直连 IP：192.168.207.130）。

🤖 本文 AI 生产力实测：TraeWork 积分消耗报告

本文从环境搭建、文档撰写、电子书打包、宣传素材生成到博客发布，全程由 TraeWork（TRAE AI 原生工作台）驱动完成。以下为本次项目的 AI 工作量与积分消耗估算。