OLX的博客

测试

Tue, 30 Jun 2026 00:00:00 GMT

测试

测试2

Tue, 30 Jun 2026 00:00:00 GMT

测试

有些人，注定只能做普通朋友，却偷偷改变了你一生

Wed, 20 May 2026 00:00:00 GMT

有些人，注定只能做普通朋友，却偷偷改变了你一生#

音频：也许从见你的第一面开始，就注定我们只能是普通朋友 / 春风不语人

很多人听《普通朋友》的时候，听到的不是一段关系的结束，而是一种成年人的克制。

明明心里还有位置，嘴上却只能说一句：我们只是普通朋友。

明明很想靠近，却又比谁都清楚，有些人不是不喜欢，而是不适合；不是不遗憾，而是再往前一步，就会变成打扰。

我有一个朋友，很特别。

白天的他，像一个标准的“e人”。

在人群里永远不冷场，会主动接话，会照顾别人的情绪，会开玩笑，会热情大方，会让所有人觉得他很好相处。

可一到晚上，他就像换了一个人。

白天那个开朗的人消失了，取而代之的，是一个敏感、多疑、容易失眠、容易反复想起旧事的“i人”。

他常常在深夜给我发消息。

有时候是一句话：

“你说，她是不是从来没有真正喜欢过我？”

有时候是一张聊天截图。

有时候什么都没有，只是沉默很久，然后说：

“我又梦见她了。”

我一直觉得，真正敏感的人，不是玻璃心，而是感知力太强。

别人随手的一句话，他会记很久。

别人语气里一点点变化，他会反复揣摩。

别人没有回复的消息，他会给自己编出一整晚的答案。

他不是不懂感情，相反，他太懂了。

他经历过双向奔赴，也经历过被人疯狂追求。

所以他比谁都明白：

一个人喜欢你，是藏不住的。

她会主动找你，会分享生活，会在细节里给你回应。

一个人不喜欢你，也是很明显的。

她不会主动靠近，也不会让你进入她的生活。

很多时候，我们不是看不懂答案，只是不愿意承认答案。

他跟那个女生，已经很久没有联系了。

他们最后一次聊天，停留在他发过去的一张照片。

没有争吵，没有告别，没有一句正式的结束。

只是那张照片发出去以后，对话框就安静了下来。

安静到后来，他每次点进去，都像在看一座废弃的城市。

作为“i人”的那一面，他很清醒。

他会告诉自己：

算了吧，忘记她吧。

你们只适合做普通朋友。

可作为“e人”的那一面，他又很不甘心。

他会幻想，有一天她突然想起他，突然重新翻开聊天记录，突然发现原来他一直在原地。

他甚至会想：

如果她能多看我一点，多了解我一点，会不会发现，其实我真的不一样？

可感情最残忍的地方就在这里。

你把对方放进了未来，对方可能只把你放进了某一段路过。

你把她当成故事的主角，她可能只是刚好经过了你的迷茫期。

他说，他做过两个梦。

第一个梦里，他们离得越来越远。

像两个人站在一条很长的路上，他想追过去，却怎么也追不上。

第二个梦里，她身边出现了一个更好的人。

那个人比他更稳定，比他更成熟，也更适合她。

他醒来以后，没有哭，也没有崩溃。

只是突然很难受。

因为有些梦不像梦，更像是内心早就知道的答案，只是借着夜晚告诉你。

他第一次喜欢上那个女生的时候，其实正处在人生很迷茫的阶段。

那时候的他，对生活没什么期待，对未来也没有方向。

每天看起来很热闹，实际上心里空得厉害。

他后来跟我说：

“也许那个时候，我不是非她不可。我只是太需要一个人，把我从那种无所事事的状态里拉出来。”

这句话，我听了很久都没有回。

因为很多感情，最开始并不是爱情本身，而是一个人对生活的求救。

你喜欢上的，可能不只是那个人。

还有她身上的光，她出现时带来的希望，她让你突然想变好的冲动。

他记得第一次见她的样子。

她像是刚从学校出来没多久，身上还带着一种青春的气息。

干净、明亮、松弛，好像没有被生活磨损过。

他被那种气场感染了。

人都是有首因印象的。

第一次让你心动的人，你会自动记住她最好的一面。

她笑起来的样子，她说话的语气，她站在人群里的光，她身上所有你以为特别的东西，都会被你的喜欢不断放大。

直到后来你才明白：

很多念念不忘，其实不是对方真的无可替代。

而是你给她套上了光环。

那里面有冲动，有想象，有见色起意，也有你对更好生活的渴望。

可那一刻的喜欢是真的。

即使不成熟，也是真的。

他曾经对那个女生说过一句话：

“你是我遇见过最特别的人，我愿意将你置顶我的人生。”

女生听完笑了笑，说：

“一般置顶微信不都是爸妈吗？你把爸妈置顶就好了。”

那一瞬间，他也笑了。

可后来他才知道，其实她没有听懂他的意思。

又或者，她听懂了，只是不想接住。

有些话，对方没接住的时候，关系其实就已经有答案了。

他那时候就隐隐感觉到，他们不在同一条路上。

像站在十字路口。

她往左走，他往右走。

没有谁错。

只是方向不同的人，再用力，也很难走到一起。

他说，这段感情对他来说很特别。

特别到哪怕没有结果，他也不后悔。

如果成功了，他也许会更加努力地去追寻幸福，不会再像以前一样，把喜欢的人和喜欢自己的人弄丢。

如果失败了，他也能得到一个目标。

把没有送出去的爱，慢慢转移到自己身上。

让自己变得更好，让生活变得更有方向。

所以他说，那个女生确实是他遇见过很特别的人。

不是因为她有多完美。

而是因为她真的改变了他。

她让他开始认真看待感情。

让他知道，喜欢不是一味靠近，而是要懂得分寸。

让他知道，一个人的热情不能只靠幻想支撑。

也让他知道，人生不能总是无所事事地等一个人回头。

后来，他开始做自己喜欢的事情。

开始规划未来，开始让生活有节奏，开始不再把所有情绪都押在一个人身上。

只是夜晚还是很难熬。

他会失眠，会想她，会反复内耗。

会在某个很安静的瞬间，突然想起他们之间一些很小的画面。

她说过的话，她笑起来的样子，那张没有回复的照片，那句“你把爸妈置顶就好了”。

成年人的遗憾，往往不是轰轰烈烈地失去。

而是你们什么都没有发生，却好像已经错过了一生。

但他也慢慢学会了克制。

以前他以为，喜欢一个人就要拥有。

后来才明白：

有些人来到你的世界，不是为了陪你走到最后，而是为了把你唤醒。

她让你知道自己还会心动。

让你知道自己还有渴望。

让你从麻木的生活里抬起头，看见自己原来还可以成为更好的人。

比起拥有，他后来更在意的是：

她曾经来过。

这就够了。

我们总以为，关系只有在一起才算圆满。

可有些关系，最好的结局就是停在普通朋友的位置。

再近一步是贪心，再退一步是遗憾。

于是只能停在那里。

不打扰，不纠缠，不追问答案。

让那个人继续走她的路，也让自己慢慢走回自己的人生。

我听他说了很多个夜晚。

说实话，最开始我只是一个倾听者。

他用“i人”的敏感，把所有细节拆开给我看。

而我用“e人”的方式陪着他，安慰他，开导他，告诉他别想太多。

可听到后来，我突然发现：

他说的又何尝不是我呢？

我们每个人心里，其实都住着两个人。

一个人清醒地说：算了吧。

另一个人固执地说：再等等吧。

一个人知道对方不属于自己。

另一个人却还在梦里偷偷重逢。

白天，我们都装得很体面。

该工作工作，该社交社交，该笑的时候笑，该说没事的时候说没事。

可到了夜晚，所有被压下去的情绪都会重新浮上来。

你会想起那个没有结局的人。

想起那段没有开始就结束的关系。

想起自己曾经那么认真地喜欢过一个人，却最后只能退回到“普通朋友”。

可人总要长大。

长大的标志，不是再也不想她。

而是想起她的时候，不再冲动地打扰。

不是突然不爱了。

而是终于明白，有些爱只能用来成全自己。

如果有一天，你也遇见过这样一个人。

她没有陪你到最后，却改变了你很多。

她让你失眠，也让你成长。

她让你内耗，也让你开始看见自己的方向。

那就别恨她，也别怪自己。

有些相遇，本来就不是为了结果。

而是为了让你在最迷茫的时候，重新找回那个会心动、会努力、会认真生活的自己。

谢谢她来过。

也谢谢那个曾经认真喜欢过她的自己。

因为正是那段没有结果的喜欢，让你终于懂得：

真正值得置顶的人，不一定是她。

而是那个因为她来过，开始慢慢变好的自己。

原文发布于微信公众号合集《每晚一首歌，聊点成年人不说的话》。

Cloudflare Workers 部署 Cloudflare‑ImgBed 图床完整教程

Thu, 07 May 2026 00:00:00 GMT

Cloudflare Workers 部署 Cloudflare‑ImgBed 图床完整教程#

本文基于官方文档)，从零教你用 Cloudflare Workers 部署专属图床，全程免费、无服务器、支持自动更新。

一、什么是图床？为什么选 Cloudflare‑ImgBed？#

1. 图床是什么#

图床 = 专门存放图片并生成可直接访问的 URL 的服务，用于博客、公众号、文档、笔记，Markdown 等场景，解决图片统一托管、跨平台复用、链接长期有效问题。

2. 为什么选本方案#

零成本：Cloudflare 免费额度足够个人日常使用
无服务器：不用买主机、不用配置环境
全球加速：Cloudflare CDN 全球节点，访问快
数据可控：自己部署、自己管理，不怕第三方图床跑路
多存储：支持 R2、Telegram、D1/KV 数据库
自动部署：GitHub Actions 一键部署 + 自动更新

3. Pages vs Workers（本教程选 Workers）#

可以做ip优选#

二、部署前期准备#

账号准备 - GitHub 账号（用于 Fork 项目、存 Secrets） - Cloudflare 账号（免费注册即可）
必备信息（后面会一步步拿） - Cloudflare Account ID - Cloudflare API Token（权限：编辑 Workers） - KV 或 D1 数据库 ID（二选一） - 可选：R2 存储桶名、Telegram 机器人信息
工具浏览器即可，无需本地环境、无需终端。

三、完整部署步骤（按顺序做）#

一步：Fork 开源项目

打开官方项目：CloudFlare ImgBed
点右上角 Fork → 选择你的 GitHub 账号 → 等待 Fork 完成。

第二步：准备 Cloudflare 资源#

2.1 获取 Account ID + API Token#

登录 Cloudflare Dashboard
右上角头像 → 我的个人资料 → API 令牌
创建令牌 → 选模板 编辑 Cloudflare Workers → 下一步 → 创建令牌
复制并保存生成的 API Token（只出现一次）
返回 Dashboard 首页，右侧找到并复制 Account ID。

2.2 创建数据库（KV 或 D1 二选一）#

方案 A：KV 数据库（读写更快）#

存储和数据库 → Workers KV → 创建实例
名称填 img_url → 创建
复制 命名空间 ID

方案 B：D1 数据库（免费额度更高）#

存储和数据库 → D1 SQL 数据库 → 创建数据库
名称填 img_d1 → 创建
复制 数据库 ID
进入「控制台」执行项目提供的 init.sql 初始化语句

2.3（可选）创建 R2 存储桶#

存储和数据库 → R2 对象存储 → 创建存储桶
自定义名称，复制保存 存储桶名称

第三步：配置 GitHub Secrets（关键）#

进入你 Fork 的仓库
Settings → Secrets and variables → Actions → New repository secret
按表添加，必填项必须填，二选一填一个即可

Secret 名称	说明	是否必填
CLOUDFLARE_API_TOKEN	Cloudflare API 令牌	✅ 必填
CLOUDFLARE_ACCOUNT_ID	Cloudflare 账户 ID	✅ 必填
KV_NAMESPACE_ID	KV 命名空间 ID	KV/D1 二选一
D1_DATABASE_ID	D1 数据库 ID	KV/D1 二选一
R2_BUCKET_NAME	R2 存储桶名	可选
WORKER_NAME	Worker 名称（默认 cloudflare-imgbed）	可选
WORKER_VARS	业务变量（JSON 格式，如 TG 配置）	可选

安全提醒：一律用 Secrets，不要用 Variables（公开可见）。

第四步：运行部署（手动 / 自动二选一）#

方式 1：手动触发部署#

进入仓库 Actions 页面
左侧选择 Deploy to Cloudflare Workers
点 Run workflow
分支选 main → 直接 Run workflow
等待执行成功（约 1–3 分钟）

方式 2：开启自动部署（推荐）#

Actions 页面找到 Upstream Sync
点 Enable workflow
以后上游更新 → 自动同步 main → 自动部署，全程不用管

四、部署成功 ; 访问使用#

访问地址：“
部署后必须配置存储渠道（R2/Telegram 等）才能上传图片，在后台管理面板配置即可。

五、后续更新维护#

1. 自动更新（推荐）#

保持 Upstream Sync 开启，上游更新自动同步并部署。

2. 手动更新#

仓库点 Sync fork 同步上游
触发自动部署；或手动再跑一次 Deploy workflow。

六、常见问题#

部署失败：检查 Secrets 是否填错、权限是否正确
无法上传：未配置存储渠道，去后台绑定 R2 或 Telegram
链接打不开：确认 Worker 已启用、名称与子域名拼写正确

七、总结#

用 Cloudflare Workers 部署图床，全程免费、无服务器、10 分钟搞定，适合个人长期稳定使用。按本文步骤：Fork → 拿 Cloudflare 信息 → 配 GitHub Secrets → 一键部署，即可拥有专属高速图床。

我以为我们有以后，原来只是我一个人在计划

Thu, 07 May 2026 00:00:00 GMT

我以为我们有以后，原来只是我一个人在计划#

音频：原来我一直没在你的计划里 / 春风不语人

“是不是一开始就没出现在你的计划里。”

有时候，一句歌词最伤人的地方，不是它写得多苦。

而是你听着听着，突然就安静了。

因为你发现，它像一把很钝的刀，慢慢划开了你一直不肯承认的那层心事。

你后来最难过的，不是他走了。

也不是你们真的散了。

而是某个深夜，你一个人坐着，反反复复想起这句话的时候，终于意识到：

原来你曾经那么认真地把他放进未来。

认真地想过以后。

认真地信过“我们”。

可到最后，真正把这段关系当成未来的人，好像从头到尾，只有你一个。

那种感觉，不是一下子崩掉的。

不是突然失去。

不是一句分手就能概括的疼。

而是你终于承认：

你拼命护着的，不只是一个人，

还有那份你曾经深信不疑的以后。

可偏偏，感情里最狠的地方就在这里。

你还守着从前，

他已经在慢慢退场。

你还在认真修补，

他已经在权衡值不值得继续。

你还把他写进未来，

他却早就没有把你放进计划里。

所以后来你才懂，很多关系，不是败给不爱。

是败给了人性里最凉的一面：

越容易得到的人，越容易被轻视。

越舍不得离开的人，越容易被辜负。

越一次次原谅的人，越容易被耗到最后。

而你最疼的，不是他不爱了。

是他明明知道你认真，知道你舍不得，知道你一次次嘴上说算了，心里其实根本放不下，

却还是一点一点地冷淡你，一点一点地消耗你，一点一点地让你明白：

你在他那里，已经没有那么重要了。

真正让人崩溃的东西，往往都不是突然来的。

不是某一天醒来，他就彻底变了。

不是某一次争吵，就把所有爱都吵没了。

不是一句“我累了”，就能解释后来所有的冷淡。

真正把人磨碎的，都是那些很轻、很慢、很安静的瞬间。

是你给他发消息，屏幕亮了又灭，灭了又亮。

你拿起手机很多次，以为是他，最后发现都不是。

是你半夜两点还醒着，盯着那段停在“嗯”“好的”“你早点睡吧”的聊天记录，一遍遍翻，一遍遍告诉自己别多想。

是你明明已经很难过了，却还是不敢问得太直接，怕一开口，就显得自己太黏、太烦、太不懂事。

以前不是这样的。

以前你随口说一句“今天有点累”，他会追着问你怎么了。

以前你情绪不对，他会第一个察觉。

以前你们聊到很晚，他舍不得结束，连一句晚安都要来来回回说很多遍。

以前你说难过，他会紧张。

以前你沉默，他会在意。

可后来，一切都变得很敷衍。

你发很长一段，他回一个“嗯”。

你认真说感受，他说“你别想太多”。

你难得鼓起勇气问他：“你是不是没那么在乎我了？”

他沉默了很久，最后只回你一句：“你怎么总是这样。”

那句话真的很轻。

轻得像什么都没发生。

可只有你知道，那一刻你心里像塌下去一块。

因为你终于意识到，真正让你难过的，不是他回得慢。

而是他明明知道你为什么难过，却已经懒得认真哄你了。

有些人不是后来才变冷淡。

是从他发现你舍不得走的那一天起，就开始慢慢失去分寸。

后来你回头看，才发现自己在这段关系里，输得最早的那一刻，不是他冷下来。

而是你太早让他知道：

你离不开他。

每次闹别扭，先低头的是你。

每次冷战，先找话题的是你。

每次关系摇摇欲坠，先伸手去拉回来的人，还是你。

你太害怕失去他了。

所以你不敢闹得太僵。

不敢把委屈说得太满。

不敢真的转身。

哪怕他已经让你失望过很多次，你还是会替他解释：

他只是累了。

他只是最近压力大。

他只是不太会表达。

他不是故意的。

可你后来才懂，很多伤害，真的不是误会。

不是他不知道你有多在乎。

不是他没看见你一次次委屈。

不是他不明白你每次沉默背后，都藏着失望。

他都知道。

他只是慢慢习惯了你的让步。

习惯了你的原谅。

习惯了你无论多难过，最后都还是会回来。

于是你的懂事，变成了他的底气。

你的心软，变成了他的资格。

你的深情，最后被他活活用成了一种理所当然。

这才是感情里最残忍的地方。

不是你不够好。

恰恰是因为你太好，太能忍，太会体谅，太舍不得，

所以他才越来越不害怕失去你。

感情里最可怕的，不是被辜负一次。

而是他发现，反复辜负你，好像也没什么后果。

他知道你会难过。

也知道你不会轻易走。

所以他可以一次次地冷，一次次地淡，一次次地让你失望。

反正到最后，先回头的人，还是你。

于是你越认真，他越笃定。

你越舍不得，他越不害怕。

你越把他放进未来，他越忘了，原来自己也该认真一点。

其实后来你们真正分开的时候，你反而没那么震惊。

因为在那之前，他早就已经在慢慢离开了。

先是消息越来越少。

再是耐心越来越少。

再后来，是连你的情绪，他都懒得接了。

你能感觉到的。

你能感觉到他不再像从前那样期待和你聊天。

能感觉到你不再是他第一时间想起的人。

能感觉到他对你说话的语气越来越淡，越来越省，越来越像在完成一件并不想做的事。

最难熬的是，你还不能立刻死心。

因为他没有真的做错什么大事。

没有明确背叛。

没有狠到一下子把你推开。

他只是冷一点，慢一点，少一点。

少一点在乎。

少一点耐心。

少一点解释。

少一点你以为会一直有的偏爱。

可就是这种“少一点”，最磨人。

它不会让你立刻崩溃。

它只会让你在一天天的相处里，一点点确认：

原来自己正在被放轻。

原来你拼命护着的感情，在他那里，已经没那么值得被认真对待了。

你最疼的那一刻，不是发现他不爱你了。

而是发现他一边享受你的好，一边已经在适应没有你的日子。

你还在想怎么修补。

他已经在权衡值不值得继续。

你还在因为他一句冷淡失眠到天亮。

他却已经把情绪、耐心、热情，分给了别的事，别的人，别的新鲜感。

那种感觉，就像你还站在原地守着一扇门，

以为门后还有回应。

可后来你才发现，屋里的人早就不想再给你开门了。

真正刺痛人的，不是离开。

是他明明还站在你身边，却已经开始把你当成可有可无。

人真正心死的时候，不是吵得最凶的时候。

而是某一天，你突然不想再替他解释了。

你不再告诉自己，他只是太累了。

不再告诉自己，他只是不会表达。

不再告诉自己，再熬一熬，也许就会回到从前。

因为你终于承认：

很多冷淡，不是无意。

很多敷衍，不是没看见。

很多让你整夜整夜睡不着的委屈，也不是你太敏感。

是他真的没那么在乎了。

而最疼的，就是这一点。

不是他十恶不赦。

不是他做了多么惊天动地的错事。

而是他明明知道你认真，知道你心软，知道你一次次退让背后藏着多少不甘，

却还是用一种最轻、最淡、最无所谓的方式，慢慢消耗你。

后来你才懂，感情里最狠的真相，从来不是“他不爱你”。

而是——

他明明知道你有多爱他，却还是选择那样对你。

这句话，比分开更疼。

因为它撕开的不是遗憾，

是人性。

你终于承认，自己拼命护着的那段感情，从一开始就不对等。

你在认真爱。

他在习惯被爱。

你在拼命维系。

他在慢慢抽身。

你把很多轻视熬成沉默，

把很多失望咽回肚子里，

最后才终于敢承认：

原来你不是输给了爱情，

你只是输给了人性里，对廉价得到的不珍惜。

原来最让人难堪的，不是爱错了人。

而是明明已经被轻视了很久，你还是舍不得承认，他没有你想象中那么爱你。

后来你终于不再等了。

不再守着手机。

不再反复翻聊天记录。

不再因为他偶尔一点点温柔，就把所有委屈都忘掉。

也不再因为他一句冷淡，就怀疑自己是不是不够好。

因为你终于明白，问题从来不是你给得不够多。

而是你给得太多了。

多到他忘了珍惜。

多到他以为你永远不会走。

多到他把你的真心，当成了一种不会失去的东西。

可人总有疼醒的时候。

你后来终于承认，很多时候，你不是舍不得那个人。

你只是舍不得自己曾经那么认真。

舍不得那个一边掉眼泪，一边还在替别人圆谎的自己。

舍不得那个明明已经被伤得很深，却还是不肯承认对方没那么在乎的自己。

舍不得那个曾经真的以为，你会和他有以后的人。

可幸好，最后你还是醒了。

你终于明白：

有些人失去你，不是遗憾。

不是可惜。

也不是错过了一个普通的人。

他失去的，是一个曾经把真心捧到他面前、被他反复轻视过、却还是认真爱过他的人。

这样的人，失去你，

不是他难过得不够多。

是他活该。

因为你后来终于明白，

不是所有出现在生命里的人，都配得上被你写进未来。

也不是所有说过“以后”的人，都会真的陪你走到以后。

而一个明明知道你认真、知道你深情、知道你舍不得，

却还是一点一点把你弄丢的人，

他失去你，从来都不是你的遗憾。

那是他的损失。

也是他的报应。

写在最后

后来你才明白，感情里最狠的，从来不是分开。

而是他明明知道你舍不得，知道你认真，知道你会疼，

却还是一点一点地轻视你、冷淡你、消耗你。

很多时候，你不是输给了爱情。

你只是输给了人性里，对轻易得到的不珍惜。

而最疼的那句真相，也许早就藏在那句歌词里了：

“是不是一开始就没出现在你的计划里。”

原文发布于微信公众号合集《每晚一首歌，聊点成年人不说的话》。

爱情里最清醒的答案，藏在《达尔文》里

Tue, 05 May 2026 00:00:00 GMT

爱情里最清醒的答案，藏在《达尔文》里#

音频：感情中也需要不断进化的两个人 / 春风不语人

“进化成更好的人。”

这句歌词响起来的时候，我总会想到一对很普通的情侣。

他们的爱情没有惊天动地的开场，也没有什么命运般的重逢，甚至连认识的方式，都普通得像每天都会发生在城市里的一个小插曲。

故事开始于一个早高峰的地铁口。

女生叫温梨，是一家装修公司的软装设计师。每天背着电脑包、样板册和一堆布料色卡，在城市里跑来跑去。

男生叫许川，是一家医疗器械公司的售后工程师。经常拎着工具箱去医院检修设备，衣服口袋里永远放着螺丝刀、数据线和一小包创可贴。

他们第一次见面，是因为温梨在地铁站扶梯口摔了一跤。

那天她赶着去见客户，左手抱着方案图纸，右手拎着咖啡，鞋跟卡在扶梯缝边，整个人差点往前扑。

许川刚好站在她后面，下意识扶了她一把。

咖啡洒了他半只袖子，温梨尴尬得脸都红了，连声道歉。

许川低头看了一眼袖口，只说了一句：

“没事，反正我今天也要去医院，白大褂比我干净。”

温梨被他逗笑了。

他们就这样认识了。

后来温梨说，她喜欢许川，是从那一刻开始的。

不是因为他有多帅，也不是因为他多会说话，而是因为那天早上所有人都在急着赶路，只有他停下来扶了她一把。

成年人心动，有时候真的很简单。

不是玫瑰，不是情话，是你狼狈的时候，有个人刚好没有嫌你麻烦。

刚在一起时，他们像两块刚好拼上的拼图。

温梨浪漫，许川踏实。

温梨喜欢把生活过得有仪式感，周末会买鲜花，会换香薰，会把出租屋的小阳台布置成一个小小的下午茶角。

许川不太会浪漫，但很会照顾人。

灯泡坏了，他修。

下水道堵了，他通。

温梨加班到很晚，他就骑着电动车去接她，后座放着一杯还温着的豆浆。

有一次温梨发朋友圈：

“他不会说很多好听的话，但他会在我说灯坏了的十分钟后，带着工具箱出现在门口。”

朋友都在下面评论：这不就是理想型吗？

那时候温梨也觉得，自己遇到了对的人。

许川也觉得，温梨是那个能把他平淡生活点亮的人。

她会拉着他去看展，去逛旧书市，去吃那些藏在巷子里的小店。

她会在他生日那天，把出租屋客厅装成一个小型星空影院。投影仪一开，墙上全是流动的银河。

许川坐在沙发上，看着她忙前忙后，心里忽然觉得：

原来生活不只是上班、下班、还房租、攒钱。

原来一个人真的可以让日子变得有光。

刚相爱的时候，他们都觉得对方很好。

温梨觉得许川稳定。

许川觉得温梨鲜活。

可后来他们才明白，关系里最初吸引你的东西，也可能会在生活里慢慢变成考验。

你喜欢他的稳定，后来可能会嫌他不懂浪漫。

你喜欢她的鲜活，后来也可能会觉得她太不现实。

爱情最难的不是遇见。

而是遇见之后，能不能在真实的生活里，继续适应彼此。

真正的矛盾，是从同居开始的。

温梨喜欢把家布置得好看。

她会买漂亮的餐盘、复古台灯、白色纱帘，还会在网上收藏各种家居灵感。

许川更在意实用。

他觉得一个杯子能喝水就行，一盏灯能照明就够，一张桌子稳当比好看更重要。

刚开始他们只是开玩笑。

温梨说：“你这个人一点审美都没有。”

许川笑着回：“我有你就行了。”

可日子久了，玩笑慢慢变成刺。

有一次，温梨花八百多买了一把中古椅子。

椅子送到家的时候，许川正好下班回来。

他看了一眼价格，眉头立刻皱起来：

“八百多买一把旧椅子？”

温梨正在拆包装，听到这句话，手停了一下。

她说：“这是中古，不是破烂。”

许川脱下外套，语气有点重：

“我们下个月还要交房租，你上次说想报课，这个月又买椅子。你有没有想过以后？”

温梨心里一下就凉了。

她不是不知道钱重要。

她只是觉得，自己辛苦工作，偶尔买一件喜欢的东西，不应该被说成不懂生活。

那天晚上，他们吵得很厉害。

许川觉得温梨花钱太感性。

温梨觉得许川总是用“以后”压她。

许川说：“我是在为我们考虑。”

温梨说：“可你考虑的未来里，好像没有我的感受。”

这句话说完，屋子里安静了很久。

那把椅子就放在客厅中央，像一个忽然出现的证据，证明他们的生活方式并没有想象中那么合拍。

后来类似的事越来越多。

温梨想辞职去做独立设计。

许川第一反应是风险太大。

许川想攒钱买房。

温梨觉得不能为了买房把生活过成一张还款计划表。

温梨周末想去看展。

许川只想在家补觉。

许川下班后累到不想说话。

温梨却觉得他越来越冷淡。

你看，爱情进入生活以后，真正筛选两个人的，从来不是多大的风浪。

而是这些小事。

钱怎么花。

家怎么过。

情绪怎么接。

未来怎么走。

两个人要不要为彼此调整一点点。

许川有个习惯。

一遇到矛盾，他就讲道理。

温梨说：“我今天很委屈。”

他说：“你先别情绪化，我们把问题说清楚。”

温梨说：“我只是想让你理解我。”

他说：“理解不能解决问题。”

温梨每次听到这句话，都觉得心里像被关了一扇门。

她不是不想解决问题。

她只是希望，在解决问题之前，他先看见她这个人。

而温梨也有自己的问题。

她太希望许川能懂她。

很多话她不直接说，却希望他能猜到。

她嘴上说“随便”，心里却希望他坚持问。

她说“我没事”，其实想听他说“我知道你有事”。

她把很多失望藏起来，等到攒够了，就一次性爆发。

许川觉得莫名其妙。

温梨觉得他不在乎。

他们就像两个人站在同一间屋子里，一个说普通话，一个说方言。

都在表达爱，却谁也没有真正听懂谁。

最严重的一次，是温梨接了一个很重要的项目。

客户要求很高，她连续熬了十几天，方案改了七版。

最终提案那天，她紧张到手心出汗。

她提前跟许川说：“你今晚能不能早点回来？我想跟你说说今天的事。”

许川答应了。

可那天医院设备临时故障，他一直忙到晚上十一点。

等他回到家，温梨已经坐在沙发上睡着了。

电脑还开着，页面停在方案结尾那一页。

桌上放着两碗已经坨掉的面。

许川轻轻叫醒她：“我回来了。”

温梨睁开眼，看了他几秒，只说：

“面凉了。”

许川解释：“今天真的走不开。”

温梨点点头：“我知道。”

她越平静，许川越慌。

他说：“你别这样。”

温梨看着他，声音很轻：

“许川，我不是怪你忙。我只是突然觉得，我人生里那些很需要被分享的时刻，你好像总是缺席。”

这句话，让许川愣住了。

他一直以为，自己在努力赚钱、努力稳定、努力给未来，就是爱。

可他忘了，爱情不只是未来。

爱情也是当下。

是她累到崩溃时，你能不能听她说十分钟话。

是她取得一点成绩时，你能不能认真为她高兴。

是她站在人生某个重要节点时，你不是永远说“我在忙”，而是尽力让她感受到“我在”。

那天之后，他们没有立刻分开。

但温梨明显变安静了。

她不再分享那些琐碎的小事。

客户夸她，她不说。

路边买到好吃的糖炒栗子，她不说。

看见一盏很漂亮的灯，她也只是拍下来，默默存进相册。

许川终于发现，一个人真正失望的时候，不是大吵大闹。

而是她开始把原本想分享给你的生活，慢慢收回去。

后来，事情出现转机，是因为一次搬家。

房东突然通知房子不续租，他们不得不在一个月内找新住处。

找房那段时间，两个人几乎每天都在争执。

许川看重通勤和价格。

温梨看重采光和生活感。

许川觉得：“房子只是睡觉的地方。”

温梨反问：“那生活呢？生活也只是活着吗？”

有一天，他们去看一套老小区。

房子不大，但窗外有一棵很高的香樟树。

下午阳光照进来，地板上有树影晃动。

温梨几乎一眼就喜欢上了。

许川却站在厨房里检查水压、电路和墙角渗水。

中介在旁边催：“这套很抢手，今天不定可能就没了。”

温梨看着许川，眼里有期待。

许川看着房子，脑子里全是预算。

就在那一刻，他忽然想起了他们争吵过的很多瞬间。

想起那把中古椅子。

想起那两碗凉掉的面。

想起温梨说：“你考虑的未来里，好像没有我的感受。”

他沉默了一会儿，对中介说：“我们再看一下阳台。”

阳台很小，但能放下两张椅子。

温梨站在那里说：“这里可以种薄荷，也可以放一盏落地灯，晚上我们可以坐在这里吹风。”

以前的许川，大概会立刻计算这些东西要花多少钱。

但那天他没有。

他只是问：“那灯你选，我负责装。”

温梨怔了一下。

就这么一句话，她眼眶忽然红了。

因为她听出来了。

许川不是突然变得多浪漫。

而是他终于愿意进入她的世界，哪怕只是一小步。

他们最后租下了那套房子。

搬家那天，许川把那把曾经引发争吵的中古椅子搬上楼。

椅子很重，他一个人扛到三楼，累得满头是汗。

温梨站在门口看着他，忍不住说：“你不是一直嫌它贵吗？”

许川喘着气说：

“贵是贵，但你坐在上面改方案的时候，确实挺好看的。”

温梨笑了。

那一刻，他们都知道，有些问题不是一夜之间解决的。

但关系开始往好的方向走了。

不是因为谁彻底妥协。

而是两个人终于开始明白：

爱情里的进化，不是把对方变成自己想要的人。

而是你愿意把自己的世界，打开一点给对方。

搬进新家后，他们做了一件很有意思的事。

温梨在冰箱上贴了一张纸，写着：

共同进化清单。

第一条：吵架时不能说“随便”“算了”“你爱怎么想怎么想”。

第二条：忙的时候要提前说，不要让对方一直等。

第三条：花大钱之前一起商量，但不能嘲笑对方的热爱。

第四条：每周留一个晚上，不谈工作，不刷手机，只吃饭聊天。

第五条：谁情绪不好，另一个人先拥抱，再讲道理。

许川看到第五条，皱了皱眉：“拥抱能解决问题吗？”

温梨看着他：“不能，但能先解决我想哭的问题。”

许川沉默两秒，把这条圈了起来：“重点执行。”

他们当然没有马上变成模范情侣。

许川还是会忙到忘记回消息。

温梨还是会偶尔因为一句话想太多。

但不一样的是，他们开始学着提醒自己。

有一次温梨因为客户临时改需求，在家里发脾气。

许川刚想说：“你先冷静一点。”

话到嘴边，他停住了。

然后他走过去，抱了她一下，说：

“我知道你现在很烦。你先骂客户，骂完我帮你一起看方案。”

温梨本来很想哭，听到这句话又笑了。

还有一次，许川因为工作压力大，连续几天都很沉默。

以前温梨一定会觉得他不爱自己了。

但那一次，她没有追问。

她只是给他煮了一碗面，坐在旁边说：

“你不想说也没关系。我在这里，不是来审问你的。”

许川低头吃面，吃着吃着，眼眶红了。

他说：“我最近真的有点撑不住。”

那是温梨第一次听见许川这样表达脆弱。

她才明白，原来那个总是看起来很稳的人，也会害怕，也会累，也会需要被接住。

好的爱情就是这样。

它不会让你越来越极端，越来越敏感，越来越不像自己。

它会让你慢慢学会表达，学会倾听，学会把刺收起来，把手伸出去。

你变得更柔软。

他变得更坦诚。

你学会不再用情绪试探。

他学会不再用沉默逃避。

这不是谁改造了谁。

这是两个人在关系里，一起进化。

后来温梨的独立设计工作室真的开起来了。

刚开始很难。

收入不稳定，客户也不稳定。

有几个月，她赚的钱还不如上班时的一半。

如果是以前，许川一定会劝她回去找份稳定工作。

但这一次，他没有急着否定。

他帮她做预算表，帮她整理客户资料，帮她把家里的小房间改成工作区。

温梨也开始改变。

她不再只凭热情做决定。

她开始认真记账，规划现金流，给自己设置试错期限。

许川对她说：“你看，你也开始讲计划了。”

温梨笑着回：“你不也开始讲感受了吗？”

他们都变了。

却不是变成了对方。

而是从对方身上，长出了一部分更好的自己。

这大概就是《达尔文》里最清醒的爱情答案。

爱情不是谁天生适合谁。

爱情也不是遇到问题就换人。

当然，不合适的人要筛掉，消耗你的关系要离开，不值得的人不要强留。

但真正值得珍惜的关系，是你们在发现问题之后，不是互相指责，而是愿意一起升级。

有人筛掉的是不合适的伴侣。

有人筛掉的是自己身上的坏习惯。

有人筛掉的是不成熟的表达方式。

有人筛掉的是对爱情不切实际的幻想。

最后留下来的，才是真正能长久的爱。

它不是永远热烈。

但它稳定。

它不是没有矛盾。

但它愿意沟通。

它不是从不改变。

而是两个人都愿意为了更好的未来，进化成更好的人。

有一年冬天，温梨和许川在新家的阳台上吃火锅。

外面很冷，窗户上起了一层薄薄的雾。

那盏落地灯亮着，薄荷长得很好，那把中古椅子放在角落里，上面搭着许川的外套。

温梨忽然说：“你有没有发现，我们现在和刚在一起的时候不一样了？”

许川夹了一片牛肉，想了想说：

“刚开始是喜欢对方身上自己没有的东西。后来是被这些东西折磨。现在是学会和这些东西一起生活。”

温梨笑了：“你现在说话越来越像我了。”

许川也笑：“你现在做预算越来越像我了。”

他们没有说什么永远。

但那个瞬间，温梨突然觉得很安心。

因为她知道，真正能让两个人走下去的，不是某一次盛大的浪漫，也不是某一句漂亮的承诺。

而是在无数个普通的日子里，他们都没有放弃学习怎么爱对方。

爱情不是静止的。

人会变，生活会变，压力会变，需求也会变。

如果两个人都停在原地，再深的喜欢也会慢慢被现实磨薄。

可如果两个人都愿意成长，愿意调整，愿意在一次次矛盾后变得更懂彼此，那这段关系就会在时间里长出新的生命力。

所以，爱一个人最好的方式，从来不是把自己低到尘埃里。

也不是要求对方完全按照你的方式生活。

而是你们在彼此身边，都能慢慢成为更好的人。

你没有因为爱他变得委屈。

他也没有因为爱你失去自己。

你们一起筛掉坏脾气，筛掉冷暴力，筛掉不沟通，筛掉那些“我本来就是这样”的固执。

然后在很普通的一天里突然发现：

原来我们真的比以前更好了。

也原来，真正好的爱情，不是找到一个完美的人。

而是两个普通的人，在一地鸡毛的生活里，依然愿意牵着手，慢慢进化成更适合彼此的人。

这就是《达尔文》最清醒的地方。

爱情会筛选人。

生活会筛选人。

时间也会筛选人。

但最后留下来的那个人，一定不是让你退化的人。

而是那个陪你一起，进化成更好的人。

原文发布于微信公众号合集《每晚一首歌，聊点成年人不说的话》。

原来真正的偏爱，是你对别人都很好，却只对我不一样

Mon, 04 May 2026 00:00:00 GMT

原来真正的偏爱，是你对别人都很好，却只对我不一样#

音频：茫茫人海，我只偏爱你一人 / 春风不语人

张芸京的《偏爱》一响起来，最先冲出来的，不是温柔。

而是一种很倔的坚定。

像是一个人明知道前面有很多不确定，明知道爱一个人可能会受伤，明知道这份感情未必有结果，可他还是不想后退。

他不是没看见别人。

他只是看见了很多人以后，还是偏偏选择了你。

所以后来我们才懂，《偏爱》真正打动人的地方，不是“我有多喜欢你”，而是那种近乎固执的偏心。

别人可以被照顾。

但你会被我放在心上。

别人可以被礼貌对待。

但你会被我认真偏向。

别人可以得到我的好。

但你得到的，是我藏不住的例外。

感情里最容易让人误会的，就是“他对我很好”。

因为有些人本来就温柔，本来就周到，本来就会照顾身边所有人的情绪。

他会给所有人递纸巾，会替所有人解围，会对所有人说“路上小心”。

可真正的偏爱，不是他对别人不好。

而是他对所有人都好，却唯独对你，格外不同。

他对别人是顺手。

对你，是特意。

他对别人是礼貌。

对你，是心疼。

他对别人是照顾。

对你，是下意识的偏心。

后来许知南才明白：

一个人让你心动的，从来不是他有多会照顾人。

而是他明明可以把温柔平均分给所有人，却偏偏把最细的那一份，留给了你。

许知南以前喜欢过一个男生。

那个男生人很好。

朋友聚会，他会主动买单；同事加班，他会顺手带咖啡；谁遇到麻烦，他都会过去帮一把。

所有人都说：“他真的很温柔，跟他在一起一定很幸福吧。”

一开始，许知南也是这么觉得的。

她以为，自己终于遇到了一个情绪稳定、会照顾人的人。

可后来她才发现，一个人对所有人都好，并不代表你在他心里特别。

她生日那天，男生答应陪她吃饭。

她提前订好了餐厅，化了很久的妆，还特意穿了那条一直舍不得穿的裙子。

临出门前，男生打来电话，说朋友失恋了，状态很差，他要先过去陪一下。

许知南站在镜子前，手里还拿着口红。

她沉默了几秒，只回了一句：

“没事，你去吧。”

那晚，她一个人坐在餐厅靠窗的位置。

服务员问她：“小姐，还需要等人吗？”

她笑着说：“不用了，先上菜吧。”

菜一道一道端上来，她却没什么胃口。

手机亮了一下，是男生发来的消息：

“你别多想，我只是看他真的很难受。”

许知南看着那句话，忽然觉得很委屈。

她不是怪他善良。

她只是突然明白，自己好像从来不是那个会被优先选择的人。

感情里最难受的，不是他对你不好。

而是他对所有人都很好，所以你连难过都显得小气。

后来，许知南遇见陈序，是在一次朋友饭局上。

陈序也是那种大家都觉得很好的人。

谁杯子空了，他会顺手倒水；谁找不到话题，他会自然接话；有人尴尬，他会帮忙圆场；聚会结束，他也会提醒所有人注意安全。

许知南一开始没有多想。

她甚至在心里提醒自己：

别再把一个人的礼貌，误会成特别。

那天吃火锅，大家都说点辣锅才热闹。

许知南胃不好，其实不能吃太辣，但她没有开口。

她太习惯照顾场面，也太怕自己扫兴。

锅底端上来后，她夹了一片毛肚，刚放进嘴里，辣意就呛得她眼眶发红。

她赶紧低头喝水，假装没事。

桌上大家还在聊天，没有人注意。

只有陈序忽然按了服务铃。

他说：“再加一个番茄锅吧。”

朋友笑他：“你什么时候这么养生了？”

陈序没解释，只是把菜单往许知南那边推了推：

“有人不能吃辣。”

许知南愣了一下。

她明明什么都没说。

可他看见了。

那一刻，她第一次觉得，偏爱不是多轰轰烈烈。

偏爱是明明一桌子人都很热闹，可他偏偏能在人群里，先看见你的不舒服。

后来他们慢慢熟起来。

许知南发现，陈序确实对很多人都不错。

同事电脑坏了，他会帮忙看；朋友搬家，他会去搭把手；聚会散场，他也会提醒大家到家说一声。

可他对许知南的好，又是不一样的。

不是更夸张，而是更细。

有一次，许知南加班到很晚，随手发了一条朋友圈：

“今天好想喝热豆浆。”

她只是随口一说。

半小时后，她从公司楼下出来，看见陈序站在路边。

夜风很冷，他穿着黑色外套，手里拎着一杯热豆浆，还有一袋她喜欢吃的红豆饼。

许知南怔住：“你怎么来了？”

陈序说：“顺路。”

可她知道，他家根本不顺这条路。

她接过豆浆的时候，杯壁还是烫的。

那一瞬间，她忽然有点想哭。

人这一生，其实听过很多客套的关心。

“多喝热水。”

“早点休息。”

“别太累。”

这些话都没错。

可真正让人心动的，是有人把你的随口一说，当成他的特意去做。

对别人，他是顺手。

对你，他是上心。

这就是偏爱。

许知南真正动心，是因为一次工作上的委屈。

那次项目临时出问题，客户把责任推到她身上。

会议室里气氛很僵，所有人都沉默。

许知南坐在那里，手指紧紧攥着笔。

她已经准备开口道歉了。

因为她太熟悉这种场面了。

只要有人不高兴，她就会下意识先让步。

只要气氛难看，她就会先把错揽到自己身上。

可陈序突然把电脑转过去，一条一条打开沟通记录。

他说：

“需求是你们确认过的，修改时间也是你们临时压缩的，这个责任不该让她一个人背。”

客户脸色不太好。

旁边有人小声劝：“算了，别把场面弄僵。”

陈序却很平静：

“可以解决问题，但不能随便让一个认真做事的人受委屈。”

许知南坐在旁边，眼眶一下就红了。

她不是没有被安慰过。

可是那些安慰，常常是在事情结束后，别人轻飘飘地说一句：“别往心里去。”

只有陈序，是在她快被推出来承担所有指责的时候，站到了她身边。

偏爱不是事后哄你两句。

偏爱是别人都劝你忍一忍的时候，他偏要替你认真一次。

在一起之后，许知南有过一段时间的不安。

因为陈序依然对人很好。

他会帮同事改方案，会送朋友去车站，会在聚会里照顾每一个人的感受。

许知南不是不懂事。

她只是害怕。

害怕自己又一次把普通的好，误会成了偏爱。

直到有一天，她无意间看见陈序手机备忘录里，记着很多很小的事。

“知南不吃香菜。”

“知南胃不好，少点冰。”

“下雨天她膝盖会疼。”

“她喜欢靠窗的位置。”

“她不开心时，不喜欢被追问，要先陪着。”

那一瞬间，许知南突然说不出话。

原来他对别人好，是因为教养。

可对她好，是因为爱。

别人需要帮助，他会伸手。

可她的喜好、情绪、习惯、脆弱，他都一件一件记了下来。

那天晚上，她问陈序：

“你是不是对谁都这么好？”

陈序看着她，笑了一下：

“我可以对别人都好，但我只会把你的事记这么清楚。”

许知南忽然就安心了。

因为偏爱最明显的地方，从来不是他对别人冷漠。

而是他对所有人都温柔，却只对你格外认真。

后来，许知南生日那天，陈序原本在外地出差。

她没提醒他。

因为她太怕期待落空。

晚上十点多，她一个人煮了一碗面，刚准备吃，门铃响了。

她打开门，看见陈序站在门口。

头发被风吹乱，外套上还有雨水，手里提着一个小蛋糕。

他说：“航班延误了，差点赶不上。”

许知南愣在那里，眼泪一下就掉了下来。

她问：“你怎么非要回来？”

陈序说：

“因为我不想让你觉得，你的生日又可以被随便推迟。”

那句话，像一把很轻的钥匙，打开了她心里很多年的委屈。

她终于明白，真正的偏爱不是天天把“我爱你”挂在嘴边。

而是他知道你以前总被放到最后，所以这一次，他偏要让你排在第一。

偏爱是：

他可以很忙，但不会让你一直等。

他可以对很多人好，但不会让你分不清自己重不重要。

他可以有很多选择，但会用行动告诉你，那个特别的位置，是你的。

很多人都说，成年人别太渴望偏爱。

可我觉得，人这一生，就是需要一次偏爱。

不是为了变得任性。

而是为了相信自己值得。

值得被看见。

值得被心疼。

值得被坚定选择。

值得不用懂事到连委屈都不敢说。

真正好的感情，不是他只会对你好。

而是他本来就很好，可你依然能清楚地感觉到：他给你的那一份，是不一样的。

别人也能得到他的礼貌。

但你能得到他的牵挂。

别人也能得到他的帮忙。

但你能得到他的惦记。

别人也能听见他的“路上小心”。

但你能等到他走过来，亲自送你回家。

这才是偏爱。

愿你以后遇见的人，不只是对你好，而是让你知道，你和别人不一样。

愿你不用在感情里排队，不用猜自己是不是特别，不用反复证明自己重不重要。

愿有一个人，可以对世界温柔，也可以把最特别的耐心、最细致的心疼、最坚定的选择，都留给你。

因为真正的偏爱，从来不是他对别人不好。

而是他对所有人都很好。

可唯独对你，格外不同。

原文发布于微信公众号合集《每晚一首歌，聊点成年人不说的话》。

Cloudflare IP优选

Sun, 03 May 2026 00:00:00 GMT

一、Cloudflare IP优选#

步骤1：添加路由规则#

登录Cloudflare账号，进入你绑定的Astro博客域名控制台（左侧导航栏选择对应域名）。
找到左侧导航栏的路由（Rules），点击进入后选择「转换规则」或「路由」（按当前Cloudflare界面显示为准）。
点击「添加路由」，进入路由配置页面。
路由地址填写：你的Astro域名/*（示例：blog.xxx.com/*），含义是匹配Astro博客的所有页面（包括文章、静态资源），统一走优选节点。
无需额外添加规则，直接保存并确认路由配置。

步骤2：配置DNS解析（关键步骤）#

在Cloudflare域名控制台，找到左侧导航栏的DNS → 记录，点击进入。
点击「添加记录」，开始配置优选解析。
记录类型：选择「A记录」或「CNAME」均可。
名称：可自定义前缀（如cdn、speed、ip），用于标识优选节点（示例：speed.xxx.com）。
目标：填写UP主提供的Cloudflare优选节点/地址（格式：任意文字或字母.cf.090227.xyz，直接复制粘贴，确保地址正确）。
代理状态：必须关闭云朵图标（即关闭Cloudflare代理），否则优选无效。
点击「保存」，完成优选解析记录添加。

步骤3：绑定Astro主域名到优选节点#

再次点击「添加记录」，配置Astro主域名的解析。
记录类型：与上一步一致（A记录/CNAME）。
名称：填写Astro主域名前缀（如blog，即blog.xxx.com，若为根域名则填写@）。
目标：填写上一步创建的优选记录名称（示例：speed.xxx.com），将主域名指向优选节点。
代理状态：保持关闭（与上一步一致）。
点击「保存」，等待1-3分钟解析生效，刷新Astro博客即可感受到访问速度提升。

原理：Astro博客主域名 → Cloudflare优选地址 → Cloudflare最优节点，自动选择国内延迟最低的IP，减少静态资源（Astro生成的HTML、CSS、图片）加载耗时。

二、Astro博客Markdown文章编写与发布#

Astro博客的文章均以Markdown格式编写，核心需遵循Astro的Frontmatter元数据规范，以下步骤完全适配Astro框架，新手可直接复刻。

1. 文章存放位置（Astro固定路径）#

所有Markdown文章，需放在Astro项目源码的 src/content/posts/ 文件夹下（若没有posts文件夹，可手动创建，Astro默认读取该路径下的文章）。
文章格式：必须是纯Markdown文件（后缀为.md），文件名建议用英文/拼音（如astro-blog-guide.md），避免中文乱码。
图片、附件等资源：统一放在 src/content/posts/images/ 或 src/assets/ 文件夹下（推荐前者，方便管理），引用时使用相对路径。

2. 文章必备元数据（Astro Frontmatter规范）#

每篇Markdown文章顶部，必须编写固定格式的Frontmatter元数据（用---包裹），适配Astro的文章渲染逻辑，示例如下（可直接复制修改）：

1
---
2
title: 文章标题（如：Astro博客部署全流程指南）
3
date: 2026-05-03 19:00:00
4
description: 文章简短描述（100字内，用于SEO和文章列表展示）
5
cover: /src/content/posts/images/cover.jpg
6
tags: [Astro, 静态博客, 部署]
7
categories: 技术教程
8
draft: false
9
author: 作者名
10
pubDate: 2026-05-03 19:00:00
11
---

元数据字段说明

title：文章标题，必填，将作为博客文章的标题展示。
date：文章发布时间，格式为YYYY-MM-DD HH:MM，适配Astro时间渲染。
description：文章简短描述，控制在100字内，用于SEO优化和博客文章列表展示。
cover：文章封面图路径，可填写本地相对路径（需对应资源存放位置）或网络图片链接。
tags：文章标签，用英文逗号分隔并包裹在中括号内，适配Astro标签功能，方便分类检索。
categories：文章分类，可自定义，用于博客文章分类展示。
draft：草稿状态，true为草稿（不显示在博客），false为正式发布（必填）。
author：作者名，可选，适配Astro作者展示功能。
pubDate：可选，与date一致即可，部分Astro主题需配置以正常显示发布时间。

Astro支持的Markdown功能（适配文章编写） Astro完全支持标准Markdown语法，可正常使用标题（# ~ ######）、段落、列表（有序/无序）、代码块（```包裹）、链接、图片、引用（>）等功能，同时支持GFM扩展语法（如表格、任务列表），可满足日常文章编写需求，无需额外配置。
推荐编辑器（适配Astro，二选一）
VS Code（推荐，适配Astro开发）：原生支持Astro项目结构，可安装Markdown预览插件，实现语法高亮、实时预览，同时可编辑Astro项目代码，适合兼顾开发与写作的用户。
Obsidian（OC，适合纯写作）：可视化编辑，实时预览Markdown效果，无需记忆语法，适合不想接触代码的新手；可将Obsidian的文章文件夹，与Astro项目的src/content/posts/文件夹关联，编写完成后直接同步，无需手动复制。

真正有吸引力的必杀技，都赢在这两个字

Sun, 03 May 2026 00:00:00 GMT

真正有吸引力的必杀技，都赢在这两个字#

音频：真诚其实是最简单最动人的必杀技 / 春风不语人

耳机里响起《必杀技》的时候，我突然想到一个问题：

在感情里，男生吸引到一个女生，到底什么才算真正的“必杀技”？

是秒回消息吗？

是制造惊喜吗？

是故意冷几天，让对方开始在意吗？

还是学会那些所谓的聊天技巧、推拉节奏、情绪价值？

以前很多人都以为，喜欢一个人不能太明显，追一个人不能太真诚。

你要会藏，要会装，要让她猜，要让她觉得你不是非她不可。

可后来我才发现，感情里最打动人的，从来不是谁更会演，也不是谁更会拿捏。

而是一个人明明也害怕被拒绝，却还是愿意认真地靠近你。

所谓爱情里的“必杀技”，从来不是套路。

是真诚。

我见过一个男生，叫阿远。

他喜欢一个女生很久。

女生叫林夏，是他们公司新来的设计师。

第一次见面，是在一场项目会议上。

会议室里很吵，大家都在争论方案。只有林夏坐在靠窗的位置，安静地翻着文件。

轮到她发言时，她没有急着表现自己，只是把问题一条条讲清楚。

声音不大，却很坚定。

阿远就是在那个瞬间，对她有了好感。

后来他跟朋友说：

“她身上有一种很舒服的感觉，不张扬，但很让人想靠近。”

朋友笑他：

“喜欢就追啊，不过现在追女生，不能太老实。你得有点技巧，别一上来就暴露需求感。”

阿远听进去了。

于是，他开始学着“克制”。

林夏发朋友圈，他明明想评论，却只点了个赞。

林夏给他发消息，他明明马上看到了，却故意隔十几分钟才回。

林夏说今天加班有点累，他明明很想问她吃没吃饭，最后却只发了一句：

“早点休息。”

他以为这样显得成熟。

以为不那么主动，就不会显得卑微。

以为把喜欢藏起来，对方反而会更在意。

可结果是，林夏一直离他很远。

他们明明每天都能见面，明明有很多次可以靠近的机会，可每一次，阿远都把自己退回了安全位置。

他怕自己太明显。

怕同事看出来。

怕林夏知道以后尴尬。

更怕自己一认真，就输了。

有一次，公司聚餐。

林夏夹不到远处的菜，阿远下意识把盘子转到她面前。

旁边同事起哄：

“阿远，你是不是对林夏有点特别啊？”

所有人都笑。

阿远也笑。

他几乎没有犹豫，就摆摆手说：

“没有没有，大家都是同事嘛。”

这句话说出口的时候，他以为自己化解了尴尬。

可他没有注意到，林夏低头喝水的那一瞬间，眼神暗了一下。

后来他才明白。

有些女生不是看不懂你的喜欢。

她只是想知道，你的喜欢到底有没有勇气站出来。

你所有的靠近，如果都用“顺便”包装。

你所有的关心，如果都用玩笑带过。

你所有的喜欢，如果一被别人提起就急着否认。

那她怎么敢相信，你是真的？

很多感情最遗憾的地方，不是不喜欢。

而是明明喜欢，却非要装作无所谓。

明明在意，却偏偏让对方猜。

明明心里已经走过去了，嘴上还要说：

“我没有。”

后来，林夏身边出现了另一个男生。

那个男生不算特别会说话，也没有什么所谓的恋爱技巧。

他不会故意晚回消息，也不会装作忽冷忽热。

但他很直接。

林夏加班，他会问：

“你吃饭了吗？我刚好下楼，可以帮你带一份。”

林夏方案被否定，他不会急着讲大道理，而是认真听她说完。

林夏说周末想看展，他不会假装自己也刚好想去，而是直接说：

“我想陪你去。”

阿远一开始很不服。

他觉得那个人太笨了。

喜欢得那么明显，不怕输吗？

可慢慢地，他发现林夏和那个人在一起的时候，很放松。

她不用猜对方到底什么意思。

不用小心翼翼判断一句话背后的含义。

不用在忽冷忽热里怀疑自己是不是想多了。

因为那个人给她的感觉很简单：

我喜欢你，所以我靠近你。

我在意你，所以我不装。

我想对你好，所以我不会让你一直猜。

阿远这才发现，原来女生真正会被打动的，不是一个男生多会撩。

而是他敢不敢真诚。

后来有一次，项目赶进度。

林夏一个人留在公司加班。

那天晚上下了很大的雨，办公室里的人陆续走光，只剩她坐在电脑前改图。

阿远站在茶水间门口，看见她揉了揉眼睛，又低头继续工作。

那一刻，他突然不想再装了。

他下楼买了两杯热咖啡。

回来的时候，外套被雨打湿了一半。

他走到林夏桌前，把咖啡放下。

林夏抬头看他。

这一次，阿远没有说“顺便”。

也没有用玩笑带过去。

他只是很认真地说：

“这杯不是顺便买的，是专门给你的。”

林夏愣了一下。

阿远站在那里，声音有点发紧。

他说：

“林夏，我以前总觉得，喜欢一个人不能表现得太明显。”

“怕太主动会掉价，怕太认真会被看轻，怕我说出来以后，我们连朋友都做不成。”

“所以我总是装。”

“装作只是顺路，装作只是普通关心，装作没那么在意你。”

他说到这里，停了几秒。

然后像终于把藏了很久的话，从心口拿出来一样：

“可其实不是。”

“我喜欢你，是真的。”

“不是因为一时新鲜，也不是因为大家起哄。”

“我是想认真认识你，认真靠近你，认真对你好。”

“你不用马上给我答案，也不用有压力。我只是觉得，再不说出来，我连喜欢你这件事都不够坦荡。”

那一刻，办公室很安静。

窗外是雨声，电脑屏幕的光落在林夏脸上。

她没有立刻回答。

只是看着那杯咖啡，轻轻说了一句：

“其实我不是没有感觉到。”

阿远愣住。

林夏说：

“我只是一直不确定，你到底是真的喜欢我，还是只是偶尔对我好。”

这句话，让阿远心里酸了一下。

因为他终于明白，原来很多错过，不是因为不喜欢。

而是因为不确定。

不是因为没有机会。

而是因为不真诚。

后来，林夏没有立刻答应阿远。

他们也没有像电视剧里那样，因为一场告白就马上在一起。

真正的感情，本来就不是一句话就能翻篇。

但从那以后，阿远变了。

林夏说累，他不会只说“早点休息”，而是问：

“要不要我给你带点吃的？”

林夏说想看展，他不会再假装偶遇，而是直接说：

“我想陪你去。”

林夏心情不好，他不会急着讲道理，而是安静听她说完。

他开始明白，真诚不是把所有热情一下子倒给对方。

也不是用感动去绑架谁。

真诚是稳定。

是清楚。

是你说到的事情会做到。

是你喜欢一个人，就不让她一直猜。

是你在靠近她的时候，也给她足够的尊重和安全感。

后来某天，林夏问阿远：

“你以前为什么总是装得那么无所谓？”

阿远想了很久，说：

“因为我怕你不喜欢我。”

林夏笑了一下：

“可你越装无所谓，我越不敢相信你喜欢我。”

这句话，其实很多人都该听懂。

女生不是喜欢套路。

她只是希望自己别输在真心里。

她可以接受你不够浪漫。

可以接受你嘴笨，不会说漂亮话。

甚至可以接受你送的礼物不贵，安排的约会不完美。

但她很难接受，你一边靠近她，一边又让她没有安全感。

你让她猜。

让她等。

让她怀疑自己是不是想多了。

让她明明感觉到你的喜欢，却又在你一次次退缩里，把心慢慢收回去。

成年人的感情已经够累了。

大家都见过太多暧昧，听过太多漂亮话，也经历过太多忽近忽远的关系。

所以到最后，真正稀缺的，从来不是会聊天的人。

而是愿意真诚的人。

不是会制造情绪起伏的人。

而是能给人稳定回应的人。

不是嘴上说“我会一直在”的人。

而是真的在某个下雨的晚上，愿意站在你面前，把话说清楚的人。

真正吸引女生的必杀技，都赢在这两个字：

真诚。

你可以不完美。

可以不够会说话。

可以偶尔笨拙，偶尔紧张，偶尔不知道怎么表达。

但你不能一边说喜欢，一边让她没有安全感。

不能一边靠近，一边又随时准备退场。

不能一边在意，一边又装作无所谓。

因为一个女生真正想要的，不是被你套路成功。

而是被你坚定选择。

《必杀技》最适合放在这样的故事里。

因为它像是在提醒我们：

爱情不是一场博弈。

喜欢也不是一场考试。

你不需要把自己训练成一个多会拿捏的人。

也不需要把真心伪装成不在乎。

真正能打动一个人的，往往不是你有多少技巧，而是你敢不敢坦荡地告诉她：

“我喜欢你，不是玩笑。”

“我靠近你，不是顺便。”

“我对你好，不是套路。”

“我是真的想和你有以后。”

所以，男生追女生最重要的是什么？

不是多会撩。

不是多会安排惊喜。

不是多懂所谓的恋爱技巧。

而是在喜欢这件事上，你能不能真诚一点。

别让一个本来可能靠近你的人，在你的试探里失望。

别让一个本来也许愿意相信你的人，在你的忽冷忽热里退后。

别把真心藏得太深。

因为有时候，你以为自己藏住了喜欢。

其实只是藏丢了机会。

爱情里真正的必杀技，从来不是套路。

是你明明也怕受伤，却还是愿意认真一次。

是你明明也怕被拒绝，却还是愿意坦荡一点。

是你终于敢站在她面前，认真地说：

“我喜欢你，是真的。”

原文发布于微信公众号合集《每晚一首歌，聊点成年人不说的话》。

Firefly 博客搭建教程

Wed, 29 Apr 2026 00:00:00 GMT

Firefly 博客部署教程#

根据Firefly 官方文档，涵盖全流程操作，代码可直接复制，小白可按步完成，附关键避坑提示。说明：基于 Windows 系统；命令可直接执行。

第一篇：前置准备｜安装必备环境#

一、前言#

Firefly 是 Astro 静态博客主题，本文是作者的搭建笔记，为以后回溯搭建过程，为后续操作筑牢基础。

二、必备软件清单#

Node.js：核心环境，版本 ≥22
pnpm
Git：用于拉取源码、提交代码
VS Code：推荐编辑器，用于修改配置、写文章

三、分步安装教程#

1. 安装 Node.js#

访问 https://nodejs.org/，下载 LTS 版。
image.png|528

image.png|534

终端执行 node -v、npm -v，输出版本号即成功。

image.png

注意：安装后重启终端，无效则重启电脑。

2. 安装 pnpm#

终端执行：npm install -g pnpm
执行 pnpm -v 输出版本号即成功，权限不足用管理员终端。

image.png

注意：网络超时切换手机热点。

3. 安装 Git#

1.访问 https://git-scm.com/download/win，下载最新版并默认安装。

image.png

2. 一直下一步就行了，全程默认安装。

4. 安装 VS Code（可选）#

1.访问 https://code.visualstudio.com/，下载并安装，勾选“创建桌面快捷方式”和“将 Code 加入 PATH”。

image.png

推荐安装中文插件。

image.png

四、常见环境问题排查#

node 命令无效 → 重新安装并勾选“Add to PATH”，重启终端/电脑。
pnpm 权限不足 → 用管理员终端执行命令。
git 无反应 → 重启电脑，无效则重装。

第二篇：源码托管｜Fork Firefly 官方仓库#

一、前言#

通过Fork官方仓库，获得自己的独立仓库，可自由修改内容、同步官方更新，后续推送代码到该仓库，Cloudflare会自动触发构建部署。

二、前置准备#

已完成第一篇环境安装（Node ≥22、pnpm、Git、VS Code）
已注册并登录 GitHub 账号

三、Fork 操作步骤（1分钟完成）#

打开Firefly官方仓库：https://github.com/CuteLeaf/Firefly
点击页面右上角的「Fork」按钮（绿色/灰色，位置显眼）。
等待3-5秒，页面自动跳转，此时你已拥有「自己的Firefly仓库」（仓库地址：https://github.com/你的GitHub用户名/Firefly）。

关键说明：Fork后的仓库归你所有，修改内容不会影响官方仓库，后续可一键同步官方更新，适合长期维护。

第三篇：本地搭建｜克隆仓库 + 本地预览调试#

一、前言#

将你Fork后的仓库克隆到本地，安装依赖后启动本地服务，用于预览修改效果（仅本地查看，无需打包，推送代码后Cloudflare自动部署）。

二、前置准备#

已完成前两篇操作（环境安装、Fork仓库）
新建空文件夹：路径无中文、无空格、无特殊字符（示例：D:\blog）

三、分步操作教程#

四、克隆你自己的仓库到本地#

进入 你的 Fork 仓库 页面
点击 Code → 复制 HTTPS 地址
执行克隆（把地址换成你自己的）：运行

1
git clone https://github.com/你的用户名/Firefly.git

1
cd Firefly

2. 安装本地依赖（仅用于本地预览）#

安装依赖（用 pnpm）运行

1
pnpm install

3. 启动本地预览服务#

1
pnpm dev

等待10-30秒，终端显示访问地址： http://localhost:4321
打开浏览器输入该地址，看到Firefly默认首页，即本地搭建成功。

4. 本地简单调试#

修改配置 / 文章 → 保存自动刷新

在项目根目录创建wrangler.toml： Cloudflare Workers部署需要

1
name = "firefly"
2
compatibility_date = "YYYY-MM-DD" # 更为今日
3

4
[assets]
5
directory = "./dist"
6

7
[vars]
8
NODE_VERSION = "22"

2.简单修改站点信息。

停止服务：Ctrl + C
重新启动：pnpm dev
本地仅用于预览，无需执行任何打包命令（Cloudflare会自动打包）。

5. 本地开发完成后#

1.先配置本地 Git 身份

打开电脑的终端（Mac/Linux） 或 Git Bash/CMD（Windows），执行 2 条命令：

1
# 1. 设置你的GitHub用户名（就是你GitHub主页的用户名）
2
git config --global user.name "你的GitHub用户名"
3

4
# 2. 设置你的GitHub绑定邮箱（就是你注册GitHub用的邮箱）
5
git config --global user.email "你的GitHub邮箱"

检测是否成功

1
git config --global user.name
2
git config --global user.email

1
能显示出你填的信息，就说明绑定好了。

2. 推送到 GitHub：

1
git add .
2
git commit -m "更新内容"
3
git push

第四篇：部署配置｜Cloudflare 关联GitHub自动构建#

一、前言#

这是核心部署步骤，关联你的GitHub仓库后，后续只要推送代码到GitHub，Cloudflare会自动执行「安装依赖→打包→上线」，全程无需手动操作。

二、前置准备#

已完成前几篇操作（环境安装、Fork仓库、本地搭建，简单修改，上传到github）
已注册并登录Cloudflare账号（无账号可注册：https://dash.cloudflare.com/）
你的GitHub仓库已包含完整Firefly源码

三、分步配置教程#

1. 新建 Cloudflare Worker 应用#

登录 Cloudflare 控制台 打开浏览器访问官方控制台：https://dash.cloudflare.com/，输入账号密码完成登录。
进入 Workers & Pages 页面 登录后，在左侧菜单栏找到并点击 Workers 和 Pages（英文对应：Workers & Pages），进入应用管理页面。
创建应用程序 在页面右上角，点击 创建应用程序（英文对应：Create application），进入应用创建流程。
关联 GitHub 代码仓库 在创建页面中，选择 连接到 Git（Connect Git），然后选中 GitHub，按照页面提示完成授权，允许 Cloudflare 访问你的 GitHub 账号。
选择目标仓库 授权完成后，系统会列出你的 GitHub 所有仓库，从中选中需要部署到 Cloudflare Worker 的代码仓库（如 Firefly 仓库）。
配置构建设置 ：

Build command: pnpm build
Deploy command: npx wrangler deploy

发起首次部署 配置完成后，点击页面底部的 部署（Deploy），启动首次自动部署流程。
等待自动构建完成 Cloudflare 会自动执行三个操作：拉取 GitHub 仓库代码 → 执行构建命令 → 将项目部署至 Workers 服务器，耐心等待即可。。

2. 验证自动部署是否成功#

当构建状态显示“成功”后，点击 Worker 项目顶部的 临时域名（格式为：xxx.workers.dev）。
打开浏览器访问该临时域名，若页面展示效果与本地预览的博客首页完全一致，说明 Cloudflare Worker 与 GitHub 自动部署配置成功。

第五篇：绑定域名（Spaceship 平台域名适配）#

完成 Cloudflare Worker 自动部署后，默认使用 xxx.workers.dev 临时域名访问，为了提升专业性和记忆性，我们将你在 Spaceship 平台注册的域名，绑定到 Worker 应用，全程适配博客框架，步骤清晰无冗余。

一、绑定前准备（必做）#

确认域名状态：登录 Spaceship 控制台，确认你的域名状态为“正常”，未被锁定、未过期，且已完成实名认证（若有要求），避免因域名异常导致绑定失败。

二、Step 1：在 Cloudflare 中添加自定义域名#

登录 Cloudflare 控制台，进入之前创建的 Worker 项目主页（可通过左侧「Workers 和 Pages」找到对应项目）。
在项目主页左侧导航栏，点击 触发器（英文：Triggers）选项卡，找到「自定义域」模块，点击 添加自定义域。
在弹出的输入框中，填写你在 Spaceship 平台的域名（如 yourdomain.com 或 www.yourdomain.com），点击添加。
添加后，Cloudflare 会自动生成对应的 DNS 解析记录（CNAME 记录），记录下该 CNAME 记录的「目标值」（通常为你的 Worker 临时域名），后续需在 Spaceship 平台配置该解析。

三、Step 2：在 Spaceship 平台配置 DNS 解析（核心步骤）#

这一步是关键，需在你的域名所在平台（Spaceship）修改 DNS 解析，将域名指向 Cloudflare Worker，具体操作如下：

登录 Spaceship 控制台：打开浏览器，访问 https://www.spaceship.com/zh/auth/?returnUrl=%2Flaunchpad%2F，输入你的账号密码完成登录（若已登录可直接进入）。
进入域名管理页面：登录后，点击顶部「Launchpad」（控制台），找到「Domain Manager」（域名管理）模块，在域名列表中找到你要绑定的域名，点击该域名进入详情页。
进入 DNS 解析设置：在域名详情页中，找到「DNS」选项（或「DNS 解析」「解析设置」），点击进入 DNS 解析配置页面，删除当前无关的解析记录（避免冲突）。
添加 CNAME 解析记录：点击「添加记录」（或「新增解析」），按以下参数填写（适配 Cloudflare Worker 绑定）：
1. 记录类型：选择 CNAME（核心类型，用于将域名指向 Worker 临时域名，适配 IP 动态变化场景）；
2. 主机记录：填写 @（代表主域名，如 yourdomain.com）或 www（代表带 www 前缀的域名，如 www.yourdomain.com，建议两者都添加）；
3. 记录值：粘贴 Step 1 中 Cloudflare 生成的 CNAME 目标值（即 Worker 临时域名，如xxx.workers.dev），确保填写无误；
4. TTL（缓存时间）：设置为 10~60 分钟（数值越小，解析生效越快，新手可直接默认）；
点击「保存」，完成 DNS 解析配置，此时 Spaceship 平台的域名解析已指向 Cloudflare Worker。

四、Step 4：验证域名绑定是否成功#

DNS 解析生效时间通常为 10 分钟~24 小时（新域名生效较快，老域名可能需等待更久），可通过以下两种方式验证绑定结果：

浏览器直接访问：打开浏览器，输入你绑定的域名（如 yourdomain.com），若能正常显示博客首页，且地址栏有 HTTPS 小锁标志，说明绑定成功；若提示“无法访问”，请耐心等待解析生效，或检查解析记录填写是否正确。
在线工具查询：使用 DNS 解析查询工具（如 DNSChecker.org），输入你的域名，查询 CNAME 记录，若查询结果与你配置的 Worker 临时域名一致，说明解析已生效，绑定成功。

###五、域名绑定常见问题排查

解析配置后无法访问：检查 Spaceship 平台的 CNAME 记录值是否与 Cloudflare 生成的目标值一致，TTL 设置是否过小，若无误，耐心等待解析生效（最长 24 小时）；同时确认 Cloudflare 中自定义域已添加成功。
浏览器提示“不安全”：检查 Cloudflare 的 SSL/TLS 加密模式是否设置正确，证书是否已生效，若未生效，等待几分钟后刷新页面重试。
提示“域名已被占用”：确认该域名未被其他 Cloudflare 项目绑定，若已绑定，先删除原有绑定，再重新添加。
DNS 解析修改无效：检查 Spaceship 平台的域名 DNS 服务器是否为默认服务器，若已修改为第三方 DNS，需先改回默认或同步解析记录至对应 DNS 服务器。

Git 使用教程测试

Tue, 28 Apr 2026 00:00:00 GMT

Git 详细使用教程（命令行版，附命令作用解释）#

Git 是目前最流行的分布式版本控制系统，核心作用是跟踪文件变化、管理代码版本，支持多人协作开发，可随时回滚到历史版本，避免代码丢失或冲突。本教程全程使用命令行操作（Windows 用 Git Bash、Mac/Linux 用终端），从基础配置到高级用法，逐一讲解命令作用和实操场景，新手可直接跟着步骤练习。

一、Git 前期准备（必做）#

1. 安装 Git#

先在本地安装 Git，安装完成后，打开命令行，输入以下命令验证是否安装成功：

Terminal window

1
git --version

命令作用：查看当前 Git 版本，若输出类似git version 2\.43\.0，说明安装成功；若提示“命令不存在”，需重新安装 Git。

2. 初始配置（绑定身份，关键步骤）#

Git 每次提交代码时，会记录提交者的身份（用户名和邮箱），用于区分不同开发者，必须配置后才能正常提交代码。

Terminal window

1
# 配置用户名（建议和 GitHub/GitLab 用户名一致）
2

3
git config --global user.name "你的用户名"
4

5

6

7
# 配置邮箱（建议和 GitHub/GitLab 绑定邮箱一致）
8

9
git config --global user.email "你的邮箱地址"

命令作用详解：

git config：Git 的配置命令，用于设置 Git 相关参数；
\-\-global：全局参数，意味着该配置在当前电脑所有 Git 项目中生效（若只想针对单个项目配置，去掉该参数，进入项目后再执行）；
user\.name/user\.email：配置提交者的用户名和邮箱，后续所有提交记录都会显示该信息。

验证配置是否成功：

Terminal window

1
git config --list

命令作用：查看当前 Git 的所有配置，若能看到刚才设置的用户名和邮箱，即为配置成功。

二、Git 核心概念（先理解，再操作）#

在使用命令前，先明确 3 个核心工作区域，避免操作混乱：

工作区（Working Directory）：就是你本地电脑上的项目文件夹，你直接修改的文件都在这个区域；
暂存区（Stage/Index）：临时存放你修改的文件，相当于“缓存区”，用于确认哪些修改需要提交到版本库；
版本库（Repository）：Git 真正保存版本的地方，存放所有提交记录，可随时回滚到任意历史版本（分为本地版本库和远程版本库，如 GitHub）。

核心流程：工作区修改 → 提交到暂存区 → 提交到本地版本库 → 推送到远程版本库（如 GitHub）。

三、本地仓库操作（最基础，必练）#

本地仓库是 Git 操作的基础，无需联网，可独立完成版本管理，适合个人开发或离线工作。

1. 初始化本地仓库（创建新项目）#

适用于：新建一个项目，想要用 Git 管理版本（比如本地新建的文件夹，需要变成 Git 仓库）。

Terminal window

1
# 1. 进入你要管理的项目文件夹（先切换到目标路径）
2

3
cd 你的项目文件夹路径（如：cd /Users/xxx/Documents/MyProject）
4

5

6

7
# 2. 初始化 Git 仓库
8

9
git init

命令作用详解：

cd：切换目录命令，用于进入你要操作的项目文件夹（若路径错误，会提示“没有该文件或目录”）；
git init：初始化 Git 仓库，执行后会在项目文件夹中生成一个隐藏的 \.git 文件夹（该文件夹是 Git 版本库的核心，不要删除），此时项目就被 Git 管理起来了。

注意：每个项目只需初始化一次，初始化后，该文件夹就是 Git 仓库了。

2. 查看工作区状态（高频命令）#

无论做什么操作，建议先查看工作区状态，确认当前文件的修改情况，避免误操作。

Terminal window

1
git status

命令作用：查看工作区、暂存区的文件状态，常见输出场景：

未修改：提示 nothing to commit, working tree clean（工作区干净，没有任何修改）；
已修改但未提交到暂存区：文件名称显示为 modified（红色）；
已提交到暂存区但未提交到版本库：文件名称显示为 staged（绿色）。

3. 将修改的文件提交到暂存区#

适用于：你在工作区修改了文件（如新增、修改、删除文件），需要先提交到暂存区，再准备提交到版本库。

Terminal window展开收起

1
# 方式1：提交所有修改的文件（最常用）
2

3
git add .
4

5

6

7
# 方式2：提交指定文件（适用于只提交部分修改）
8

9
git add 文件名（如：git add index.html）
10

11

12

13
# 方式3：提交指定文件夹下的所有文件
14

15
git add 文件夹名（如：git add src/）

展开收起

命令作用详解：

git add：将工作区的修改“暂存”起来，告诉 Git“这些修改我要提交到版本库，请先记录下来”；
\.：表示当前目录下所有修改的文件（包括新增、修改、删除），简化操作，无需逐个指定文件；
提交后，再执行git status，会看到文件变成绿色，提示“changes to be committed”（暂存区有等待提交的内容）。

4. 将暂存区的文件提交到本地版本库#

这是 Git 版本管理的核心步骤，提交后，修改会被永久保存到本地版本库，生成一条新的版本记录。

Terminal window

1
git commit -m "提交说明"

命令作用详解：

git commit：将暂存区的内容提交到本地版本库，完成一次版本更新；
\-m \&\#34;提交说明\&\#34;：必填参数，用于描述本次提交的内容（如“新增登录页面”“修复首页轮播bug”），建议说明清晰，方便后续查看历史记录时，快速知道该版本做了什么修改；
提交成功后，会提示类似 1 file changed, 2 insertions$\+$ 的信息，表示“1个文件被修改，新增了2行内容”。

注意：必须先执行 git add，再执行 git commit，否则会提示“没有可提交的内容”。

5. 查看提交历史记录#

适用于：查看之前的提交记录，包括提交者、提交时间、提交说明、版本号（用于回滚版本）。

Terminal window展开收起

1
# 方式1：查看完整历史记录（详细）
2

3
git log
4

5

6

7
# 方式2：查看简洁历史记录（只显示版本号和提交说明，推荐）
8

9
git log --oneline
10

11

12

13
# 方式3：查看所有提交记录（包括回滚的记录）
14

15
git reflog

展开收起

命令作用详解：

git log：显示所有提交记录，每条记录包含版本号（40位哈希值）、提交者、提交时间、提交说明；
\-\-oneline：简化输出，每条记录只显示前7位版本号和提交说明，更易查看；
git reflog：比 git log 更全面，会记录所有操作（包括回滚、撤销提交），常用于找回误删的版本。

6. 版本回滚（恢复到历史版本）#

适用于：修改出错、代码丢失，需要恢复到之前的某个稳定版本（核心操作，务必掌握）。

Terminal window展开收起

1
# 第一步：查看历史版本，获取要回滚的版本号（前7位即可）
2

3
git log --oneline
4

5

6

7
# 第二步：回滚到指定版本（两种常用方式）
8

9
# 方式1：彻底回滚，删除回滚版本之后的所有提交记录（谨慎使用，适合个人开发）
10

11
git reset --hard 版本号（如：git reset --hard a1b2c3d）
12

13

14

15
# 方式2：安全回滚，保留回滚版本之后的修改（推荐，适合多人协作）
16

17
git revert 版本号（如：git revert a1b2c3d）

展开收起

命令作用详解：

git reset \-\-hard 版本号：强制回滚到指定版本，工作区、暂存区的内容都会同步到该版本，之后的提交记录会被删除（无法恢复，谨慎使用）；
git revert 版本号：不会删除任何提交记录，而是生成一条新的提交记录，将代码恢复到指定版本，后续的修改仍然保留（安全，多人协作时优先使用）；
版本号：通过 git log \-\-oneline 获取，如 a1b2c3d（前7位即可，Git 会自动识别）。

7. 撤销工作区的修改（未提交到暂存区）#

适用于：在工作区修改了文件，但还没执行 git add，想放弃修改，恢复到上一次提交后的状态。

Terminal window

1
# 撤销单个文件的修改
2

3
git checkout -- 文件名（如：git checkout -- index.html）
4

5

6

7
# 撤销所有工作区的修改（未 add 的）
8

9
git checkout .

命令作用：放弃工作区的所有未暂存修改，将文件恢复到最近一次 git commit 或 git add 后的状态（注意：撤销后，修改会彻底丢失，无法恢复）。

8. 撤销暂存区的修改（已 add 但未 commit）#

适用于：执行了 git add，将修改提交到了暂存区，但还没执行 git commit，想撤销暂存，重新修改。

Terminal window

1
git reset HEAD 文件名（如：git reset HEAD index.html）
2

3

4

5
# 撤销所有暂存区的修改
6

7
git reset HEAD .

命令作用：将暂存区的修改撤销回工作区，此时文件状态会从“绿色（staged）”变回“红色（modified）”，之后可以重新修改、重新 add。

四、远程仓库操作（多人协作必备）#

远程仓库（如 GitHub、GitLab、Gitee）是用于多人共享代码的服务器，本地仓库的代码可以推送到远程，也可以从远程拉取别人的代码，实现协作开发。

前提：你已经有一个远程仓库（如在 GitHub 上创建了仓库），且本地 Git 已配置好远程仓库地址。

1. 关联远程仓库（第一次绑定）#

适用于：本地已有 Git 仓库，想要和远程仓库绑定，实现代码同步。

Terminal window

1
git remote add origin 远程仓库地址

命令作用详解：

git remote：用于管理远程仓库的命令（如添加、删除、查看远程仓库）；
add：添加远程仓库；
origin：远程仓库的别名（默认用 origin，可自定义，如 git remote add github 远程地址），后续操作远程仓库时，用别名即可，无需输入完整地址；
远程仓库地址：从 GitHub/GitLab 复制，一般分为 HTTPS 和 SSH 两种（HTTPS 无需配置密钥，直接输入账号密码即可；SSH 需要配置密钥，无需每次输入账号密码，推荐长期使用）。

查看已关联的远程仓库：

Terminal window

1
git remote -v

命令作用：查看当前本地仓库关联的所有远程仓库，输出会显示远程仓库的别名、地址，以及可进行的操作（fetch：拉取，push：推送）。

2. 从远程仓库拉取代码（同步别人的修改）#

适用于：多人协作时，别人将代码推送到了远程仓库，你需要将远程的最新代码拉取到本地，保持本地和远程同步。

Terminal window

1
# 方式1：拉取远程默认分支（如 main/master）的最新代码（最常用）
2

3
git pull origin main（或 master，取决于远程仓库的默认分支名）
4

5

6

7
# 方式2：拉取远程指定分支的代码
8

9
git pull origin 分支名（如：git pull origin develop）

命令作用详解：

git pull：等价于 git fetch \+ git merge，即先从远程拉取最新代码到本地临时区域，再自动合并到当前本地分支；
origin：远程仓库别名；
main/master：远程仓库的默认分支（GitHub 现在默认分支是 main，旧版本是 master）；
注意：拉取代码前，建议先执行 git commit，将本地的修改提交到本地版本库，避免拉取时出现代码冲突。

3. 将本地代码推送到远程仓库（分享自己的修改）#

适用于：你在本地完成了代码修改（已 commit 到本地版本库），想要将修改推送到远程仓库，让别人看到你的代码。

Terminal window展开收起

1
# 方式1：推送本地默认分支到远程默认分支（第一次推送需加 -u）
2

3
# 第一次推送（绑定本地分支和远程分支，后续可直接用 git push）
4

5
git push -u origin main（或 master）
6

7

8

9
# 后续推送（已绑定分支，无需加 -u）
10

11
git push origin main（或 master）
12

13

14

15
# 方式2：推送本地指定分支到远程指定分支
16

17
git push origin 本地分支名:远程分支名（如：git push origin develop:develop）

展开收起

命令作用详解：

git push：将本地版本库的提交记录推送到远程仓库；
\-u：第一次推送时使用，用于绑定本地分支和远程分支（如本地 main 分支绑定远程 main 分支），后续推送时，直接输入 git push 即可，无需指定别名和分支；
推送失败常见原因：① 本地代码不是最新的（需先 git pull 拉取远程最新代码，解决冲突后再推送）；② 没有远程仓库的权限（检查账号密码或 SSH 密钥配置）。

4. 克隆远程仓库到本地（第一次下载）#

适用于：本地没有该项目，直接从远程仓库下载完整的项目代码（包括所有版本记录）。

Terminal window

1
git clone 远程仓库地址

命令作用详解：

git clone：将远程仓库的所有内容（包括代码、版本记录、分支）完整下载到本地，自动创建项目文件夹，并初始化 Git 仓库；
执行后，本地会自动关联该远程仓库（别名默认是 origin），无需再执行 git remote add；
示例：git clone https://github\.com/用户名/项目名\.git（HTTPS 地址），或 git clone git@github\.com:用户名/项目名\.git（SSH 地址）。

5. 查看远程分支#

Terminal window展开收起

1
# 查看本地所有分支
2

3
git branch
4

5

6

7
# 查看远程所有分支
8

9
git branch -r
10

11

12

13
# 查看本地和远程所有分支
14

15
git branch -a

展开收起

命令作用：

git branch：查看本地已有的分支，当前所在分支会用 \* 标记；
\-r：查看远程仓库的所有分支；
\-a：查看本地和远程的所有分支（远程分支会显示为 remotes/origin/分支名）。

6. 切换/创建分支（多人协作核心）#

多人协作时，建议每人在自己的分支上开发，避免直接修改默认分支（main/master），开发完成后再合并到默认分支。

Terminal window展开收起

1
# 1. 创建新分支（并切换到该分支，最常用）
2

3
git checkout -b 分支名（如：git checkout -b develop）
4

5

6

7
# 等价于以下两条命令：
8

9
# git branch 分支名（创建分支）
10

11
# git checkout 分支名（切换到该分支）
12

13

14

15
# 2. 切换到已有的本地分支
16

17
git checkout 分支名（如：git checkout main）
18

19

20

21
# 3. 切换到远程分支（并创建本地对应分支）
22

23
git checkout -b 本地分支名 origin/远程分支名（如：git checkout -b develop origin/develop）

展开收起

命令作用详解：

git checkout \-b 分支名：一次性完成“创建分支+切换分支”，高效便捷；
分支命名建议：按功能命名（如 feature/login，表示登录功能分支）、按bug修复命名（如 fix/banner\-bug），便于区分。

7. 合并分支（将开发分支的代码合并到默认分支）#

适用于：在开发分支（如 develop）完成开发后，将代码合并到默认分支（如 main），让修改生效。

Terminal window

1
# 1. 先切换到要合并到的目标分支（如 main 分支）
2

3
git checkout main
4

5

6

7
# 2. 合并开发分支（如 develop 分支）到当前分支（main）
8

9
git merge develop

命令作用：将指定分支（如 develop）的所有修改，合并到当前所在的分支（如 main），合并后，main 分支就包含了 develop 分支的所有代码。

注意：合并时可能会出现代码冲突（如两个人同时修改了同一个文件的同一行），此时需要手动解决冲突：

执行 git merge 后，Git 会提示“冲突文件”；
打开冲突文件，找到标记冲突的地方（用 \<\<\<\<\<\<\<、=======、\>\>\>\>\>\>\> 标记）；
修改冲突内容（保留需要的代码，删除冲突标记）；
执行 git add \. 和 git commit \-m \&\#34;解决合并冲突\&\#34;，完成合并。

8. 删除分支（分支开发完成后）#

Terminal window展开收起

1
# 删除本地分支（分支已合并到主分支，可安全删除）
2

3
git branch -d 分支名（如：git branch -d develop）
4

5

6

7
# 强制删除本地分支（分支未合并，强行删除，谨慎使用）
8

9
git branch -D 分支名
10

11

12

13
# 删除远程分支
14

15
git push origin --delete 分支名（如：git push origin --delete develop）

展开收起

命令作用：删除无用的分支，保持分支结构清晰，避免混乱。

五、常用补充命令（高频实用）#

Terminal window展开收起

1
# 1. 查看当前分支的提交差异（对比工作区和暂存区）
2

3
git diff
4

5

6

7
# 2. 查看暂存区和本地版本库的差异
8

9
git diff --cached
10

11

12

13
# 3. 查看两个分支之间的差异
14

15
git diff 分支1 分支2（如：git diff main develop）
16

17

18

19
# 4. 暂存当前修改，切换到其他分支（临时切换分支，不提交当前修改）
20

21
git stash  # 暂存当前修改
22

23
git stash pop  # 恢复暂存的修改（恢复后，暂存记录删除）
24

25
git stash list  # 查看所有暂存记录
26

27

28

29
# 5. 重命名本地分支
30

31
git branch -m 旧分支名 新分支名
32

33

34

35
# 6. 更新远程分支列表（远程删除了分支，本地同步）
36

37
git fetch --prune

展开收起

每个命令的作用简要说明：

git diff：快速查看修改的具体内容（哪一行被修改、新增/删除了什么）；
git stash：临时保存未提交的修改，常用于“正在开发一个功能，突然需要切换到其他分支修复bug”的场景；
git fetch \-\-prune：同步远程分支的删除操作，避免本地显示已删除的远程分支。

六、常见问题解决（新手必看）#

1. 拉取/推送代码时，提示“权限不足”#

原因：未配置正确的账号密码或 SSH 密钥。

解决方法：

若用 HTTPS 地址：重新输入正确的 GitHub/GitLab 账号密码；
若用 SSH 地址：配置 SSH 密钥（网上搜索“GitHub SSH 密钥配置”，按步骤操作即可，配置一次终身可用）。

2. 合并分支时出现代码冲突#

解决方法：按前面“合并分支”部分的步骤，手动修改冲突文件，删除冲突标记，保留需要的代码，再提交即可。

注意：冲突解决后，一定要仔细检查代码，确保没有误删有用的内容。

3. 误删本地代码/误回滚版本，如何恢复？#

解决方法：执行 git reflog，查看所有操作记录，找到误删/误回滚前的版本号，再执行git reset \-\-hard 版本号，即可恢复到该版本。

4. 推送代码时，提示“本地版本落后于远程版本”#

原因：远程仓库有别人推送的最新代码，你的本地代码不是最新的，无法直接推送。

解决方法：先执行 git pull 拉取远程最新代码，解决冲突后，再执行 git push。

七、总结（核心流程梳理）#

Git 的核心操作围绕“本地仓库”和“远程仓库”展开，新手记住以下流程即可快速上手：

前期准备：安装 Git → 配置用户名和邮箱；
本地开发：初始化仓库（git init）→ 修改文件 → 提交到暂存区（git add .）→ 提交到本地版本库（git commit -m "说明"）；
多人协作：克隆远程仓库（git clone）→ 拉取远程更新（git pull）→ 创建分支开发 → 推送分支到远程（git push）→ 合并分支；
问题处理：版本回滚（git reset/git revert）、解决冲突、恢复误删代码（git reflog）。

Git 命令看似多，但常用的只有十几个，多练习几次（比如新建一个测试项目，反复执行 add、commit、push、pull 等操作），就能熟练掌握。记住：所有命令的核心都是“跟踪版本、同步代码”，理解每个命令的作用，比死记硬背更重要。

Firefly 友链自助申请按钮添加

Mon, 27 Apr 2026 00:00:00 GMT

Firefly 友链自助申请按钮添加#

本篇教程适用于 Firefly Astro 主题，不破坏原有布局、不影响任何功能，只修改两处代码，实现两种友链申请入口。

右上角「自助申请友链」按钮
友链页面内「自助申请友链」文字链接

一、准备工作#

打开你的 Firefly 项目
准备好你的 GitHub 友链申请地址

1
https://github.com/fqzlr/Firefly/issues/new?template=friend-request.yml

全程只需要修改 2 个文件，复制粘贴即可完成。

二、添加右上角「自助申请友链」按钮#

修改文件#

1
src/pages/friends.astro

步骤 1：添加申请链接#

在文件顶部的变量区域加入：

1
const friendApplyUrl = "https://github.com/fqzlr/Firefly/issues/new?template=friend-request.yml";

步骤 2：替换标题区域布局#

找到页面标题部分，替换成以下布局：

1
<div class="flex flex-col gap-4 md:flex-row md:items-end md:justify-between">
2
  <div>
3
    <div class="flex items-center gap-3 mb-3">
4
      <div class="h-8 w-8 rounded-lg bg-(--primary) flex items-center justify-center text-white">
5
        <Icon name="material-symbols:group" class="text-[1.5rem]" />
6
      </div>
7
      <div class="text-3xl font-bold text-neutral-900 dark:text-neutral-100">
8
        {title}
9
      </div>
10
    </div>
11
    {description && (
12
      <p class="text-base text-neutral-600 dark:text-neutral-400 leading-relaxed">
13
        {description}
14
      </p>
15
    )}
16
  </div>
17

18
  <!-- 自助申请友链按钮 -->
19
  <div class="flex shrink-0 flex-col items-start gap-2 md:items-end">
20
    <a
21
      href={friendApplyUrl}
22
      target="_blank"
23
      rel="noopener noreferrer"
24
      class="inline-flex items-center gap-2 rounded-lg bg-(--primary) px-4 py-2.5 text-sm font-medium text-white transition-all hover:opacity-90 hover:scale-[1.02] active:scale-[0.98]"
25
    >
26
      <Icon name="material-symbols:add-link-rounded" class="text-lg" />
27
      <span>自助申请友链</span>
28
    </a>
29
    <p class="text-xs text-neutral-500 dark:text-neutral-400 md:text-right">
30
      通过 GitHub Issue 提交，系统会自动校验回链并同步收录
31
    </p>
32
  </div>
33
</div>

展开收起

完成效果#

✅ 右上角出现美观的申请按钮
✅ 适配明暗主题
✅ 点击直接跳转到友链申请表单
✅ 不破坏任何原有布局

三、添加友链页面内文字超链接#

修改文件#

1
src/content/spec/friends.mdx

找到 Step 2 里的：

1
<p class="font-semibold text-sm mb-1">自助申请友链</p>

替换成 文字超链接样式：

1
<a href="https://github.com/fqzlr/Firefly/issues/new?template=friend-request.yml"
2
   target="_blank"
3
   class="font-semibold text-sm mb-1 inline-block text-(--primary) hover:underline">
4
  自助申请友链
5
</a>

完成效果#

✅ 保持布局完全不变
✅ 文字变为主题色超链接
✅ 鼠标悬浮自动加下划线
✅ 点击即可跳转申请

四、最终效果#

你的友链页面现在拥有：

右上角申请按钮（醒目、直观）
步骤中的文字链接（流程清晰、体验友好）

两者配合，访客可以非常方便地提交友链申请。

五、常见问题#

1. 按钮文字看不见#

这是 CSS 变量问题，可使用固定色值：

1
class="... bg-blue-500 text-white ..."

2. 跳转 404#

检查用户名、仓库名、yml 模板文件名是否正确。

3. 样式错位#

只替换教程里对应的代码块，不要改动其他结构。

六、总结#

只需修改 2 个文件：

src/pages/friends.astro → 右上角按钮
src/content/spec/friends.mdx → 文字链接

Firefly 友链自助申请自动化

Mon, 27 Apr 2026 00:00:00 GMT

Firefly 友链自助申请自动化#

Tip

原教程来自upxuu https://upxuu.com/posts/friend-link-system

这篇文章把我这次在 Firefly 里落地的“友链自助申请”方案完整拆开讲一遍。

目标很简单：

访客不需要私聊站长，直接在 GitHub 仓库里点一个 Issue 模板。
填完网站名称、网站链接、友链页面 URL 等信息后，GitHub Actions 自动开始校验。
系统会自动检查对方站点是否真的加了本站友链。
校验通过后，自动把友链写入 src/config/friendsConfig.ts。
自动格式化、自动提交、自动推送，并在 Issue 里回评结果。

如果你也想在自己的博客里做一套类似的“自助申请友链”系统，这篇文章可以直接照着抄。

一、最终效果是什么#

这套方案上线后，整个流程会变成这样：

用户打开 GitHub 仓库里的“申请友链” Issue 模板。
填写以下信息：
- 网站名称
- 网站链接
- 友链页面 URL
- 网站描述
- 网站头像 URL
用户提交 Issue。
GitHub Actions 监听到 issues.opened 事件后自动运行。
工作流先给 Issue 打上“验证中”标签。
脚本使用 Playwright 访问对方填写的友链页面。
校验两件事：
- 这个页面能不能正常打开
- 页面里有没有本站的回链
如果校验失败：
- 在 Issue 里自动评论失败原因
- 给 Issue 打上 needs-update
如果校验成功：
- 自动更新 src/config/friendsConfig.ts
- 自动运行 Biome 格式化
- 自动提交到仓库
- 自动推送到默认分支
- 在 Issue 里评论“已添加成功”
- 自动关闭 Issue

评论重新验证也支持：

如果申请者后来修好了友链页面，只需要回复这个 Issue。
Workflow 会监听 issue_comment.created。
但只有 Issue 作者本人 的评论才会触发重新验证，避免别人乱刷。

二、这套系统的核心原理#

这套自动化其实不是“一个脚本干完所有事”，而是四层拼起来的：

1. GitHub Issue 模板负责收集表单#

你不需要自己写前端表单，也不需要数据库。

GitHub 自带的 Issue Forms 就能帮你把申请信息收上来。
用户填完表单后，GitHub 会把内容渲染成一段结构化文本，放进 Issue body。

我们后面的脚本做的事情，本质上就是：

读取 context.payload.issue.body
从里面解析出“网站名称 / 网站链接 / 友链页面 URL / 描述 / 头像”

所以第一层原理很朴素：

GitHub Issue 不是单纯的“提问题”，它也可以被当成一个零后端表单系统。

2. GitHub Actions 负责事件驱动#

第二层是 GitHub Actions。

它的职责不是写业务逻辑，而是：

监听事件
准备运行环境
安装依赖
调用真正的处理脚本

这里我们监听两个事件：

1
on:
2
  issues:
3
    types: [opened, reopened]
4
  issue_comment:
5
    types: [created]

这意味着：

新建 Issue 时自动跑一次
重新打开 Issue 时自动跑一次
在 Issue 下面评论时也会跑一次

但后面脚本里会再做一层筛选，只允许作者自己的评论触发重新验证。

3. `actions/github-script` 负责把 GitHub 上下文交给本地脚本#

很多人会把全部逻辑都塞进 YAML 里的 script: |，但这样很容易炸：

YAML 缩进难维护
JS 代码太长可读性差
混入 # 注释时容易直接变成语法错误
编码和引号很容易出坑

所以这次的做法是：

Workflow 里只保留一个很短的入口。
真实逻辑放到独立文件 .github/scripts/process-friend-request.cjs。

现在入口只有这一小段：

1
- name: Process friend request
2
  uses: actions/github-script@v7
3
  with:
4
    github-token: ${{ secrets.GITHUB_TOKEN }}
5
    script: |
6
      const path = require('node:path');
7
      const handler = require(path.join(process.env.GITHUB_WORKSPACE, '.github/scripts/process-friend-request.cjs'));
8
      await handler({ github, context, core });

这段代码只做一件事：

把 github、context 这些 GitHub Runtime 对象传给仓库里的本地脚本。

于是业务逻辑就从“YAML 内联脚本”变成了“普通 Node.js 文件”，维护体验会好很多。

4. Playwright 负责做浏览器级校验#

为什么不用 fetch 直接请求页面？

因为友链页面场景更适合浏览器级校验：

有些站点会跳转
有些内容是客户端渲染出来的
有些友链列表在真实 DOM 渲染后才出现
只看 HTML 源码不一定能确认页面最终长什么样

所以这里用了 Playwright：

1
const { chromium } = require("playwright");

校验逻辑分成两步：

用浏览器打开对方提供的友链页面
检查页面内容和页面上的所有链接里，是否出现本站域名或本站名称

也就是说它不是纯字符串比较，而是近似模拟了一个真实用户打开页面之后看到的结果。

三、当前实现依赖哪些文件#

如果你要在自己的项目里复刻这套系统，主要会改下面这些文件。

1. `.github/ISSUE_TEMPLATE/friend-request.yml`#

作用：定义“申请友链”表单。

这个文件负责告诉 GitHub：

模板标题是什么
默认标签是什么
需要用户填写哪些字段

你至少要保留这些字段：

网站名称
网站链接
友链页面 URL

描述和头像可以设为可选。

2. `.github/workflows/friend-link-checker.yml`#

作用：定义自动化工作流。

它主要负责：

监听 Issue / 评论事件
安装 Node.js
安装 pnpm
安装项目依赖
安装 Playwright Chromium
调用处理脚本

这个文件是系统的“总开关”。

3. `.github/scripts/process-friend-request.cjs`#

作用：真正的核心业务逻辑。

它做了几乎所有关键工作：

解析 Issue 内容
校验 URL
使用 Playwright 检查友链页
解析现有 friendsConfig.ts
生成新的友链对象
写回配置文件
运行 Biome 格式化
Git 提交与推送
在 Issue 里评论成功/失败
打标签和关闭 Issue

可以把它理解成这套系统的“应用层”。

4. `src/config/friendsConfig.ts`#

作用：真正保存友链数据。

这个仓库不是写入 JSON，而是直接更新 TypeScript 配置文件里的数组：

1
export const friendsConfig: FriendLink[] = [
2
  {
3
    title: "站点名",
4
    imgurl: "头像地址",
5
    desc: "描述",
6
    siteurl: "https://example.com/",
7
    tags: ["Blog"],
8
    weight: 10,
9
    enabled: true,
10
    issue_id: 123,
11
  },
12
];

所以自动化脚本必须知道这个文件的格式，并按它的结构生成内容。

5. `.github/workflows/biome.yml`#

作用：保证自动写入后的文件仍然符合代码格式规范。

这一步非常重要，因为如果脚本写入的内容格式不稳定，CI 会红，自动化虽然成功写入了数据，但 PR / 提交质量检查会挂掉。

四、完整执行链路#

这里按一次“用户申请友链”的真实时间顺序讲。

第 1 步：用户提交申请#

用户点击 GitHub Issue 模板，生成一条“友链申请” Issue。

Issue body 里会包含类似下面的结构：

1
### 网站名称
2
My Blog
3

4
### 网站链接
5
https://example.com
6

7
### 友链页面 URL
8
https://example.com/friends
9

10
### 网站描述
11
记录技术与生活
12

13
### 网站头像 URL
14
https://example.com/avatar.png

这一步不需要额外后端，GitHub 自己就帮你把数据存下来了。

第 2 步：Workflow 被触发#

.github/workflows/friend-link-checker.yml 被触发。

它会在 Ubuntu Runner 上做这些准备工作：

1
- uses: actions/checkout@v4
2
- uses: actions/setup-node@v4
3
- uses: pnpm/action-setup@v4
4
- run: pnpm install --frozen-lockfile
5
- run: pnpm exec playwright install --with-deps chromium

这几步分别解决：

拉代码
提供 Node 环境
提供 pnpm
安装仓库依赖
安装 Playwright 所需浏览器

第 3 步：脚本判断这是不是友链申请#

在 process-friend-request.cjs 里，脚本首先读取：

context.eventName
context.payload.action
context.payload.issue.body

然后判断：

1
const isFriendRequest = body.includes("### 网站名称") && body.includes("### 网站链接");

如果不是友链申请，直接跳过。

这样做的好处是：

这个 workflow 可以挂在 issues 事件上
但不会误处理其他普通 Issue

第 4 步：打“验证中”标签#

如果是新建或重新打开的 Issue，先打一个标签：

1
await github.rest.issues.addLabels({
2
  owner,
3
  repo,
4
  issue_number: issueNumber,
5
  labels: ["验证中"]
6
});

这一步主要是用户体验优化。

访客一看标签，就知道系统已经开始处理，不需要站长人工回复“我看到了”。

第 5 步：解析 Issue 表单#

解析逻辑在 parseIssueBody(body)。

这个函数做了两件事：

按 Markdown 标题识别字段
容忍一些不同写法

它会兼容这些字段名称：

网站名称 / 名称 / 站点名称
网站链接 / 站点链接 / 链接 / 网址 / 地址
友链页面 / 友链地址
网站描述 / 描述 / 简介
网站头像 / 头像 / 图标
网站标签 / 标签 / 分类

这样做的意义是：

模板稍微改字，不至于整套系统失效
用户手动编辑 Issue 内容时，也更不容易把解析搞崩

解析结束后会得到一个统一结构：

1
{
2
  site_name,
3
  site_url,
4
  friend_page_url,
5
  site_desc,
6
  site_avatar,
7
  site_tag
8
}

第 6 步：先校验 URL 合法性#

在真正访问网站前，脚本先用 new URL() 规范化地址：

1
function normalizeUrl(value) {
2
  try {
3
    return new URL(value.trim()).toString();
4
  } catch {
5
    return "";
6
  }
7
}

如果用户填了无效 URL，就直接回评，不继续往后跑。

这样能省掉很多无意义的浏览器启动和网络请求。

第 7 步：用 Playwright 校验友链页面#

validateFriendPage(pageUrl) 是整个流程最关键的函数之一。

它主要做四件事：

1. 启动无头 Chromium#

1
const browser = await chromium.launch({
2
  headless: true,
3
  args: ["--no-sandbox"]
4
});

2. 打开用户提供的友链页#

1
response = await page.goto(pageUrl, {
2
  waitUntil: "domcontentloaded",
3
  timeout: 12000
4
});

3. 做失败重试#

脚本不是只试一次，而是会重试 3 次，中间等待 2 秒。

这样能降低这类波动造成的误判：

短时网络抖动
对方站点首包慢
CDN 临时超时

4. 检查是否存在本站回链#

脚本会同时抓：

页面 HTML 内容
页面所有 a[href] 链接

然后统一转成小写，检查其中是否包含：

本站域名
本站名称

当前配置里是：

1
const SITE_INFO = {
2
  name: "fqzlr",
3
  url: "https://fqzlr.com/",
4
  avatar: "...",
5
  desc: "..."
6
};

于是脚本会重点寻找：

fqzlr.com
fqzlr

如果没找到，就说明“对方站点没有把你的友链真正挂上去”，申请不会通过。

第 8 步：失败时怎么处理#

如果友链页打不开，或者没找到本站回链，脚本不会静默失败，而是自动在 Issue 里评论。

失败时会分成两类文案：

页面不可访问#

会提示：

用户填写的友链页 URL
实际访问后的 URL
HTTP 状态码
错误信息

页面可访问，但没找到本站友链#

会提示：

没找到友链
请先在对方站点添加本站信息
附上本站名称、链接、头像、描述

同时还会给 Issue 打上：

1
needs-update

这样用户只要修完，再回评论，就能重新触发验证。

第 9 步：通过后如何写入 `friendsConfig.ts`#

通过验证后，系统会进入“写配置”阶段。

这一步主要由三个函数完成：

parseFriendsConfig(content)
renderFriend(friend, indent)
updateFriendsConfig(repoRoot, data, issueId)

为什么不是直接 `JSON.parse`#

因为这个文件是 TypeScript，不是纯 JSON。

它长这样：

1
export const friendsConfig: FriendLink[] = [
2
  {
3
    title: "xxx",
4
    imgurl: "xxx",
5
    desc: "xxx",
6
    siteurl: "xxx",
7
    tags: ["Blog"],
8
    weight: 10,
9
    enabled: true,
10
    issue_id: 1,
11
  },
12
];

注意几点：

属性名没加引号
带类型标注
可能带注释
不是合法 JSON

所以脚本不能这样写：

1
JSON.parse(match[1]);

这也是之前自动化里一个会继续引发报错的坑。

当前实现怎么做#

现在的实现是：

用正则先截出 friendsConfig 数组主体
再把每个对象块拆出来
分别抽取：
- title
- imgurl
- desc
- siteurl
- tags
- weight
- enabled
- issue_id
构造成 JS 对象数组
再渲染回 TypeScript 字面量

这是一种“结构感知但不依赖 TS AST”的轻量实现。

优点是简单、无额外编译依赖。
缺点是如果你未来把 friendsConfig.ts 改成完全不同的格式，正则也得跟着改。

第 10 步：新增还是覆盖，怎么判断#

脚本会根据 siteurl 判断这是不是已存在的友链：

1
const existingIndex = friends.findIndex(
2
  (friend) => trimTrailingSlash(friend.siteurl) === normalizedUrl
3
);

这里做了去尾斜杠处理：

https://example.com
https://example.com/

会被视为同一个站点。

如果已存在：

覆盖旧项

如果不存在：

push 新项

这样可以避免重复添加同一个网站。

第 11 步：为什么写完后还要再跑 Biome#

这是这次修复里非常关键的一步。

自动脚本虽然能写出结构正确的 TS，但不一定和仓库的 Biome 格式完全一致。
结果就是：

友链添加成功了
但 biome ci ./src 报 File content differs from formatting output

为了解决这个问题，我在脚本里加了一层：

1
formatFriendsConfig(repoRoot);

它会调用仓库自己的 Biome 可执行文件：

1
node_modules/.bin/biome

然后执行：

Terminal window

1
biome format --write src/config/friendsConfig.ts

这样自动生成的提交就会和仓库 CI 的格式要求一致。

这是把“写入成功”升级成“写入成功且能过 CI”的关键。

第 12 步：自动提交与推送#

通过验证并写入配置后，脚本会自动执行 Git 流程：

1
git config user.name "github-actions[bot]"
2
git config user.email "github-actions[bot]@users.noreply.github.com"
3
git add src/config/friendsConfig.ts
4
git commit -m "🤝 更新友链: 站点名"
5
git pull --rebase origin <default-branch>
6
git push origin HEAD:<default-branch>

这里有两个值得注意的点。

1. 为什么先 `pull --rebase`#

因为仓库有可能在 workflow 运行期间又被其他人提交了新内容。
如果直接 push，很容易出现：

1
! [rejected] master -> master (fetch first)

先 pull --rebase 可以降低这种失败概率。

2. 为什么不是强推#

自动化流程里不应该默认 --force。
因为它是服务流程，不是人工兜底流程。强推会增加误覆盖风险。

第 13 步：评论成功结果并关闭 Issue#

自动提交成功后，脚本还会回到 GitHub 上收尾：

评论“已成功添加友链”
移除“验证中”
移除 needs-update
关闭 Issue

关闭时使用的是：

1
await github.rest.issues.update({
2
  owner,
3
  repo,
4
  issue_number: issueNumber,
5
  state: "closed",
6
  state_reason: "completed"
7
});

这里要注意：

state 必须是 "closed"
不能写成 "completed"

completed 是 state_reason，不是 state

这也是这次修复里顺手纠正的一个 API 用法问题。

五、这次真正需要改哪些代码#

如果你也要照着搭一套，最少要改下面这些地方。

1. 修改 Issue 模板#

文件：

1
.github/ISSUE_TEMPLATE/friend-request.yml

你要根据自己的站点信息调整：

模板标题
默认标签
表单字段
“请先添加本站友链”的提示文案

如果你站点不是博客，还可以加更多字段，比如：

RSS 链接
站点分类
站长昵称
是否接受头像热链

2. 修改站点常量#

文件：

1
.github/scripts/process-friend-request.cjs

重点修改这里：

1
const SITE_INFO = {
2
  name: "fqzlr",
3
  url: "https://fqzlr.com/",
4
  avatar: "https://q1.qlogo.cn/g?b=qq&nk=20447289&s=640",
5
  desc: "坐而言不如起而行."
6
};

这是整个校验逻辑里“本站信息”的唯一可信来源。

它会影响：

是否判断回链存在
失败时给用户展示的本站友链信息

3. 修改友链数据文件路径#

如果你的友链配置不在当前路径，需要改这里：

1
const FRIENDS_CONFIG_RELATIVE_PATH = "src/config/friendsConfig.ts";

如果你用的是：

friends.json
data/friends.ts
src/content/friends.yaml

那解析和写入逻辑也要跟着改。

4. 修改配置文件字段映射#

当前脚本写入的是这个结构：

1
{
2
  title,
3
  imgurl,
4
  desc,
5
  siteurl,
6
  tags,
7
  weight,
8
  enabled,
9
  issue_id
10
}

如果你的项目使用的是别的字段，比如：

name
url
avatar
description

那就要同步调整：

parseFriendsConfig
renderFriend
updateFriendsConfig

这三个函数。

5. 修改 Workflow 权限#

当前 workflow 需要：

1
permissions:
2
  contents: write
3
  issues: write

原因是：

contents: write 用来提交代码
issues: write 用来评论、打标签、关闭 Issue

如果权限不够，会表现成：

能跑脚本
但不能回评
或者不能 push

6. 确保依赖安装方式和仓库一致#

这次还修了一组很典型的 CI 坑。

`pnpm/action-setup` 版本冲突#

如果你的 package.json 已经有：

1
"packageManager": "pnpm@9.14.4"

那么 workflow 里不要再写：

1
with:
2
  version: 9

否则会出现：

1
Multiple versions of pnpm specified

Biome 命令找不到#

不要依赖“全局有 biome 命令”。

更稳的方式是：

1
pnpm install --frozen-lockfile
2
pnpm exec biome ci ./src --reporter=github

这样 CI 使用的一定是仓库锁定的 Biome 版本。

六、为什么我把长逻辑挪出了 YAML#

这是这次改动里最值得保留的一个经验。

一开始如果把全部逻辑都写在：

1
script: |
2
  ...

里面，会有这些真实问题：

代码太长，维护困难
YAML 和 JS 的双层语法混在一起，调试痛苦
混入 # 注释时会直接触发 SyntaxError
编码、引号、缩进很容易造成“看起来没问题，运行就炸”

所以我最后采用的是：

Workflow 里只保留短入口
真正逻辑写进 .cjs 文件

这也是我给所有 GitHub Actions 复杂逻辑的建议：

YAML 负责调度，脚本文件负责业务。

不要让 YAML 同时承担“编排器”和“应用层代码容器”的职责。

七、这一套方案有哪些限制#

这套实现已经够实用，但它不是没有边界。

1. `friendsConfig.ts` 解析依赖当前格式#

现在是用正则和对象块拆分来处理 TS 配置。

所以如果你未来把友链配置改成：

嵌套更深
动态表达式更多
多行模板字符串
复杂注释结构

那解析函数需要一起升级。

更稳的长期方案有两个：

改成单独的 JSON / YAML 数据文件
用 TypeScript AST 或 Babel AST 解析

2. Playwright 校验是“近似真实浏览器”，但不是 100% 万能#

比如：

站点有地区限制
站点会拦 GitHub Actions Runner IP
页面需要登录
友链列表要滚动或点击后才出现

这些情况下仍可能误判。

如果你的网站遇到这种场景，可以进一步增强：

增加自定义等待策略
支持指定 CSS 选择器
支持截图附件
把失败截图上传到 Issue 评论

3. 自动 push 依赖仓库分支策略#

如果你的默认分支启用了非常严格的限制，比如：

不允许 GitHub Actions 写入
必须走 PR 合并
强制签名提交

那么脚本里的“直接提交并推送”就需要改造。

你可以改成：

自动创建分支
自动提交到新分支
自动开 PR

这样会更适合协作型仓库。

八、如果你要从零搭建，推荐照这个顺序做#

如果你不是在改现有项目，而是从零上手，我推荐按下面顺序来。

第 1 步：先确定友链数据存储格式#

先决定你最终要写入哪里：

JSON
YAML
TS 配置文件

这一步会直接决定后面脚本复杂度。

如果想最省事，我建议优先 JSON 或 YAML。
如果你已经有成熟的 TS 配置结构，也可以像 Firefly 这样继续沿用。

第 2 步：先把 Issue 模板做好#

不要一上来就写脚本。
先确保用户提交的内容结构稳定。

因为自动化流程的第一输入，其实就是 Issue body。

第 3 步：先做“只解析不写入”#

先写一个最小脚本，只做：

读取 Issue 内容
解析字段
在日志里打印结果

这样先确认字段提取没问题，再往后接浏览器校验和写文件。

第 4 步：接入 Playwright 校验#

等字段解析稳定后，再加：

URL 检查
页面是否可访问
页面里是否包含本站回链

不要一开始把所有事情混在一块写，不然后期很难排错。

第 5 步：最后再接 Git 提交#

真正危险的是自动提交阶段。
我建议把“解析”和“校验”完全确认稳定后，再开放：

写文件
git add
git commit
git push

否则一开始就自动 push，调试时很容易把仓库历史搞脏。

九、这次踩过的坑，顺手给你避掉#

这里把这次实际遇到的问题总结一下。

1. `actions/github-script` 里的 JS 不是 Shell#

script: | 里面只能写 JS，不能混进：

1
# 注释

这种 Shell 风格注释。
否则会直接触发：

1
SyntaxError: Invalid or unexpected token

2. TS 配置文件不能直接 `JSON.parse`#

friendsConfig.ts 是 TypeScript 对象字面量，不是 JSON。

只要你文件里有：

类型标注
非引号属性名
注释

它就不可能直接被 JSON.parse。

3. 自动写入后的文件必须再格式化#

脚本“能写进去”不等于“能过 CI”。

格式化是必须的，不是锦上添花。

4. `pnpm/action-setup` 和 `packageManager` 不能双重声明版本#

如果 package.json 已经写了：

1
"packageManager": "pnpm@9.14.4"

workflow 里就不要重复写 version。

5. Cloudflare 机器人会检查 `wrangler.jsonc` 的 Worker 名称#

如果你的项目名已经改成 firefly，但 wrangler.jsonc 里还是：

1
"name": "fuwari"

Cloudflare 的机器人 PR 会持续提醒你更新。

所以这次也顺手把：

1
"name": "fuwari"

改成了：

1
"name": "firefly"

十、我对这套方案的建议#

如果你只是个人博客，这套方案已经够用，而且很优雅：

没有数据库
没有后端服务
没有额外部署成本
审核门槛低
自动化程度高

它利用的其实都是 GitHub 现成能力：

Issue Forms
Actions
github-script
仓库写权限

再加上一个 Playwright，就能拼出相当完整的业务闭环。

如果你以后还想继续增强，我建议优先加这几项：

失败时自动截图并贴到评论
自动创建 PR，而不是直接推默认分支
将友链数据迁移到单独的 JSON / YAML 文件
支持白名单域名 / 黑名单域名
支持自动去重、自动排序、自动补充默认头像

十一、本文对应的关键文件清单#

方便你对照仓库直接看：

.github/ISSUE_TEMPLATE/friend-request.yml
.github/workflows/friend-link-checker.yml
.github/scripts/process-friend-request.cjs
src/config/friendsConfig.ts
.github/workflows/biome.yml
wrangler.jsonc

十二、结语#

这套“友链自助申请”方案本质上是把 GitHub 当成了一个轻量业务平台来用：

用 Issue 表单承接输入
用 Actions 承接流程
用脚本承接业务判断
用仓库文件承接数据落地

没有后端，也能把流程做完整。
对个人博客和轻量站点来说，这种思路非常值。

如果你正在做自己的博客系统，或者想把原本人工处理的流程逐步自动化，我很推荐从这种“基于 Git 仓库自身能力”的方案开始搭。

悬溺一响，他把真心说出口，她却轻轻放下了

Wed, 22 Apr 2026 00:00:00 GMT

悬溺一响，他把真心说出口，她却轻轻放下了#

音频：悬溺一响，纯爱登场 / 春风不语人

喜欢一个人很容易，心动、靠近、暧昧，都可以叫喜欢。可真心去爱一个人很难，因为爱不是嘴上说说，而是记得、看见、行动，是把一个人放进生活里。只是有些真心，来得太干净，所以才会被人轻易忽略。

悬溺一响，纯爱登场。

有些歌不是一听就哭，而是它响起来的时候，你会突然想起一个人。

想起那年夏天，活动室里坏掉的投影仪，走廊尽头没关的灯，社团教室里堆满的展板，还有一个人站在人群里，低头认真写字的样子。

年轻时候的喜欢，其实很简单。

简单到看见她，就想靠近她。

简单到她回头看你一眼，你就觉得自己好像被这个世界轻轻选中了一次。

简单到不需要什么条件，不需要什么权衡，也不需要一遍遍问自己“值不值得”。

那时候喜欢一个人，是很热烈的。

想见她，就去见。

想对她好，就去做。

想让她知道，就努力攒够勇气说出口。

后来有人说，《悬溺》像“宣你”。

宣你。

我喜欢你。

这两个字听起来轻，可真正说出口的人，往往用了很久，才把那颗心从胸口捧出来。

可惜，有些真心递出去的时候，对方只是看了一眼。

然后轻轻放下了。

他一直都记得，自己是从哪一天开始喜欢她的。

大一那年，社团第一次做校园短片放映。

那天晚上，活动室突然停电，投影仪黑了，屋子里乱成一团。

他第一次负责设备，手忙脚乱地蹲在地上找线，越急越找不到接口。

有人在后面催：

“到底能不能弄好啊？”

他当时脸都热了。

就在他快撑不住的时候，她走过来，把手机手电筒打开，蹲在旁边帮他照着接口。

她没有催他。

只是很轻地说了一句：

“你慢慢来，别慌，我帮你挡一下光。”

那句话很普通。

可他记了很久。

后来投影仪重新亮起来，大家都松了一口气，她站起身，拍了拍手上的灰，对他说：

“挺厉害啊，救场成功。”

他那天没怎么说话。

只是后来很久以后，他还记得她蹲在地上的样子。

记得手机光照在她侧脸上。

记得她没有把他的慌乱当笑话。

也记得自己那一刻心里突然冒出来的念头：

这个女生，好像真的很温柔。

不是那种故意表现出来的温柔。

而是在人尴尬的时候，会自然伸手接住一下的温柔。

他就是从那天开始喜欢她的。

不是不知不觉。

是很清楚。

是九月二十七号，晚上八点多，活动室停电，她蹲下来帮他照光的那一刻。

后来他们熟起来，是因为社团要拍一组校园短片。

他负责拍摄，她负责文案。

他们经常一起坐在活动室改脚本。

她写东西很认真，写到不满意的时候，会把笔帽咬出一点浅浅的印子。

他发现以后，后来每次开会都会多带一支笔。

不是送给她。

只是放在桌上。

她需要的时候，他就推过去。

有一次她写旁白写到很晚，整个人趴在桌上，说：

“我感觉这段怎么写都不对。”

他没有立刻接过来改。

而是问她：

“你想让看到这段的人记住什么？”

她愣了一下。

然后他们从晚上八点聊到十一点。

那一晚，活动室最后只剩他们两个人。

窗外清洁阿姨拖地的声音一下一下传进来。

她把修改好的稿子读给他听。

读到最后一句时，她自己笑了，说：

“好像终于顺了。”

他也笑。

那一刻，他觉得他们之间不是只有他一个人在靠近。

他们是真的一起做过一件事。

一起熬过夜。

一起改过稿。

一起为了一个别人可能看几分钟就划走的视频，认真争论过一个词到底该不该换。

这也是后来他一直放不下的原因。

如果她从一开始就冷淡，他可能不会那么陷进去。

可她曾经给过他很多像是靠近的瞬间。

她会在他拍摄时提醒他：

“你今天手好像有点抖，是不是没休息好？”

她会在他剪片剪到崩溃时，把耳机递给他，说：

“听这个，别一直绷着。”

她会在他被老师批评画面太暗的时候，等老师走后，小声说：

“其实我觉得你那个镜头挺好看的，只是他们没看懂。”

这些话不重。

却刚好落在他最需要被肯定的时候。

所以他后来才会以为，她也许也是在意他的。

只是没有那么明显。

可成年人后来都会明白：

有些人给你的温柔，不一定是爱。

有些人愿意和你并肩做事，也不代表她愿意和你并肩走下去。

那年冬天，社团要做年终短片。

她说自己不喜欢被镜头拍到正脸。

因为她觉得自己不够上镜。

他说：

“那我不拍你正脸。”

她问：

“那怎么拍？”

他说：

“拍你写字的手，拍你低头看稿子的样子，拍你走在走廊里被光照到的背影。”

她笑他说：

“你还挺会说。”

可他不是会说。

他是真的这样看她。

他觉得她整理稿子时用手压住纸角的动作很好看。

觉得她认真听别人讲话时微微偏头的样子很好看。

觉得她站在窗边改文案，头发被风吹乱，也很好看。

后来那支短片放出来的时候，很多人都说画面很有感觉。

她也很喜欢。

她指着其中几个镜头说：

“这几个拍得好好。”

他当时坐在旁边，心跳很快。

因为那几个镜头，全是他最用心拍她的部分。

可她不知道。

她只是觉得画面好看。

不知道他为了等走廊那束光，提前在那里站了半个小时。

不知道他反复剪掉她可能会不喜欢的角度。

不知道他把她不自信的地方都小心避开，只留下她最自然的样子。

他没有说。

因为有些喜欢太细了。

细到说出来像邀功。

不说出来又没人知道。

爱一个人最难受的地方，有时候不是你没有付出。

而是你付出的心思太轻、太隐秘、太怕打扰。

轻到对方只看见了结果。

看不见你藏在里面的爱。

真正让他决定表白，是在毕业前的最后一次社团聚餐后。

那天晚上，大家吃完饭，从店里出来。

外面刚下过雨，地面有一层很浅的水光。

他们慢慢往学校走。

一路上，有人说以后要去哪里实习，有人说以后可能很难再聚了。

她走在他旁边，低头看手机。

他看着她，忽然觉得如果再不说，可能这辈子就真的只剩遗憾了。

到了学校后门那条小路，他叫住她。

她问：

“怎么了？”

他沉默了很久。

不是不知道说什么。

而是知道自己接下来每一句话，都可能把他们推到另一个关系里。

他最后还是开口了。

他说：

“我喜欢你，是从九月二十七号那天晚上开始的。”

她愣了一下。

他继续说：

“就是活动室停电那晚，我蹲在地上修投影，大家都在催，我很慌。你蹲下来帮我照光，跟我说，别慌。”

“我那时候就觉得，你这个人好像很不一样。”

“后来一起改短片的时候，你说我那个镜头不是拍得不好，只是他们没看懂。其实那天我真的挺难受的，是你那句话让我觉得，我好像还能继续拍下去。”

“还有那次我们改稿改到很晚，你读完最后一句，笑着说终于顺了。我当时看着你，心里就在想，如果以后还能和你一起做很多事，好像也挺好。”

他停了一下，声音有点哑。

“我不是因为你长得好看才喜欢你。”

“当然你很好看，但真正让我喜欢你的，是你做事认真，是你会照顾别人的尴尬，是你明明也会紧张，却还是愿意把事情做好。”

“我喜欢你，不是想让你觉得有压力。”

“也不是想用我对你的好，换一个结果。”

“我只是想很认真地告诉你，我不是对谁都这样。”

“我记得你不喜欢被拍正脸，所以每次镜头里有你，我都会避开让你不舒服的角度。”

“我记得你写稿子卡住的时候会咬笔帽，所以后来我总会多带一支笔。”

“我记得你说自己怕被否定，所以你每次站上台前，我都希望你能多一点底气。”

“这些事可能都很小。”

“但对我来说，每一件都是真的。”

“我喜欢你，也想更认真地了解你。”

“如果你愿意，我们可以慢慢来。”

“如果你不愿意，我也会尊重你。”

“但我不想毕业以后再假装无所谓地说，其实我当年差一点就说出口了。”

“我不想让自己后悔。”

那一刻，他几乎把所有勇气都用完了。

没有夸张的承诺。

没有“我会永远爱你”这种听起来很大的话。

只是把他们之间发生过的那些细节，一件一件说出来。

像把一颗心慢慢打开。

可她听完以后，只是低头看了一眼手机。

然后有点尴尬地笑了笑。

她说：

“你别这样。”

四个字。

很轻。

轻到像一句随口的提醒。

却把他攒了很久的勇气，轻轻按了回去。

她又说：

“我真的一直把你当朋友。”

“你人很好，但我对你没有那种感觉。”

“而且快毕业了，我们还是别把关系弄复杂吧。”

他点点头。

说：

“好，我知道了。”

其实他知道。

不喜欢就是不喜欢。

不爱就是不爱。

她有拒绝的权利。

真正让他难过的，不是她拒绝他。

而是他把那么多共同经历讲给她听，她却好像只想快点把这个场面结束。

他很认真地打开了自己。

她很轻易地把门关上了。

表白以后，他没有纠缠。

也没有问她为什么。

因为答案已经很清楚了。

只是后来发生的一件小事，让他彻底放下了。

毕业展那天，他们社团的人一起合影。

有人问他以后去哪个城市工作。

他说了一个名字。

她在旁边愣了一下，问：

“你不是准备留在本地吗？”

他看着她，忽然不知道该怎么回答。

其实他早就说过很多次。

他想去南方。

想做影像相关的工作。

想先攒钱买一台真正属于自己的相机。

他也说过，家里不太支持他做这行，所以他一直压力很大。

这些话，他都跟她讲过。

不是只讲过一次。

可她不记得。

她记得他会帮她改片子。

记得他会在需要时出现。

记得他脾气好，不会让人难堪。

却不记得他想去哪里。

不记得他害怕什么。

不记得他真正想成为怎样的人。

那一刻，比表白被拒还疼。

因为他终于明白：

他一直在认真了解她。

可她从来没有真正了解过他。

爱与不爱，真的一眼就能看出来。

喜欢你的人，会记得你的方向。

会关心你的难处。

会把你的分享当成一件重要的事。

不喜欢你的人，也许不会故意伤害你。

但她不会把你放进心里。

你说过的话，她听过就算了。

你给过的真心，她收下就算了。

你藏在细节里的爱，她看见了，也不会往深处想。

因为你不是她想了解的人。

所以你的一切，对她来说，都没有那么重要。

后来他才知道，她不是不会喜欢人。

也不是不会主动。

她只是不会对他主动。

她会为了另一个男生，提前查对方喜欢的电影。

会记得那个人什么时候面试。

会在对方说压力大的时候，写一大段安慰的话。

会因为那个人一句“最近状态不好”，专门约他出来散步。

他看见过一次她的朋友圈。

配图是一张很普通的夜景。

文案只有一句：

“别怕，我一直在。”

那句话，他看了很久。

因为他曾经也很想听她对自己说一句：

“我一直在。”

可她没有。

原来她不是不懂回应。

她只是不想回应他。

原来她不是慢热。

她只是对他不热。

原来她不是不会在意一个人的情绪。

她只是没有在意他的情绪。

他不怪她喜欢别人。

感情从来不能勉强。

可他终于承认，自己这些年所有的希望，很多时候都是自己替她找的理由。

她对他温柔过。

也和他一起认真做过事。

可那些都不是爱。

至少不是他想要的那种爱。

他离开的时候，没有告别，只删掉了那个文件夹

后来，他慢慢不再出现。

不是赌气。

也不是故意冷落。

是真的累了。

她找他帮忙，他会说：

“我最近可能不太方便。”

她发消息问他能不能看看一个文件，他会晚一点再回。

语气还是礼貌。

但已经没有以前那种随时奔向她的热烈。

她一开始没有发现。

因为她习惯了他的好。

习惯了自己需要的时候，他总会在。

直到有一天，她问：

“你最近是不是变了？”

他看着那句话，突然笑了一下。

他变了吗？

其实不是。

只是他终于把那个围着她转的自己，一点点收回来了。

那天晚上，他打开电脑，删掉了一个文件夹。

文件夹名字叫：

“社团素材备份”。

里面有很多东西。

他们一起改过的脚本。

那支年终短片的分镜。

她不喜欢正脸镜头的备注。

他为她保留下来的那些背影。

还有一张他一直没有发给她的照片。

照片里，她坐在活动室窗边写稿，低着头，光落在她肩上。

他看了很久。

最后还是点了删除。

系统弹出提示：

“是否确认永久删除？”

他停了很久。

然后点了确认。

没有声音。

没有仪式。

可那一刻，他心里有一场很大的告别。

不是告别她。

是告别那个曾经很热烈、很认真、很勇敢地爱过她的自己。

很多年后，她也谈过几段恋爱。

有人说喜欢她，却记不住她认真讲过的话。

有人追她时很热烈，得到以后慢慢冷淡。

有人送她很贵的礼物，却不知道她真正害怕什么。

也有人在她狼狈的时候，根本没有耐心听她说完。

她慢慢发现，被喜欢并不难。

被短暂心动也不难。

难的是，有个人真的愿意了解你。

愿意记得你。

愿意在你不自信的时候，用很笨拙的方式告诉你：

你已经很好了。

某个夜里，她听到《悬溺》。

前奏响起来的时候，她突然想起很多年前那个男生。

想起他说：

“我喜欢你，是从九月二十七号那天晚上开始的。”

想起他说：

“我不想毕业以后再假装无所谓地说，其实我当年差一点就说出口了。”

她忽然明白。

原来那不是普通的表白。

那是一个人把他们之间所有细节都记在心里以后，认真交出来的一颗心。

只是那时候，她太年轻，也太习惯被偏爱。

所以误以为那种真心并不稀缺。

直到后来再也遇不到，才知道那不是普通的好。

那是一个人把最柔软、最干净、最没有防备的一面交到了她面前。

可她没有接住。

不喜欢一个人，没有错。

不爱一个人，也没有错。

感情里，每个人都有拒绝的权利。

但真正伤人的，是明明不爱，却享受别人对你的好。

明明不喜欢，却舍不得失去那个一直回应你的人。

明明不会选择他，却让他一直误以为自己还有机会。

喜欢很容易。

一次心动，一段暧昧，一句“我觉得你很好”，都可以叫喜欢。

可爱很难。

爱是记得。

是看见。

是行动。

是你愿意认真了解一个人，也愿意尊重一个人的真心。

更是你在不被珍惜的时候，终于懂得把自己收回来。

所以，别轻易消耗一个真心爱你的人。

也别把自己的真心，一次次交给一个不在意你的人。

纯爱不是卑微。

不是讨好。

也不是没有自尊地一直等。

真正的纯爱，是我曾经勇敢、热烈、认真地爱过你。

但当我知道你不爱我，我也会慢慢学着放过自己。

悬溺一响，纯爱登场。

可真正值得被记住的，不是那段没有结果的关系。

而是我们终于明白：

爱是这个世界上很珍贵的东西。

得到它的人，要懂得珍惜。

付出它的人，也要学会清醒。

因为真正好的感情，从来不是一个人拼命靠近，另一个人心安理得接受。

而是你的真心有人看见。

你的勇敢有人回应。

你的爱，刚好落在一个也愿意爱你的人心里。

原文发布于微信公众号合集《每晚一首歌，聊点成年人不说的话》。

先说谎的人，后来连真心都像假的

Tue, 21 Apr 2026 00:00:00 GMT

先说谎的人，后来连真心都像假的#

音频：在感情里先说谎的人，最后一定会输得一败涂地 / 春风不语人

“被爱的那个人是我，先说谎那个人是我。”

后来她才明白，最痛的不是一个人不爱你。

而是你曾经那么认真地相信过他。

相信他的温柔。

相信他的靠近。

相信他说的每一句“我懂你”。

可到最后你才发现。

那些让你一遍遍心软的瞬间，原来从一开始，就藏着一个你不知道的谎。

那种感觉，像是有人把你们所有的回忆重新翻出来，一页一页告诉你：

你以为的心动，不一定是真的。

你以为的被懂，也不一定是因为爱。

你以为自己终于被认真珍惜。

可后来才知道。

有些温柔，早就被明码标价过。

我见过一段这样的感情。

男生和女生是在一次朋友聚会上认识的。

那天晚上，人很多。

大家坐在一起吃饭、聊天、开玩笑。

女生话不算多。

别人聊得热闹，她就安静地听。

偶尔被点到名字，才低头笑一下，轻轻接两句。

她不是那种一眼就特别张扬的人。

可她身上有一种很干净的安静。

让人想靠近，又怕打扰。

男生就是那天注意到她的。

聚会结束后，朋友起哄让大家互相加微信。

他加到她的时候，手心都有点出汗。

回到家以后，他盯着她的头像看了很久。

输入框里打了又删。

“今天认识你很开心。”

太刻意。

“下次有空一起吃饭？”

又怕显得太急。

“你到家了吗？”

好像又太普通。

最后，他只发了一句：

“到家了吗？”

女生回：

“到了，谢谢。”

然后聊天就停在那里。

他看着那个对话框，等了很久，也不知道下一句该怎么接。

他是真的喜欢她。

可他太笨了。

他不知道女生回“嗯嗯”的时候，是不想聊了，还是只是暂时不知道说什么。

不知道女生说“还好”，是真的还好，还是希望有人多问一句。

不知道怎么关心才不显得油腻。

也不知道怎么主动才不会让人有压力。

那几天，他一直想找她聊天。

可每次打开对话框，又觉得自己像一个很无聊的人。

后来，他刷到一个情感博主的视频。

视频标题很刺眼：

“真正会聊天的人，不是会说情话，而是会让对方感觉自己被看见。”

他点进去看了很久。

博主说：

“一个人最容易心动的瞬间，不是听见你说喜欢她。”

“而是她突然发现，你好像读懂了她自己都没说清楚的那部分。”

男生像抓住了一根救命绳。

他私信了那个博主。

对方很快回复：

“可以做聊天指导，也可以代聊。”

“前期我帮你建立关系里的安全感，后期你自己接。”

男生犹豫了很久。

最后还是转了一笔钱。

他给自己找了一个很合理的借口：

“我只是不会表达，不是想骗她。”

“我只是想多一个机会。”

“等她愿意了解我了，我会自己好好对她。”

可很多后来无法挽回的错，都是从这句“我只是想多一个机会”开始的。

从那天开始，男生会把聊天截图发给那个博主。

一开始，他以为对方会教他怎么幽默，怎么暧昧，怎么让女生秒回。

可博主没有让他急着表白。

也没有让他说那些很满的话。

对方只让他做一件事：

先别追。

先看懂她。

博主告诉他：

“很多人聊天，只会回应表面。”

“她说累，你回辛苦了。”

“她说烦，你问怎么了。”

“她说没事，你就真的信了。”

“可真正让人心动的，不是你听见了她说什么，而是你听懂了她为什么这么说。”

男生第一次听到这些话的时候，愣了很久。

因为他以前真的只会回：

“早点休息。”

“别想太多。”

“明天会好的。”

可这些话太轻了。

轻到接不住一个人真正的委屈。

有一天，女生发来一句：

“今天方案又被领导改了，感觉白忙了。”

如果是以前，男生大概只会回：

“没事，下次会更好。”

可那次，他按照博主给的方向，回了另一句话：

“你难受的可能不是方案被改。”

“是你认真做了很久的东西，好像又被轻轻带过了。”

“那种感觉不是白忙。”

“是你的认真，暂时还没被看见。”

女生那边沉默了很久。

最后回：

“你怎么每次都能说到我心里。”

男生看着这句话，心跳得很快。

他开心。

也心虚。

因为真正说中她的人，不是他。

还有一次，女生说：

“我感觉自己挺麻烦的。”

男生刚想回：

“不麻烦，我愿意听你说。”

可博主提醒他：

“不要急着否认她。”

“她说自己麻烦，不是真的想听你说不麻烦。”

“她是在试探，你会不会有一天也觉得她麻烦。”

于是男生发：

“你不用急着证明自己不麻烦。”

“如果你今天就是乱一点、脆弱一点、话多一点，也没关系。”

“你不用每次都整理好了情绪，才来找我。”

女生看完后，隔了十几分钟才回：

“这句话，真的有点犯规。”

男生盯着屏幕笑了很久。

他以为自己终于学会爱人了。

可其实，他只是学会了怎么让一个人误以为自己被爱。

后来，那个博主教他的东西越来越细。

不是简单地“秒回”。

而是告诉他，真正让人放下防备的，不是热烈。

是低压。

你不能让她觉得，你一直在等她。

那会变成压力。

你也不能让她觉得，你随时会消失。

那会变成不安。

你要让她觉得：

你有自己的生活。

但你心里给她留了位置。

所以，女生忙到很晚才回消息时，男生不会说：

“你怎么现在才回？”

也不会说：

“我等你很久了。”

他只会回：

“刚刚看见消息。”

“猜你今天应该被事情缠住了。”

“你不用因为晚回我有负担，我不是来增加你压力的。”

女生第一次看到这句话时，心里突然软了一下。

因为她太怕亏欠别人。

太怕别人的等待，最后变成责备。

而这个人好像刚好懂。

还有一次，女生只是随口说了一句：

“我每周三开会都很累。”

她自己都快忘了。

可博主让男生记下来。

他说：

“这不是信息，这是情绪坐标。”

“以后每个周三，你不用说太多。”

“只要在她最容易疲惫的时候出现一次。”

“人会对稳定出现的温柔产生记忆。”

于是，下一个周三晚上，男生发了一句：

“今天是不是又开例会了？”

“如果现在有点被消耗，不用急着说。”

“先回家，洗个热水澡。”

“等你缓过来了，再把今天最难受的那一段讲给我听。”

女生看着这条消息，突然鼻子发酸。

因为那一刻，她真的以为：

他把她放在心上了。

可她不知道，男生的备忘录里，有一页专门写着她。

不是浪漫的记录。

而是一张被整理过的“情绪地图”。

上面写着：

周三例会，容易低落。

怕麻烦别人，所以不能给压力。

说“没事”时，大概率是在撤退。

害怕被忽略，但不喜欢直接索取陪伴。

被否定后，第一反应是怀疑自己。

适合低压陪伴，不适合强行追问。

这些词，看起来很专业。

也很准确。

可越准确，后来越伤人。

因为女生以为这是爱里的细心。

其实一开始，那是别人帮他做的分析。

她越来越觉得，他和别人不一样。

别人只看见她说了什么。

他好像能看见她为什么这么说。

别人只问她发生了什么。

他好像能看见她在那件事里，怎么把自己弄疼了。

这才是最容易让人心动的地方。

不是被哄。

是被看见。

可最残忍的也在这里。

后来她才知道。

她以为的“被看见”，有一部分，是被研究。

一开始，男生只是想追到她。

他想过，等关系稳定一点，就不再让那个博主帮忙。

可他没想到，女生会那么认真。

她开始记得他的喜好。

知道他不爱吃太甜的东西。

知道他紧张的时候会抠手指。

知道他现实里其实不太会说漂亮话。

她甚至觉得这种反差很可爱。

有一次见面，女生看着他笑：

“你好奇怪，微信上那么会说，见面的时候又有点笨。”

男生愣了一下，只能跟着笑。

他不敢解释。

因为他知道，微信上那个温柔、稳定、很懂她的人，有一部分不是自己。

可后来，他真的动心了。

不是因为技巧。

不是因为话术。

而是因为女生太真诚了。

有一次，他只是随口说自己头疼。

女生下班后绕了很远的路，给他买药。

她没有说什么煽情的话。

只是把药递给他，说：

“你记得吃，别又硬撑。”

那一刻，男生突然很难受。

因为他发现，自己一开始是用技巧靠近她的。

可她是用真心对他的。

后来，他开始不只是照着别人给的话术回复。

他会真的担心她有没有吃饭。

真的记得她每周三开会后情绪容易低落。

真的因为她一句“今天不太开心”，放下手里的事陪她很久。

他甚至慢慢能听懂她的沉默。

知道她说“随便”时，其实是在等一个坚定的答案。

知道她说“没关系”时，其实已经失望过一次。

知道她突然不说话，不是想冷战，而是在等他靠近一点。

可越是这样，他越不敢坦白。

因为他已经没有办法把真相说得轻描淡写。

他不能说：

“其实我们刚开始聊天的时候，很多话不是我想的。”

他不能说：

“你第一次心动的那句安慰，是别人教我的。”

他不能说：

“你以为我很懂你，其实是我把你的聊天记录发给别人分析过。”

这太残忍了。

残忍到他自己都不敢面对。

于是他继续骗。

他告诉自己：

“现在不一样了。”

“我后来是真的。”

“那些话虽然不是我想的，但我的喜欢是真的。”

可感情里最无力的地方就在这里。

你不能因为后来真的爱了，就假装一开始没有骗。

女生不是突然发现真相的。

她是一点一点察觉到不对劲的。

微信里的他，像一个很成熟、很稳定、很懂情绪的人。

可现实里的他，常常笨得让人陌生。

她难过的时候，坐在他旁边不说话。

他会慌。

会问：

“那你现在想怎么办？”

会忍不住讲道理。

会说：

“其实你也别想太多。”

女生听到这句话时，心里会轻轻沉一下。

因为微信上的他，从来不会这样说。

微信上的他总能越过事情本身，直接说中她真正难过的地方。

可现实里的他，像一个临时被拉上场的人。

不知道什么时候该抱她。

不知道一句话说错以后，为什么她突然安静。

有一次，两个人坐在出租车后排。

外面下着雨，车窗上全是水痕。

女生突然问他：

“你还记得你之前说过，我不是麻烦，只是太久没有被好好回应过吗？”

男生明显顿了一下。

然后说：

“我说过这个吗？”

那一刻，女生的心像被轻轻刺了一下。

因为那句话，她记了很久。

那是她第一次觉得，自己不是累赘。

那是她第一次觉得，有人真的懂她那些别扭和敏感。

可他竟然不记得。

后来，真正拆穿一切的，是一个很普通的晚上。

男生去洗澡，手机放在桌上。

屏幕亮了。

备注是：

“聊天导师。”

消息弹出来：

“她这次不是生气，是在确认你会不会因为她的情绪而后退。”

第二条紧跟着跳出来：

“把她刚才说的话截图给我，我帮你拆她真正想被回应的点。”

女生坐在那里，手指一下子凉了。

她没有立刻点开。

也没有大喊。

只是看着那两条消息，整个人像被按进了很深的水里。

那一刻，她突然想起很多事。

想起他说“你不用证明自己不麻烦”的那晚。

想起他说“我不是来增加你压力”的下午。

想起他说“你可以在我这里不用懂事”的深夜。

想起她曾经因为这些话偷偷哭过，偷偷心软过，偷偷觉得自己终于被人珍惜过。

可现在，她才知道。

那些让她反复回味的温柔，

那些让她一次次卸下防备的话，

那些她以为只属于自己的偏爱，

背后可能都有另一个人看过、拆过、改过。

男生出来的时候，看见她的表情，就知道瞒不住了。

他慌着解释：

“我一开始只是不会聊天。”

“我真的喜欢你，我只是怕说错话。”

“后来不一样了，后来很多话都是我自己想说的。”

女生看着他，眼睛很红。

她问：

“所以我跟你说过的那些事，你都给别人看了？”

男生说不出话。

她又问：

“我说我害怕被丢下的时候，也是他教你怎么回的吗？”

男生还是沉默。

女生轻轻笑了一下。

那个笑，比哭还疼。

她说：

“我一直以为你是懂我。”

“原来你只是找了一个更懂女生的人，来替你懂我。”

那天晚上，女生没有立刻崩溃。

她只是坐在那里，很久很久没有说话。

不是不痛。

是痛到不知道该从哪里开始问。

她想起自己曾经那么小心地把心事讲给他听。

那些她不愿意告诉朋友的话。

那些她藏了很久的委屈。

那些她一边打字一边删掉，又鼓起勇气发出去的脆弱。

原来没有只停在他那里。

它们被截图。

被转发。

被分析。

被别人总结成一句：

“她是敏感型，需要稳定但不压迫的回应。”

她忽然觉得很难堪。

不是因为自己爱错了人。

而是因为自己曾经那么认真地相信，那些温柔只属于她。

男生坐在她对面，不停解释。

他说：

“我一开始是真的喜欢你。”

“我只是不会聊天。”

“我怕自己说错话，怕你不理我。”

“我承认刚开始是他帮我回的，可后来很多话都是我自己想说的。”

“我后来是真的爱你。”

女生听着，眼泪终于掉下来。

她说：

“其实你一开始笨一点，我不会怪你。”

“你不会聊天，我可以慢慢告诉你。”

“你不懂我，我也可以慢慢让你懂。”

“可是你不该让别人替你走进我心里。”

“更不该把我那些只敢告诉你的脆弱，拿去变成追我的方法。”

男生站在那里，一句话都说不出来。

因为他终于明白。

有些人不是不能接受你的笨拙。

她不能接受的是，你用别人的聪明，骗走了她的真心。

女生离开的时候，没有说狠话。

她只是把自己的东西收好。

牙刷。

护手霜。

一件留在他家的外套。

还有那张他们一起拍的大头贴。

她拿起来看了一眼，最后还是放下了。

男生声音发抖地说：

“我真的爱你。”

女生停了一下，没有回头。

她说：

“我知道你后来可能是真的。”

“可是我一想到我是被别人教你怎么爱上的，我就没办法继续了。”

这句话，成了男生很久都走不出来的结。

他后来才明白。

有些欺骗，不是你编了多大的谎。

而是你让一个人误以为：

她被你真诚地爱着。

可其实一开始，你连怎么靠近她，都是别人替你设计好的。

你以为自己只是不会聊天。

只是找人帮忙。

只是想把喜欢的人留住。

可对她来说，那不是帮忙。

那是入侵。

是她最私密的情绪，被拿去当成追求攻略。

是她最真实的心动，建立在一场不属于你的温柔里。

所以后来你再说爱，她会怕。

你再说心疼，她会怀疑。

你再说“这次真的是我自己想说的”，她也不知道该不该信。

因为先说谎的人，最痛的地方就在这里：

不是你后来没有真心。

而是你的真心，被你一开始的谎，弄脏了。

如果一开始，他笨一点也没关系。

不会聊天也没关系。

说错话也没关系。

他可以慢慢学。

可以真诚一点。

可以笨拙但干净地靠近她。

可他偏偏选了最坏的方式。

他用别人写好的温柔，换来了她真的心动。

又在后来真的爱上她时，失去了证明自己的资格。

感情里，最珍贵的从来不是你有多会说话。

而是你说出口的每一句，都是你自己。

笨拙没有关系。

不完美也没有关系。

真正让人心寒的，是你假装成一个很懂爱的人，让别人把真心交给了一个并不真实的你。

所以啊。

愿我们以后遇见的爱，

不用靠话术维持，

不用靠套路推进，

不用让第三个人教你怎么心疼我。

愿那个爱你的人，

哪怕笨一点，慢一点，不会说漂亮话，

也从一开始，

就真实地走向你。

原文发布于微信公众号合集《每晚一首歌，聊点成年人不说的话》。

明明就还爱，为啥最后还是散了

Mon, 20 Apr 2026 00:00:00 GMT

明明就还爱，为啥最后还是散了#

音频：明明就很喜欢，但最后还是走散了 / 春风不语人

以前听周杰伦《明明就》，总觉得它写的是吃醋，是不甘，是一个人明明还在意，却偏偏说不出口。

后来才懂，成年人的感情里，最难过的“明明就”，不是明明喜欢却没开始。

而是——

明明就一起走过很难的路。

明明就真的爱过。

明明就没有谁对不起谁。

明明就两个人都越来越好了。

可最后，还是散了。

有些感情，不是坏在开始太轻，而是坏在后来太清醒。

清醒到你终于承认：

我们都没有变差。

只是我们想去的地方，不一样了。

我曾经见过一段这样的感情。

他们不是校园恋爱，也不是暧昧错过。

他们是在工作后认识的。

一个做摄影，一个做文案。

一个相信画面能说话，一个相信文字能留下情绪。

他们最开始不是恋人，是一起熬项目的人。

男生以前是婚礼摄影师。

每天背着很重的相机，跑不同的酒店、草坪和宴会厅。别人眼里，他是在记录幸福。可只有他自己知道，很多时候，他只是一个拿着设备到处赶场的人。

拍完一场婚礼，凌晨回到出租屋，肩膀酸得抬不起来。电脑一开，还有几百张照片等着修。

女生那时候在一家小公司做文案。

写公众号，写短视频脚本，写品牌介绍，什么都写。很多稿子写完，客户只回两个字：重写。

他们认识，是因为一个小品牌的宣传片。

预算不高，要求很多。老板想要“高级感”，客户想要“故事感”，最后压力都落在他们两个人身上。

男生负责拍摄和剪辑。

女生负责脚本和旁白。

第一次开会，女生拿着稿子，讲得很慢。她说，她不想把这个片子拍成那种空洞的宣传语。

男生听完，只说了一句：

“那就拍真实一点。”

那一刻，女生抬头看了他一眼。

她后来跟我说：

“我当时觉得，终于有个人听懂我在说什么了。”

那支片子拍了很多天。

他们去过清晨还没开门的街区，去过下雨后的旧厂房，也去过客户嫌“不够好看”的小巷子。

有一天拍到很晚，设备快没电，女生蹲在路边改旁白，男生站在旁边举着补光灯。

她说：“你不觉得很累吗？”

男生说：“累啊，但总比拍一堆自己都不信的东西好。”

就是这句话，让女生忽然觉得，这个人和别人不一样。

因为那时候，他们都太需要一个人告诉自己：

你坚持的东西，不是笑话。

后来，他们在一起了。

没有什么轰轰烈烈的表白。

只是某一次收工后，两个人坐在路边等车。

女生说：“以后我们会不会有一天，能只做自己想做的东西？”

男生看着远处的车灯，说：“会吧。”

女生问：“那你到时候还会跟我一起做吗？”

男生笑了笑：

“只要你还写，我就拍。”

那时候的承诺很轻，没有戒指，没有鲜花，没有朋友圈官宣。

可也很重。

重到后来很多年，女生想起这句话，还是会眼眶发酸。

刚在一起那几年，他们过得很辛苦。

租的小房子里，客厅堆满了灯架、硬盘、三脚架，还有一摞摞打印出来的脚本。

有时候男生剪片剪到凌晨三点，女生就坐在旁边改旁白。

电脑风扇一直响，窗外偶尔有车经过。

他们不怎么说话。

可只要抬头看一眼，发现对方还在，就觉得还能撑下去。

后来，他们真的慢慢被看见了。

男生拍的一组城市短片火了，有人开始找他拍商业片。女生写的几篇品牌故事被转发，也开始有了自己的客户。

他们的生活变好了。

不用再接所有不喜欢的活。

不用再为了几百块钱跟客户磨半天。

不用再把梦想说得很小心，怕别人笑他们天真。

他们开始有选择。

可是，问题也就是从“有选择”开始的。

以前，他们最大的愿望是：有人看见我们。

后来，他们真正被看见以后，才发现：

被看见之后，要走哪条路，也是一道很难的题。

男生变得越来越忙。

他开始接更大的项目，进入更大的团队，认识更多品牌方和制片人。

他学会了谈预算，学会了控制成本，也学会了在饭局上把话说得漂亮。

他不再只是那个为了一个镜头等半天光线的人。

他开始说：

“这个东西要有效率。”

“客户要的是结果。”

“作品不能只讲情绪，还要讲转化。”

这些话没有错。

甚至很成熟。

女生也知道，他一路走来不容易。

可她慢慢发现，他们开始听不懂彼此了。

她写了一篇很喜欢的长文，想慢慢打磨。

男生看完说：“太慢了，现在没人看这么长。”

她想做一个关于普通人生活记录的栏目。

男生说：“这个方向不够商业，变现难。”

她说：“可我就是想写一点真的东西。”

他说：“真的东西，也要有人买单。”

那一刻，女生忽然沉默了。

她不是怪他现实。

她只是有点难过。

因为那个曾经说“拍真实一点”的人，现在开始反过来提醒她：

真实不一定有用。

男生也觉得委屈。

他觉得自己没有错。

他只是比以前更清楚这个世界的规则。

他只是想让他们过得更好。

他只是想把曾经吃过的苦，变成后来站稳的底气。

他不明白，为什么自己越努力，女生反而越远。

直到有一次，他们因为一个项目吵了起来。

女生说：“你现在什么都在算值不值。”

男生说：“不算怎么办？你以为我们还能像以前一样，只靠喜欢做事吗？”

女生看着他，过了很久才说：

“我不是想回到以前。”

“我只是害怕，你越来越不像以前那个你了。”

那天之后，他们冷战了很久。

不是谁不想低头。

而是他们都不知道，该怎么解释自己心里的委屈。

真正让他们分开的，也不是某一次争吵。

而是很多个很小的瞬间。

女生生日那天，男生给她订了很贵的餐厅，还送了她一台新电脑。

女生知道他用心了。

可她真正想要的，是他陪她去看一场很小众的展。

那个展，她提前跟他说过很多次。

他忘了。

后来他解释说：

“最近太忙了，我想着电脑你刚好需要。”

女生点点头，说：“我知道。”

她真的知道。

可知道和不难过，是两回事。

还有一次，女生深夜发了一条朋友圈：

“有时候很怀念无人问津的日子。”

男生看见后，第一反应不是心疼，而是问她：

“你是不是对现在的工作状态不满意？”

女生说：“我只是忽然有点累。”

男生说：“累就休息两天，别发这种容易让客户误会的话。”

那一刻，女生突然不想解释了。

因为她明白，他不是不关心她。

只是他的第一反应，已经不再是她的情绪，而是风险、影响、后果和安排。

他还爱她。

只是他的爱，越来越像管理。

她也还爱他。

只是她越来越无法在这段关系里安心地软下来。

他们后来也试过修复。

约定每周留一天不谈工作。

约定吃饭不看手机。

约定有情绪就说，不要憋着。

可很多东西，不是靠约定就能回到从前。

因为人一旦变了，爱人的方式也会变。

而最残忍的是：

你不能要求一个正在往前跑的人，永远停在原地。

也不能要求一个开始珍惜内心的人，继续陪你拼命燃烧自己。

他们都没有错。

只是爱到后来，彼此都累了。

分开那天，他们没有撕破脸。

女生把自己的书、手账、旧电脑，还有几份打印过的脚本，慢慢装进行李箱。

房间里很安静。

安静到他们都能听见纸张被合上的声音。

女生收拾到最后，翻出了一张旧照片。

照片里，他们站在一个旧厂房门口。男生扛着相机，女生抱着脚本。

两个人都很疲惫，却笑得很亮。

女生看了很久，然后把照片放回桌上。

她说：

“这张留给你吧。”

男生低头看着那张照片，眼睛红了。

他说：

“我们是不是也没有做错什么？”

女生摇摇头。

“没有。”

“只是后来，我们想成为的人，不太适合继续相爱了。”

这句话一说出来，两个人都沉默了。

因为他们都知道，这就是答案。

有些分开，不是因为谁不值得。

而是因为你们曾经在同一条路上互相扶过一把，后来却各自看见了不同的风景。

他想去更远的地方。

她想回到更真的自己。

他想证明自己终于赢了。

她想确认自己不必一直赢。

这些都不是错。

可感情里最无力的，恰恰是两个人都没错。

后来我再见到女生，是很久以后。

她开了自己的小工作室，更新得不频繁，但每一篇文字都很像她。

慢一点，安静一点，却很有力量。

我问她：“还会想起他吗？”

她说：

“会啊。”

“毕竟有一段时间，我是真的以为我们会一起走很久。”

我问：“那还遗憾吗？”

她笑了一下。

“遗憾。”

“但我不觉得失败。”

“因为他确实陪我走过最难的一段路。”

这句话，我记了很久。

因为很多人总以为，没走到最后的感情，就是失败。

可其实不是。

有些人出现在你的生命里，不是为了陪你到终点。

而是为了在你最不相信自己的时候，陪你走过一段黑暗。

后来你变好了。

他也变好了。

你们没有继续在一起。

但那段爱，并不是假的。

所以，明明就还爱，为什么最后还是散了？

也许是因为，爱可以让两个人靠近。

但能不能走到最后，还要看彼此变好之后，能不能继续同频。

有些人陪你熬过无人问津。

却没能陪你走过人声鼎沸。

有些人见过你最狼狈的样子。

却在你们都变得体面之后，慢慢失去了拥抱彼此的能力。

这不是谁的错。

只是人生有时候就是这样：

有些爱，是真的。

有些散，也是真的。

你不必用最后的结局，去否定曾经的陪伴。

也不必因为没能走到最后，就觉得那个人不值得。

他曾经在你最难的时候，陪你撑过一程。

你也曾经在他最没底气的时候，给过他光。

这就已经很珍贵了。

后来再听《明明就》，我越来越觉得，它最痛的地方，不只是遗憾。

而是那种明明还记得，明明还在意，明明心里还有柔软，却只能承认：

我们只能走到这里了。

明明就还爱。

可最后还是散了。

不是因为爱不够真。

而是因为有些人，只能陪你完成一段人生。

然后在某个路口，把你还给更好的自己。

原文发布于微信公众号合集《每晚一首歌，聊点成年人不说的话》。

那年夏天，我把《嗜好》唱给她听，却没敢说喜欢她

Sun, 19 Apr 2026 00:00:00 GMT

那年夏天，我把《嗜好》唱给她听，却没敢说喜欢她#

音频：后来对你喜欢成为一种嗜好 / 春风不语人

“治不好，想念你的嗜好，再多时光，都徒劳。”

第一次听到《嗜好》这句歌词的时候，我突然想起一个男生。

他曾经喜欢过一个女生很多年。

不是轰轰烈烈的喜欢。

而是很安静、很笨拙、很小心翼翼的喜欢。

他会故意等她下班。

会记住她爱喝什么饮料。

会因为她一句普通的关心，在心里开心很久。

也会在深夜点开聊天框，打出很多话，又一字一句删掉。

他不是没有机会。

只是每一次机会来到面前，他都退了一步。

后来他才明白，有些喜欢之所以会变成“嗜好”，不是因为那个人真的有多难忘。

而是因为你习惯了想她，习惯了等她，习惯了在每一个相似的夏夜里，把那段没说出口的青春，重新想一遍。

他们认识在高中毕业后的那个暑假。

那时候，所有人刚刚从高考里逃出来。

自由是真的。

迷茫也是真的。

他去打暑假工，想赚一点生活费，也想提前看看大人的世界。

可真正上班以后，他才知道，大人的世界并没有想象中体面。

工作服闷得发热。

主管说话很急。

一天站下来，腿像灌了铅。

晚上下班时，城市的热气还没散。

路边有烧烤摊的烟火气，有奶茶店的甜味，也有公交车经过留下的尾气。

女生就是在那个夏天出现的。

她和他穿着一样的工作服，头发总是随便扎起来。

累的时候，会把冰饮料贴在脸边降温。

她笑起来不算特别惊艳。

但很干净。

像那个夏天里，唯一不让人觉得烦的风。

一开始，他们只是普通同事。

一起上班，一起下班，偶尔一起吃很便宜的夜宵。

两个人坐在路边的小桌子前，点一份炒粉，再分一瓶饮料。

她会吐槽主管太凶。

他会学主管说话逗她笑。

有时候公交迟迟不来，他们就站在站牌下面聊天。

风是热的。

灯是暗的。

可他每次站在她旁边，都觉得那天好像没那么累了。

喜欢就是从这些小事里开始的。

不是某一个瞬间突然心动。

而是某一天他发现，自己下班前开始故意放慢收拾东西的速度。

只为了等她一起走。

他开始记住她喜欢喝什么味道的奶茶。

开始因为她一句“你今天是不是被骂了，别放心上”，在心里反复开心很久。

也开始在手机里点开她的头像，却什么都不敢发。

那时候他还不懂。

一个人开始反复注意另一个人的情绪，其实就是喜欢的开始。

有一次，下班后，他们和几个同事去唱歌。

包厢里灯光很暗。

大家点的歌都很吵。

有人唱跑调，有人抢麦，有人笑得很大声。

轮到他的时候，他点了《嗜好》。

其实那首歌，他已经偷偷练了很多遍。

在宿舍里。

在回家的路上。

在夜里戴着耳机的时候。

他想过很多次。

如果有一天唱给她听，她会不会听懂？

会不会知道，他唱的不是歌，是藏了很久的心事？

音乐响起来的时候，他忽然不敢看她。

只盯着屏幕。

手心微微出汗。

那几分钟里，他唱得很认真。

认真到旁边人都安静了一会儿。

女生坐在角落，手里拿着饮料，偶尔抬头看他。

唱完以后，她笑着说：

“你唱得还挺认真。”

就这一句。

他记了很多年。

那天晚上回去，他躺在床上翻来覆去睡不着。

一会儿觉得她是不是听懂了。

一会儿又觉得自己想太多。

聊天框里，他打过一句：

“其实那首歌是想唱给你听的。”

又删掉。

最后只发了一句：

“到家了吗？”

她回：

“到了，你也早点睡。”

他盯着那几个字看了很久。

像一个人守着一点很小的光，舍不得吹灭，也不敢靠近。

暑假结束后，他们各自去了不同的地方。

他上了大学。

她也继续自己的生活。

关系没有断，只是慢慢淡了。

从每天几句，变成几天一句。

再后来，变成节日问候，朋友圈点赞。

他不是没想过表白。

很多个晚上，他都想问她：

“你那时候，有没有一点点喜欢过我？”

可每次话到嘴边，他又退回去。

他怕太突然。

怕她只是把他当朋友。

更怕自己一说出口，连那点轻松的联系都没了。

几年后，他忽然听说，她专升本考来了他的大学。

比他少一届。

而那时候，他已经快毕业了。

听到这个消息的时候，他心里像被什么轻轻撞了一下。

那些他以为早就放下的夏天、公交站、夜宵摊、那首唱给她听的歌，突然全都回来了。

他开始重新期待。

甚至有点幼稚地想：

是不是命运又给了他一次机会？

她来学校报到那天，他去见了她。

校园里的树很高。

新生拖着行李来来往往。

她站在人群里，比从前成熟了一点。

可笑起来的时候，还是会让他想起那个高中毕业后的夏天。

那天，她因为宿舍手续还没完全办好，临时在学校附近订了一晚宾馆。

他陪她吃了饭，又送她过去。

一路上，他们聊那个暑假工，聊便宜的夜宵，聊等了很久才来的公交。

聊到当年那次唱歌，她忽然说：

“其实你那时候唱的那首歌，我还记得。”

他心里猛地一颤。

像一个等了很多年的人，终于听见门外有了脚步声。

他很想问：

“那你知不知道，我是唱给你听的？”

可他没有。

他只是笑了笑，说：

“那么久了，你还记得啊。”

她说：

“记得，你那时候唱得很认真。”

又是这句话。

很多年前，这句话让他开心。

很多年后，这句话让他难过。

到了宾馆门口。

她停下来，看着他说：

“谢谢你送我。”

他看着她。

有那么一秒，他真的想说：

“其实我一直都挺喜欢你的。”

可是那句话在喉咙里转了很久。

最后变成了：

“早点休息。”

她笑了笑，说：

“你也是。”

玻璃门关上的那一刻，他一个人站在门口很久。

原来有些人不是错过一次。

是你每一次都有机会，却每一次都退后一步。

后来，他毕业那年，又回了一次学校。

天气刚刚转热，操场边的风吹过来，有一点夏天要来的味道。

他约她出来吃饭。

其实说是吃饭，也不过是找了一个很普通的理由。

他说：

“我快毕业了，刚好回学校一趟，要不要出来吃个饭？”

她答应得很自然。

那天他们吃了一家学校附近的小店。

店面不大，人很多。

桌子有点油，空调也不太凉。

可他还是觉得那顿饭很特别。

因为她坐在对面。

因为她低头看菜单的时候，还是会皱一下眉。

因为她笑起来的时候，他还是会想起那个暑假。

吃完饭以后，他们去了操场散步。

有人跑步。

有人牵手。

有人坐在看台上聊天。

他们一圈一圈地走。

聊过去。

聊专业。

聊毕业。

也聊到这些年彼此错过的生活。

他其实一直在等一个合适的机会。

他想，也许这一次可以说了。

可是走到第二圈的时候，女生忽然很自然地提起：

“我男朋友之前也说过，你们学校操场还挺大的。”

那一瞬间，他整个人像被什么轻轻电了一下。

不是很疼。

但心里忽然空了一块。

原来她已经有男朋友了。

原来自己幻想过那么多次的重逢，在现实里只是她生活中很普通的一次见面。

他愣了一下，又很快故作镇定地笑了笑：

“挺好的啊。”

女生看了他一眼，又问：

“那你呢？”

他明明可以说没有。

甚至可以在那一刻，把很多年的心事说出来。

可是他没有。

他的自尊、胆怯、难堪，在那一秒全部跑了出来。

他怕自己显得太狼狈。

怕她看出自己这些年还惦记着。

于是他故作轻松地说：

“我也交了女朋友。”

说完这句话的时候，他自己都觉得陌生。

女生笑着说：

“那挺好啊。”

他也笑。

可那个笑，很轻，也很假。

那天过后，他第一次很清楚地意识到：

喜欢一个人，不能只靠幻想。

也不能一直等对方给你暗示。

你要行动。

你要表达。

你要在还有机会的时候，勇敢往前走一步。

因为有些遗憾，不是突然发生的。

是你一次次把“下次再说”，攒成了“再也不能说”。

后来，他们还是会偶尔联系。

只是再也没有那么多可以误会的靠近。

他也慢慢长大。

工作。

搬家。

认识新的人。

经历新的关系。

可有些夜晚，他还是会听到《嗜好》。

那一刻，他想起的未必只是她。

也会想起那个曾经很胆小的自己。

想起那个下班前故意放慢动作的少年。

想起那个把歌练了很多遍，却不敢把喜欢说出口的自己。

想起那个在宾馆门口明明心里翻涌，却只说“早点休息”的自己。

也想起那个在操场上听见她有男朋友时，明明心里难过，却还要假装自己也过得很好的人。

有些喜欢不是输给了别人。

是输给了自己的犹豫。

你以为不说，就不会失去。

可很多年后才发现。

不说，也是一种失去。

而且失去得很安静。

所谓嗜好，不是戒不掉某首歌。

而是戒不掉那个曾经让我心动、也让我变得胆小的人。

如果那年夏天，我多说一句喜欢你。

如果那次唱完歌，我没有只问你“到家了吗”。

如果那晚宾馆门口，我不是只说“早点休息”。

如果那次操场散步，我没有故作镇定。

也许故事不一定会圆满。

但至少很多年后，我不会一直困在那个没开口的自己里面。

喜欢一个人，真的不要只停在幻想里。

不要只靠等。

不要只靠猜。

喜欢就要勇敢一点。

哪怕结果不一定如愿。

也好过很多年以后，你才发现：

原来你最遗憾的，不是她没有喜欢你。

而是你连让她知道的勇气，都没有给过自己。

原文发布于微信公众号合集《每晚一首歌，聊点成年人不说的话》。

怎么使用obsidian 来编写 astro 博客

Sat, 18 Apr 2026 00:00:00 GMT

Obsidian + Astro Composer + Git 插件同步 Astro 博客到 GitHub 完整教程

前置前提（必做）：

已安装 Obsidian 客户端，且启用「第三方插件」（设置 → 第三方插件 → 关闭“安全模式”）。
已创建 Astro 博客项目（本地需有 Astro 项目文件夹，可通过 pnpm create astro@latest 快速创建，选择 blog 模板即可），并熟悉 Astro 项目的 src/content 目录（用于存放博客文章）。
已注册 GitHub 账号，且创建了用于托管 Astro 博客的仓库（建议仓库名与 Astro 博客项目名一致，若要部署 GitHub Pages，仓库名可设为 用户名.github.io）。
已安装所需插件：Astro Composer（Obsidian 插件）、Git（Obsidian 插件，常用 Obsidian Git 或 Git Vault/Folder Sync，本教程以 Obsidian Git 为例，适配多数用户需求）。

第一步：安装并配置 Astro Composer 插件（核心：Obsidian 笔记转 Astro 内容）#

Astro Composer 是 Obsidian 与 Astro 博客无缝衔接的关键插件，可自动将 Obsidian 笔记转换为 Astro 支持的 Markdown 格式（含自动处理链接、标准化属性、管理草稿等），目前该插件暂未上架 Obsidian 社区插件库，需通过 BRAT 插件安装或手动安装，推荐 BRAT 安装（更便捷，支持自动更新）。

1.1 安装 Astro Composer 插件#

先安装 BRAT 插件：Obsidian 内 → 设置 → 第三方插件 → 浏览社区插件 → 搜索「BRAT」→ 安装并启用。
启用 BRAT 后，打开 BRAT 设置 → 点击「Add a beta plugin」→ 输入 Astro Composer 插件仓库地址（https://github.com/astro-modular/astro-composer）→ 点击「Add Plugin」，等待安装完成后启用插件。

1.2 配置 Astro Composer 插件#

配置核心目的：让插件知道「Obsidian 笔记存放位置」和「Astro 项目的内容目录位置」，实现笔记自动转换后同步到 Astro 项目中。

打开 Obsidian 设置 → 找到「Astro Composer」插件，进入配置页面。
image.png

image.png

image.png
核心配置项（必设）：
1. Posts Folder：设置 Obsidian 中用于存放博客文章的文件夹（例如 Blog/Posts），后续所有要发布的笔记都放在这个文件夹下。
2. Astro Content Path：设置本地 Astro 项目的src/content 目录路径（例如 D:/MyBlog/astro-blog/src/content），插件会自动将转换后的笔记同步到这个目录。
3. Link Base Path：设置链接基准路径，填写 Astro 博客的文章访问路径（例如 /blog），插件会自动将 Obsidian 内部链接（ wikilinks 或 Markdown 内部链接）转换为 Astro 友好的链接格式，避免发布后链接失效。
4. Creation Mode：选择文章存储结构，推荐「Folder-based with index.md」（每个文章对应一个文件夹，内部包含 index.md 文件），适配多数 Astro 博客模板。
5. Draft Management：启用「Underscore Prefix」，插件会为草稿笔记添加下划线前缀（例如 _my-draft.md），Astro 会自动隐藏这些草稿，避免误发布。
可选配置（优化体验）：
1. Property Standardization：设置笔记属性模板（例如标题、日期、标签等），启用「Standardize Properties」命令，可自动为笔记添加缺失的属性，保持 Astro 文章格式统一。
2. Rename Post Command：启用后，修改笔记的「title」属性，插件会自动将笔记文件名/文件夹名更新为 kebab-case 格式（例如“我的第一篇博客”→「my-first-blog」），适配 Astro 的路由规则。
配置完成后，点击「Save Settings」，重启插件（Obsidian 重启或禁用再启用），确保配置生效。

“求你别离开我”这句话，他到最后都没敢说

Sat, 18 Apr 2026 00:00:00 GMT

“求你别离开我”这句话，他到最后都没敢说#

音频：求你别离开我，后来也一直没说出口 / 春风不语人

“从不主动示弱。”

听到这句的时候，我突然想起一个男生。

他不是不爱她。

相反，他很爱。

可他这辈子最失败的地方，就是太会嘴硬。

难过的时候不说。

舍不得的时候不说。

明明想挽留，却偏偏装得像个没事人。

分手那天，女生最后问他：

“你还有什么想说的吗？”

他低着头，手指攥得很紧。

他其实很想说：

“别走。”

“我真的舍不得你。”

“我以后会改。”

可最后，他只是笑了一下，说：

“那就这样吧。”

很多感情最虐的地方就在这里。

不是没有爱过。

而是爱得那么深，却没有一个人肯先低头。

他们是在大学认识的。

那时候两个人都很年轻。

女生学设计，男生学计算机。

一个总是熬夜赶图，一个总是抱着电脑写代码。

他们第一次熟起来，是因为一场社团活动。

那天活动结束很晚，学校外面下着雨。

女生没带伞，男生把伞递给她，自己一路淋回宿舍。

女生后来问他：

“你是不是傻？”

他说：

“你感冒了，还不是我陪你去买药。”

很土。

但那时候的喜欢，本来就带着一点笨拙。

后来他们在一起。

一起吃食堂最便宜的盖饭。

一起坐公交去海边。

一起在毕业前的夜晚，坐在沙滩上看远处的灯。

海浪一下一下拍着沙。

她靠在他肩膀上，说：

“以后我们会不会一直在一起？”

他说：

“会啊，我陪你留下。”

那时候他说得很认真。

她也真的信了。

年轻时说过的浪漫话，最动人的地方不是它多成熟。

而是说出口的时候，两个人都以为自己做得到。

毕业后，他们去了深圳。

一开始日子很苦。

两个人租在城中村的小房子里。

房间很小，窗外是密密麻麻的空调外机。

下雨天，墙角会有一点潮。

可那时候他们并不觉得难。

女生刚入职广告公司，每天被客户改稿改到崩溃。

男生进了一家互联网公司，天天加班到凌晨。

他们常常深夜一起吃外卖。

一份炒粉，两杯便利店酸奶。

女生说：

“我们以后一定要搬到有阳台的房子。”

男生说：

“等我涨工资。”

她说：

“那你要快一点。”

他说：

“我努力。”

那几年，他们真的很努力。

可现实不是一下子压垮人的。

它是一点一点来的。

房租涨了。

工作越来越忙。

父母开始催婚。

女生家里希望她稳定一点，最好回老家考编。

男生公司动不动裁员，他每天都怕自己突然失业。

以前他们吵架，是因为谁没有回消息。

后来他们吵架，是因为城市、工作、钱、未来、父母。

爱情一旦碰到现实，就会从“我想你”，变成“我们怎么办”。

真正让她失望的，不是某一件大事。

而是很多次小事。

她生日那天，他说好陪她吃饭。

她提前订好了餐厅，还特意点了很多他喜欢吃的菜系。

结果他临时加班。

晚上十点半，他发来一句：

“项目出问题了，走不开。”

她盯着那行字，看了很久。

最后只回了一个：

“好。”

其实她不是不懂他忙。

她只是难过。

因为那不是第一次。

她生病去医院，他说马上来，结果会议拖到半夜。

她被领导骂到哭，给他发消息，他两个小时后回：

“刚看到。”

她想和他聊聊未来，他说：

“我现在真的没精力。”

每一次，他都有理由。

每一次，理由也都是真的。

可感情最残忍的地方是：

解释不等于陪伴。

他说得再合理，她心里的空也不会自动填上。

后来她开始变得沉默。

不再追问他几点下班。

不再问他周末能不能见面。

不再把自己的委屈一股脑发给他。

男生以为她终于懂事了。

其实不是。

她只是慢慢不想再期待了。

他们分过很多次。

每一次分开，都像一场预演。

女生说：

“我们算了吧。”

男生沉默很久，又说：

“你是不是一定要在我最难的时候逼我？”

她听完这句话，眼泪一下就掉了。

因为她从来不是想逼他。

她只是太累了。

她想要一个确定的答案。

想要一个被坚定选择的感觉。

想要知道自己这些年的等待，不是一个笑话。

可男生也委屈。

他觉得自己已经拼命了。

拼命工作，拼命赚钱，拼命想让两个人以后过得好一点。

可他忘了。

女生想要的，不只是未来。

还有当下。

她不是只想住进更好的房子。

她也想在崩溃的时候，有人抱抱她。

那天他们吵得很厉害。

他说：

“你要是觉得我给不了你想要的生活，那你就走。”

这句话说出口的时候，他就后悔了。

可有些话，一旦说出来，就像刀子。

收不回去。

她看着他，很轻地说：

“好。”

就这一个字。

他突然慌了。

因为他第一次发现，她这次好像真的不想回头了。

他们最后一次见面，在深圳湾。

不是为了复合。

是为了把彼此家里的东西还清。

她把他的卫衣、耳机、几本书装在袋子里。

他把她的发夹、口红、还有一张旧拍立得放进盒子里。

海风很大。

她头发被吹乱，但没有像以前那样等他帮她整理。

她只是自己抬手拨开。

那一瞬间，他心里突然空了一下。

原来一个人真正要离开的时候，是不会再等你了。

他们沿着海边走了一段。

谁都没有说话。

以前他们并肩走的时候，总有聊不完的话。

现在只剩沉默。

他想问她：

“能不能别走？”

可话到了嘴边，又被他咽回去。

因为他知道，自己欠她太多。

欠她很多次失望后的安慰。

欠她很多个没有兑现的承诺。

欠她很多次明明可以温柔一点，却偏偏选择嘴硬的瞬间。

最后，女生停下来，说：

“其实分开以后，我反而轻松了很多。”

这句话很轻。

却像一把刀，慢慢插进他心里。

对她来说，是解脱。

对他来说，是落魄。

他终于明白，自己不是失去了一个爱人。

是失去了一个曾经愿意一次次原谅他的人。

分开后的很长一段时间，他都装得很好。

朋友圈照常发。

工作照常做。

朋友约吃饭，他也去。

别人问起她，他就笑笑说：

“和平分手。”

好像很洒脱。

好像没什么大不了。

可只有他自己知道，他每天晚上都会点开她的头像。

看她有没有更新朋友圈。

看她有没有换城市。

看她过得好不好。

他无数次打开聊天框。

打出：

“最近还好吗？”

又删掉。

打出：

“我今天路过我们以前吃饭的地方。”

又删掉。

打出：

“我其实很想你。”

还是删掉。

他终于变成了她以前的样子。

一个人在深夜里等。

一个人在聊天框里反复删改。

一个人在回忆里被漩涡一点点吞没。

可他再也没有资格问她：

“你能不能回来？”

后来有一次，他加班到很晚。

从公司出来的时候，耳机里刚好播到《海屿你》。

那一瞬间，他站在路边，突然走不动了。

他想起大学时那把伞。

想起城中村潮湿的小房间。

想起她穿着新裙子，一个人在餐厅等他的生日。

想起深圳湾那天，她平静地说：

“分开以后，我轻松了很多。”

有些回忆真的像漩涡。

平时你以为它沉下去了。

可只要一首歌响起，它就会把你整个人拖回去。

他终于承认：

自己没有那么洒脱。

自己也没有真的放下。

他只是太晚才懂。

原来爱情不是你心里有她就够了。

原来一个人失望太多次，是真的会离开的。

原来有些手，一旦松开，就再也牵不回来了。

这段感情最虐的地方，不是他们没爱过。

而是他们爱过、开心过、痛过、反复和好过。

最后还是败给了现实，败给了嘴硬，也败给了那些来不及好好说出口的话。

她离开的时候，没有大哭。

没有责怪。

没有回头。

可他却在她走后的每一个深夜里，终于学会了示弱。

只是那句“求你别离开我”，他已经没有机会说给她听了。

所以啊。

有些人真的不是突然离开的。

是你一次次让她失望。

她一次次给你机会。

直到最后，她终于不等了。

而你才发现：

她走的那天，不只是离开你。

也是放过了她自己。

可你，却从那天开始，被回忆困住了。

原文发布于微信公众号合集《每晚一首歌，聊点成年人不说的话》。

Simple Guides for Mizuki

Mon, 01 Apr 2024 00:00:00 GMT

This blog template is built with Astro. For the things that are not mentioned in this guide, you may find the answers in the Astro Docs.

Front-matter of Posts#

1
---
2
title: My First Blog Post
3
published: 2023-09-09
4
description: This is the first post of my new Astro blog.
5
image: ./cover.webp
6
tags: [Foo, Bar]
7
category: Front-end
8
draft: false
9
---

Attribute	Description
`title`	The title of the post.
`published`	The date the post was published.
`pinned`	Whether this post is pinned to the top of the post list.
`priority`	The priority of the pinned post. Smaller value means higher priority (0, 1, 2…).
`description`	A short description of the post. Displayed on index page.
`image`	The cover image path of the post. 1. Start with `http://` or `https://`: Use web image 2. Start with `/`: For image in `public` dir 3. With none of the prefixes: Relative to the markdown file
`tags`	The tags of the post.
`category`	The category of the post.
`licenseName`	The license name for the post content.
`author`	The author of the post.
`sourceLink`	The source link or reference for the post content.
`draft`	If this post is still a draft, which won’t be displayed.

Where to Place the Post Files#

Your post files should be placed in src/content/posts/ directory. You can also create sub-directories to better organize your posts and assets.

1
src/content/posts/
2
├── post-1.md
3
└── post-2/
4
    ├── cover.webp
5
    └── index.md

Encrypted Post

Mon, 15 Jan 2024 00:00:00 GMT

This is an article for testing the page encryption feature

Include Video in the Posts

Mon, 01 Aug 2022 00:00:00 GMT

Just copy the embed code from YouTube or other platforms, and paste it in the markdown file.

1
---
2
title: Include Video in the Post
3
published: 2023-10-19
4
// ...
5
---
6

7
<iframe width="100%" height="468" src="https://www.youtube.com/embed/5gIf0_xpFPI?si=N1WTorLKL0uwLsU_" title="YouTube video player" frameborder="0" allowfullscreen></iframe>

YouTube#

Bilibili#

MDX 格式文章示例

Fri, 02 Jan 1970 00:00:00 GMT

Tip

Firefly 支持 MDX 和 Markdown 两种类型的文章，你可以在文章中混合使用两种格式，如果没有特别复杂内容和需求，推荐使用 Markdown 格式就够了。

Markdown 和 MDX 的区别#

Markdown (MD) 是一种轻量级标记语言，允许用户使用纯文本格式编写文档，然后将其转换为格式化的HTML。它因其简洁易用的语法而广受欢迎，特别适合编写文档和博客文章。
MDX 是一种扩展了 Markdown 语法的格式，允许在 Markdown 文档中无缝地插入 JSX 代码。通过 MDX，用户可以在文档中嵌入 React 组件，从而实现更丰富的交互性和动态性。

特性	Markdown	MDX
基础语法	支持 (CommonMark)	支持 (CommonMark)
HTML 标签	支持	支持 (作为 JSX)
组件导入	不支持	支持 (import)
动态数据	不支持	支持 (JS 表达式)
样式定制	有限 (class/style)	灵活 (className/CSS-in-JS)

使用组件#

这是一个图标组件：

1
import { Icon } from 'astro-icon/components'
2

3
<div class="flex items-center gap-2 my-4">
4
  <Icon name="fa7-solid:rocket" class="text-4xl text-red-500" />
5
  <span>火箭发射！</span>
6
</div>

火箭发射！

使用 JSX#

你也可以直接写 HTML/JSX：

1
<div className="p-4 bg-blue-100 dark:bg-blue-900 rounded-lg my-4">
2
  这是一个自定义样式的 div 块，使用了 Tailwind CSS 类。
3
</div>

这是一个自定义样式的 div 块，使用了 Tailwind CSS 类。

简单的变量导出#

1
export const year = new Date().getFullYear()
2

3
今年是 {year} 年。

今年是 2026 年。

更多信息，请查看 MDX 文档

Markdown 扩展功能

Thu, 01 Jan 1970 00:00:00 GMT

GitHub 仓库卡片#

您可以添加链接到 GitHub 仓库的动态卡片，在页面加载时，仓库信息会从 GitHub API 获取。

CuteLeaf

Firefly

Waiting for api.github.com...

00K

Waiting...

使用代码 ::github{repo="CuteLeaf/Firefly"} 创建 GitHub 仓库卡片。

1
::github{repo="CuteLeaf/Firefly"}

提醒框(Admonitions)配置#

Firefly 采用了 rehype-callouts 插件，支持了四种风格的提醒框主题：GitHub、Obsidian、VitePress 和 Docusaurus。您可以在 src/config/siteConfig.ts 中进行配置：

src/config/siteConfig.ts

1
export const siteConfig: SiteConfig = {
2
  // ...
3
  rehypeCallouts: {
4
    // 选项: "github" | "obsidian" | "vitepress" | "docusaurus"
5
    theme: "github",
6
  },
7
  // ...
8
};

注意：更改配置后需要重启开发服务器才能生效。

以下是各个主题支持的类型列表，每个主题风格和语法不同，可根据喜好选择。

1. GitHub 主题风格#

这是 GitHub 官方支持的 5 种基本类型。

GitHub

基本语法

1
> [!NOTE] NOTE
2
> 突出显示用户应该考虑的信息。
3

4
> [!TIP] TIP
5
> 可选信息，帮助用户更成功。
6

7
> [!IMPORTANT] IMPORTANT
8
> 用户成功所必需的关键信息。
9

10
> [!WARNING] WARNING
11
> 关键内容，需要立即注意。
12

13
> [!CAUTION] CAUTION
14
> 行动的负面潜在后果。
15

16
> [!NOTE] 自定义标题
17
> 这是一个带有自定义标题的示例。

展开收起

2. Obsidian 主题风格#

Obsidian 风格支持非常丰富的类型和别名。

点击展开 Obsidian 语法列表

1
> [!NOTE] NOTE
2
> 通用的笔记块。
3

4
> [!ABSTRACT] ABSTRACT
5
> 文章的摘要。
6

7
> [!SUMMARY] SUMMARY
8
> 文章的总结（同 Abstract）。
9

10
> [!TLDR] TLDR
11
> 太长不看（同 Abstract）。
12

13
> [!INFO] INFO
14
> 提供额外信息。
15

16
> [!TODO] TODO
17
> 需要完成的事项。
18

19
> [!TIP] TIP
20
> 实用技巧或提示。
21

22
> [!HINT] HINT
23
> 暗示（同 Tip）。
24

25
> [!IMPORTANT] IMPORTANT
26
> 重要信息（Obsidian 风格通常使用类似的图标）。
27

28
> [!SUCCESS] SUCCESS
29
> 操作成功。
30

31
> [!CHECK] CHECK
32
> 检查通过（同 Success）。
33

34
> [!DONE] DONE
35
> 已完成（同 Success）。
36

37
> [!QUESTION] QUESTION
38
> 提出问题。
39

40
> [!HELP] HELP
41
> 寻求帮助（同 Question）。
42

43
> [!FAQ] FAQ
44
> 常见问题（同 Question）。
45

46
> [!WARNING] WARNING
47
> 警告信息。
48

49
> [!CAUTION] CAUTION
50
> 注意事项（同 Warning）。
51

52
> [!ATTENTION] ATTENTION
53
> 引起注意（同 Warning）。
54

55
> [!FAILURE] FAILURE
56
> 操作失败。
57

58
> [!FAIL] FAIL
59
> 失败（同 Failure）。
60

61
> [!MISSING] MISSING
62
> 缺失内容（同 Failure）。
63

64
> [!DANGER] DANGER
65
> 危险操作警告。
66

67
> [!ERROR] ERROR
68
> 错误信息（同 Danger）。
69

70
> [!BUG] BUG
71
> 报告软件缺陷。
72

73
> [!EXAMPLE] EXAMPLE
74
> 展示一个例子。
75

76
> [!QUOTE] QUOTE
77
> 引用一段话。
78

79
> [!CITE] CITE
80
> 引证（同 Quote）。
81

82
> [!NOTE] 自定义标题
83
> 这是一个带有自定义标题的示例。

展开收起

Obsidian

3. VitePress 主题风格#

VitePress 风格提供了一套现代化的、扁平的默认样式。目前仅包含与 GitHub 一致的 5 种 基础类型。

点击展开 VitePress 语法列表

1
> [!NOTE] NOTE
2
> 对应 GitHub 的 Note。
3

4
> [!TIP] TIP
5
> 对应 GitHub 的 Tip。
6

7
> [!IMPORTANT] IMPORTANT
8
> 对应 GitHub 的 Important。
9

10
> [!WARNING] WARNING
11
> 对应 GitHub 的 Warning。
12

13
> [!CAUTION] CAUTION
14
> 对应 GitHub 的 Caution。
15

16
> [!TIP] 自定义标题
17
> VitePress 风格同样支持自定义标题。

展开收起

VitePress

4. Docusaurus 主题风格#

Docusaurus 风格提供了一套现代化的提醒框样式，支持 5 种类型。

点击展开 Docusaurus 语法列表

支持以下类型的提醒框：note tip info warning danger

1
:::note
2
突出显示用户应该考虑的信息，即使在快速浏览时也是如此。
3
:::
4

5
:::tip
6
可选信息，帮助用户更成功。
7
:::
8

9
:::info
10
一般信息。
11
:::
12

13
:::warning
14
由于潜在风险需要用户立即注意的关键内容。
15
:::
16

17
:::danger
18
行动的负面潜在后果。
19
:::
20

21
:::tip[自定义标题]
22
可选信息，帮助用户更成功。
23
:::

展开收起

Docusaurus

剧透#

您可以为文本添加剧透。文本也支持 Markdown 语法。

内容被隐藏了哈哈！

1
内容 :spoiler[被隐藏了 **哈哈**]！

图片画廊网格 (Image Grid)#

您可以使用 [grid] 和 [/grid] 标签将多张图片纵向并排展示。这对于展示照片画廊或对比图非常有用。系统会自动根据包裹在其中的图片数量（最多支持并排展示4张）以响应式网格进行布局。

自动补齐图片高度： 同一排中如果有高度、大小或者比例不一的图片，会像「九宫格画廊相册」一样自动撑满。较短或不协调的图片会自动使用 object-cover 进行完美中心裁剪补充视野。图片边框水平彻底对齐无缝隙，但被裁剪后，只有点击图片通过灯箱才能查看完整图片，所以建议尽量避免使用长宽比例不一致的图片在同一排中。

图注恒定底端对齐： 不论上面的图片长宽如何变化，在同一行的所有图像解释文字（图注）都会对标到一条完美的水平基线上了。

示例图片一

示例图片二

基本语法

1
[grid]
2
![示例图片一](./images/firefly1.avif)
3
![示例图片二](./images/firefly2.avif)
4
![示例图片二](./images/firefly3.avif)
5
[/grid]

Markdown Mermaid 图表

Thu, 01 Jan 1970 00:00:00 GMT

Markdown 中 Mermaid 图表完整指南#

本文演示如何在 Markdown 文档中使用 Mermaid 创建各种复杂图表，包括流程图、时序图、甘特图、类图和状态图。

流程图示例#

流程图非常适合表示流程或算法步骤。

graph TD A[开始] --> B{条件检查} B -->|是| C[处理步骤 1] B -->|否| D[处理步骤 2] C --> E[子过程] D --> E subgraph E [子过程详情] E1[子步骤 1] --> E2[子步骤 2] E2 --> E3[子步骤 3] end E --> F{另一个决策} F -->|选项 1| G[结果 1] F -->|选项 2| H[结果 2] F -->|选项 3| I[结果 3] G --> J[结束] H --> J I --> J

时序图示例#

时序图显示对象之间随时间的交互。

sequenceDiagram participant User as 用户 participant WebApp as 网页应用 participant Server as 服务器 participant Database as 数据库 User->>WebApp: 提交登录请求 WebApp->>Server: 发送认证请求 Server->>Database: 查询用户凭据 Database-->>Server: 返回用户数据 Server-->>WebApp: 返回认证结果 alt 认证成功 WebApp->>User: 显示欢迎页面 WebApp->>Server: 请求用户数据 Server->>Database: 获取用户偏好 Database-->>Server: 返回偏好设置 Server-->>WebApp: 返回用户数据 WebApp->>User: 加载个性化界面 else 认证失败 WebApp->>User: 显示错误消息 WebApp->>User: 提示重新输入 end

甘特图示例#

甘特图非常适合显示项目进度和时间线。

gantt title 网站开发项目时间线 dateFormat YYYY-MM-DD axisFormat %m/%d section 设计阶段需求分析 :a1, 2023-10-01, 7d UI设计 :a2, after a1, 10d 原型创建 :a3, after a2, 5d section 开发阶段前端开发 :b1, 2023-10-20, 15d 后端开发 :b2, after a2, 18d 数据库设计 :b3, after a1, 12d section 测试阶段单元测试 :c1, after b1, 8d 集成测试 :c2, after b2, 10d 用户验收测试 :c3, after c2, 7d section 部署生产环境部署 :d1, after c3, 3d 发布 :milestone, after d1, 0d

类图示例#

类图显示系统的静态结构，包括类、属性、方法及其关系。

classDiagram class User { +String username +String password +String email +Boolean active +login() +logout() +updateProfile() } class Article { +String title +String content +Date publishDate +Boolean published +publish() +edit() +delete() } class Comment { +String content +Date commentDate +addComment() +deleteComment() } class Category { +String name +String description +addArticle() +removeArticle() } User "1" -- "*" Article : 写作 User "1" -- "*" Comment : 发表 Article "1" -- "*" Comment : 拥有 Article "1" -- "*" Category : 属于

状态图示例#

状态图显示对象在其生命周期中经历的状态序列。

stateDiagram-v2 [*] --> 草稿草稿 --> 审核中 : 提交审核中 --> 草稿 : 拒绝审核中 --> 已批准 : 批准已批准 --> 已发布 : 发布已发布 --> 已归档 : 归档已发布 --> 草稿 : 撤回 state 已发布 { [*] --> 活跃活跃 --> 隐藏 : 临时隐藏隐藏 --> 活跃 : 恢复活跃 --> [*] 隐藏 --> [*] } 已归档 --> [*]

饼图示例#

饼图非常适合显示比例和百分比数据。

pie title 网站流量来源分析 "搜索引擎" : 45.6 "直接访问" : 30.1 "社交媒体" : 15.3 "推荐链接" : 6.4 "其他来源" : 2.6

总结#

Mermaid 是在 Markdown 文档中创建各种类型图表的强大工具。本文演示了如何使用流程图、时序图、甘特图、类图、状态图和饼图。这些图表可以帮助您更清晰地表达复杂的概念、流程和数据结构。

要使用 Mermaid，只需在代码块中指定 mermaid 语言，并使用简洁的文本语法描述图表。Mermaid 会自动将这些描述转换为美观的可视化图表。

尝试在您的下一篇技术博客文章或项目文档中使用 Mermaid 图表 - 它们将使您的内容更加专业且更易理解！

Markdown PlantUML 图表

Thu, 01 Jan 1970 00:00:00 GMT

Markdown 中 PlantUML 图表指南#

PlantUML 是一种使用纯文本描述图表的工具。你只需要写一段结构化语法，就可以生成时序图、类图、用例图、活动图等常见工程图。

它特别适合写在技术博客和项目文档里：

图表和正文一起版本管理，便于协作与审阅
修改图只需要改文本，适合频繁迭代
能和 Markdown 无缝结合，保持文档统一

在 Firefly 中，plantuml 代码块会在构建阶段编码并生成服务器 SVG 地址，页面端再根据亮暗主题自动切换图源，并支持缩放、拖拽和全屏交互。

如果你想快速上手，可以记住这个最小模板：

活动图示例#

状态图示例#

用例图示例#

组件图示例#

部署图示例#

ER 图示例#

时序图示例（登录与刷新令牌）#

C4 风格容器图示例#

Markdown 教程

Thu, 01 Jan 1970 00:00:00 GMT

这是一个展示如何编写 Markdown 文件的示例。本文档汇总了核心语法与常见扩展（GFM）。

块级元素
- 段落与换行
- 标题
- 引用
- 列表
- 代码块
- 分割线
- 表格
内联元素
- 链接
- 强调
- 行内代码
- 图片
- 删除线
杂项
- 自动链接
- 反斜杠转义
内联 HTML

块级元素#

段落与换行#

段落#

HTML 标签：<p>

使用一个或多个空行分隔段落。（仅包含空格或制表符的行也视为空行。）

代码：

1
This will be
2
inline.
3

4
This is second paragraph.

预览：

This will be inline.

This is second paragraph.

换行#

HTML 标签：<br />

在行末添加两个或更多空格来产生换行。

代码：

1
This will be not
2
inline.

预览：

This will be not
inline.

标题#

Markdown 支持两种标题样式：Setext 与 atx。

Setext#

HTML 标签：<h1>，<h2>

使用等号 (=) 表示 <h1>、使用短横线 (-) 表示 <h2>，数量不限，作为“下划线”。

代码：

1
This is an H1
2
=============
3
This is an H2
4
-------------

预览：

This is an H1#

This is an H2#

atx#

HTML 标签：<h1>，<h2>，<h3>，<h4>，<h5>，<h6>

在行首使用 1-6 个井号 (#)，对应 <h1> 至 <h6>。

代码：

1
# This is an H1
2
## This is an H2
3
###### This is an H6

预览：

This is an H1#

This is an H2#

This is an H6#

可选：你可以在行尾“闭合” atx 标题。末尾的井号数量不必与开头一致。

代码：

1
# This is an H1 #
2
## This is an H2 ##
3
### This is an H3 ######

预览：

This is an H1#

This is an H2#

This is an H3#

引用#

HTML 标签：<blockquote>

Markdown 使用邮件风格的 > 作为引用符号。若手动换行并在每行前加 >，显示效果最佳。

代码：

1
> This is a blockquote with two paragraphs. Lorem ipsum dolor sit amet,
2
> consectetuer adipiscing elit. Aliquam hendrerit mi posuere lectus.
3
> Vestibulum enim wisi, viverra nec, fringilla in, laoreet vitae, risus.
4
>
5
> Donec sit amet nisl. Aliquam semper ipsum sit amet velit. Suspendisse
6
> id sem consectetuer libero luctus adipiscing.

预览：

This is a blockquote with two paragraphs. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aliquam hendrerit mi posuere lectus. Vestibulum enim wisi, viverra nec, fringilla in, laoreet vitae, risus.
Donec sit amet nisl. Aliquam semper ipsum sit amet velit. Suspendisse id sem consectetuer libero luctus adipiscing.

Markdown 允许“偷懒”：在一个硬换行段落中，只在第一行前加 > 即可。

代码：

1
> This is a blockquote with two paragraphs. Lorem ipsum dolor sit amet,
2
consectetuer adipiscing elit. Aliquam hendrerit mi posuere lectus.
3
Vestibulum enim wisi, viverra nec, fringilla in, laoreet vitae, risus.
4

5
> Donec sit amet nisl. Aliquam semper ipsum sit amet velit. Suspendisse
6
id sem consectetuer libero luctus adipiscing.

预览：

This is a blockquote with two paragraphs. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aliquam hendrerit mi posuere lectus. Vestibulum enim wisi, viverra nec, fringilla in, laoreet vitae, risus.

Donec sit amet nisl. Aliquam semper ipsum sit amet velit. Suspendisse id sem consectetuer libero luctus adipiscing.

引用可以嵌套（引用中的引用），通过增加 > 层级实现。

代码：

1
> This is the first level of quoting.
2
>
3
> > This is nested blockquote.
4
>
5
> Back to the first level.

预览：

This is the first level of quoting.
This is nested blockquote.
Back to the first level.

引用内可包含其他 Markdown 元素，包括标题、列表与代码块。

代码：

1
> ## This is a header.
2
>
3
> 1.   This is the first list item.
4
> 2.   This is the second list item.
5
>
6
> Here's some example code:
7
>
8
>     return shell_exec("echo $input | $markdown_script");

预览：

This is a header.#

This is the first list item.

This is the second list item.

Here’s some example code:
1
return shell_exec("echo $input | $markdown_script");

列表#

Markdown 支持有序（数字）与无序（圆点）列表。

无序列表#

HTML 标签：<ul>

无序列表可使用 星号 (*)、加号 (+) 或 短横线 (-)。

代码：

1
*   Red
2
*   Green
3
*   Blue

预览：

Red
Green
Blue

等价于：

代码：

1
+   Red
2
+   Green
3
+   Blue

或者：

代码：

1
-   Red
2
-   Green
3
-   Blue

有序列表#

HTML 标签：<ol>

有序列表使用数字加英文句点：

代码：

1
1.  Bird
2
2.  McHale
3
3.  Parish

预览：

Bird
McHale
Parish

注意：像下面这样可能会“意外触发”有序列表：

代码：

1
1986. What a great season.

预览：

What a great season.

你可以用反斜杠转义 (\) 句点：

代码：

1
1986\. What a great season.

预览：

1986. What a great season.

列表中的缩进内容#

列表项里的引用#

在列表项内放置引用，需要将 > 符号整体缩进：

代码：

1
*   A list item with a blockquote:
2

3
    > This is a blockquote
4
    > inside a list item.

预览：

A list item with a blockquote:

This is a blockquote inside a list item.

列表项里的代码块#

在列表项内放置代码块，需要缩进两层——8 个空格或两个 Tab：

代码：

1
*   A list item with a code block:
2

3
        <code goes here>

预览：

A list item with a code block:
```
1
<code goes here>
```

嵌套列表#

代码：

1
* A
2
  * A1
3
  * A2
4
* B
5
* C

预览：

A
- A1
- A2
B
C

代码块#

HTML 标签：<pre>

将代码块中的每行缩进至少4 个空格或1 个制表符。

代码：

1
This is a normal paragraph:
2

3
    This is a code block.

预览：

This is a normal paragraph:

1
This is a code block.

代码块会一直持续，直到遇到未缩进的行（或文末）。

在代码块内，与号 (&) 和尖括号 (< >) 会自动转为 HTML 实体。

代码：

1
    <div class="footer">
2
        &copy; 2004 Foo Corporation
3
    </div>

预览：

1
<div class="footer">
2
    &copy; 2004 Foo Corporation
3
</div>

下文的“围栏代码块”和“语法高亮”属于扩展语法，你也可以用它们来书写代码块。

围栏代码块#

使用成对的反引号围起来（如下所示），就不需要四空格缩进了。

代码：

1
Here's an example:
2

3
```
4
function test() {
5
  console.log("notice the blank line before this function?");
6
}
7
```

预览：

Here’s an example:

1
function test() {
2
  console.log("notice the blank line before this function?");
3
}

语法高亮#

在围栏代码块后添加可选的语言标识，即可启用语法高亮（参见支持语言列表）。

代码：

1
```ruby
2
require 'redcarpet'
3
markdown = Redcarpet.new("Hello World!")
4
puts markdown.to_html
5
```

预览：

1
require 'redcarpet'
2
markdown = Redcarpet.new("Hello World!")
3
puts markdown.to_html

分割线（水平线）#

HTML 标签：<hr /> 一行中放置三个或以上的短横线 (-)、星号 (*) 或下划线 (_)。符号之间允许有空格。

代码：

1
* * *
2
***
3
*****
4
- - -
5
---------------------------------------
6
___

预览：

表格#

HTML 标签：<table>

这是扩展语法。

用竖线 (|) 分隔列，用短横线 (-) 分隔表头，使用冒号 (:) 指定对齐方式。

两侧的竖线 (|) 与对齐可选。用于表头分隔时，每列至少需要 3 个短横线。

代码：

1
| Left | Center | Right |
2
|:-----|:------:|------:|
3
|aaa   |bbb     |ccc    |
4
|ddd   |eee     |fff    |
5

6
 A | B
7
---|---
8
123|456
9

10

11
A |B
12
--|--
13
12|45

预览：

Left	Center	Right
aaa	bbb	ccc
ddd	eee	fff

A	B
123	456

A	B
12	45

内联元素#

链接#

HTML 标签：<a>

Markdown 支持两种链接样式：行内链接与引用式链接。

行内链接#

行内链接格式：[文本](URL "标题")

标题可选。

代码：

1
This is [an example](http://example.com/ "Title") inline link.
2

3
[This link](http://example.net/) has no title attribute.

预览：

This is an example inline link.

This link has no title attribute.

如果引用同一站点的本地资源，可以使用相对路径：

代码：

1
See my [About](/about/) page for details.

预览：

See my About page for details.

引用式链接#

可以预定义链接引用。定义格式：[id]: URL "标题"

标题同样可选。引用时使用：[文本][id]

代码：

1
[id]: http://example.com/  "Optional Title Here"
2
This is [an example][id] reference-style link.

预览：

This is an example reference-style link.

说明：

方括号中包含链接标识（不区分大小写，可在左侧缩进最多三格空格）；
随后是冒号；
再跟一个或多个空格（或 tab）；
然后是链接 URL；
URL 可选地用尖括号包裹；
可选地跟随标题属性，用引号或圆括号包裹。

以下三种定义等价：

代码：

1
[foo]: http://example.com/  "Optional Title Here"
2
[foo]: http://example.com/  'Optional Title Here'
3
[foo]: http://example.com/  (Optional Title Here)
4
[foo]: <http://example.com/>  "Optional Title Here"

如果使用空的方括号，则链接文本本身会作为名称。

代码：

1
[Google]: http://google.com/
2
[Google][]

预览：

Google

强调#

HTML 标签：<em>，<strong>

Markdown 使用 星号 (*) 或 下划线 (_) 表示强调。一个分隔符对应 <em>；两个分隔符对应 <strong>。

代码：

1
*single asterisks*
2

3
_single underscores_
4

5
**double asterisks**
6

7
__double underscores__

预览：

single asterisks

single underscores

double asterisks

double underscores

但如果两侧有空格，则会被视作普通字符而非强调语法。

你可以使用反斜杠进行转义：

代码：

1
\*this text is surrounded by literal asterisks\*

预览：

*this text is surrounded by literal asterisks*

行内代码#

HTML 标签：<code>

用反引号 (`) 包裹。

代码：

1
Use the `printf()` function.

预览：

Use the printf() function.

若行内代码中需要包含反引号字符，可使用多重反引号作为定界符：

代码：

1
``There is a literal backtick (`) here.``

预览：

There is a literal backtick (`) here.

行内代码两侧的定界符允许包含空格（开头一个、结尾一个），方便在代码起始或结尾放置反引号字符：

代码：

1
A single backtick in a code span: `` ` ``
2

3
A backtick-delimited string in a code span: `` `foo` ``

预览：

A single backtick in a code span: `

A backtick-delimited string in a code span: `foo`

图片#

HTML 标签：<img />

Markdown 的图片语法与链接类似，支持行内与引用两种方式。

行内图片#

行内图片语法：![替代文本](URL "标题")

标题可选。

代码：

1
![Alt text](/path/to/img.jpg)
2

3
![Alt text](/path/to/img.jpg "Optional title")

预览：

Alt text

说明：

一个感叹号 !；
后接方括号，放置图片的替代文本；
再接圆括号，内含图片 URL/路径，及可选的标题（引号包裹）。

引用式图片#

引用式图片语法：![替代文本][id]

代码：

1
[img id]: https://s2.loli.net/2024/08/20/5fszgXeOxmL3Wdv.webp  "Optional title attribute"
2
![Alt text][img id]

预览：

Alt text

删除线#

HTML 标签：<del>

这是扩展语法。

GFM 增加了删除线语法。

代码：

1
~~Mistaken text.~~

预览：

Mistaken text.

杂项#

自动链接#

Markdown 支持一种便捷写法来创建“自动链接”（URL 与邮箱地址）：只需用尖括号将其包住即可。

代码：

1
<http://example.com/>
2

3
<address@example.com>

预览：

http://example.com/

address@example.com

GFM 会自动识别标准 URL 并转换为链接。

代码：

1
https://github.com/emn178/markdown

预览：

https://github.com/emn178/markdown

反斜杠转义#

Markdown 允许使用反斜杠来转义那些本用于 Markdown 语法的特殊字符，使其按字面显示。

代码：

1
\*literal asterisks\*

预览：

*literal asterisks*

以下字符可通过反斜杠转义以按字面量输出：

Code:

1
\   backslash
2
`   backtick
3
*   asterisk
4
_   underscore
5
{}  curly braces
6
[]  square brackets
7
()  parentheses
8
#   hash mark
9
+   plus sign
10
-   minus sign (hyphen)
11
.   dot
12
!   exclamation mark

内联 HTML#

对于 Markdown 语法未覆盖的标记，直接使用原生 HTML 即可。无需特别声明从 Markdown 切换到 HTML，直接写标签就行。

代码：

1
This is a regular paragraph.
2

3
<table>
4
    <tr>
5
        <td>Foo</td>
6
    </tr>
7
</table>
8

9
This is another regular paragraph.

预览：

This is a regular paragraph.

Foo

This is another regular paragraph.

请注意：在块级 HTML 标签内不会处理 Markdown 语法。

与块级标签不同，在行内级标签内会处理 Markdown 语法。

代码：

1
<span>**Work**</span>
2

3
<div>
4
    **No Work**
5
</div>

预览：

Work

**No Work**

***