MrBin的博客

测试

Sun, 05 Jul 2026 00:00:00 GMT

测试

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 → 一键部署，即可拥有专属高速图床。

上天会一直出同一道题给你，直到你做出改变

Sun, 03 May 2026 17:43:01 GMT

原 WordPress 正文为空，已保留原始标题、日期、分类和封面。

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/文件夹关联，编写完成后直接同步，无需手动复制。

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 仓库自身能力”的方案开始搭。

怎么使用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 重启或禁用再启用），确保配置生效。

终于！！！EI会议接收！！！

Tue, 17 Mar 2026 08:20:43 GMT

草，拿下！！！

恭喜T1六冠

Sun, 09 Nov 2025 15:47:01 GMT

有一个近乎完美的对手应当是人生的一件幸事，他会让你被动的时刻反思自己，逐渐进步

论当代NTR题材的失格

Wed, 23 Jul 2025 01:51:02 GMT

从几个游戏来论述当代NTR题材（有兴趣的可以去玩一下---------除灵猎人:第零羔羊, 那个江湖,贫民窟向导,炼金幻想R~少女的炼金炉~,源初之心等rpg游戏）本质就是出轨，没有NTR的过程，只有嘿嘿嘿和没有性格的女主，以及当代社会下的浪漫主义名存实亡的现实。

首先，我直接称述我的观点，在目前市面上的NTR作品中，大部分作品只是表面的NTR，没有深度去探讨这个领域的思想与内涵，只是单纯为了嘿嘿嘿和色图，往往只是单纯完成了整个游戏内容的开发，却丢失了最为重要的部分，为什么会有NTR的存在或者说，为什么会有女主角自愿被上的内容，核心观点就是在夺得女性肉体上的“爱意”之前，先得到女方的心。

我们来看这样的一张图（泛式的图）

我们可以清楚的看到，NTR是建立在爱意上的，单纯的嘿嘿嘿并不算是NTR，只是单纯的出轨，而在这里面也诞生出了催眠和直接上床后就离不开这个人的所谓之爱，这些都是作者为了能够进一步压缩整个故事的刻画，节省开发的行为，而正是这些行为直接摧毁了NTR，可以这样说，男女主之间本来就不在存在所谓的爱情，只是女主角被动的因为故事要求，和小处男（短小细）冠以一个男女朋友的头衔，然后出轨高富帅（大黑粗）的故事，这里面既没有纯爱的刻画，也没有两情相悦的感动，更多的就是单纯的头衔关系罢了。

那么正经的NTR作品应该是什么样的呢？我们可以参看下面这4个步奏，也就是要有这4个部分才能来组成整个NTR的情节。首先，得要正经的刻画，细致的描写纯爱，表现出男女主的两情相悦，具体可以参考哪些废萌作品（回家之前的棉花糖, RIDDLE JOKER，千恋*万花，见习恋人等），在完成这个的基础上再进行下一步，也就是胁迫，这个胁迫内容非常重要，将会直接影响后续的所有行为的合理性。

在日常生活中，我们面对胁迫的正确行为是什么呢？答案是报警，对没错，只要你遇到有任何人要挟你，你需要的只是单纯报警说黄毛勒索你万事了，再加上现代社会女性的权力远远大于男性，一篇合理正经的小作文可以轻松让黄毛下半辈子都不得翻身。那么回到游戏，因为游戏内的剧情是架空世界，可以是异世界，可以是现代世界，也可以是基于现代世界的幻想架构，那么这个胁迫就可以变得合理，变得有说服力，比如：黄毛知道女主角是什么邪物转世，或者魅魔，或者单纯用男主的安全做要挟，这些都是非常合理的。

但是，往往不少作品在这个过程中，忽略了女主角的内心变化，可以这样说，这类作品往往之前没有一点铺垫的话，后续内容就是完全的降智，女主角在对男主有着明确设定的好感和喜欢甚至是男女朋友的关系时，没有任何体现内心纠结和挣扎的过程，没有各种暗示男主，没有那种相视无语的沉默，甚至在重复之前纯爱篇的日常行为，我不禁想问，女主角是木头嘛，还是飞机杯，就单纯除了被上就没有更多的表现了，除了色色环节的各种嘿嘿发言，没有一点自己的思想变化，就是单纯的被操爽了，所以就喜欢上黄毛了，苦主就直接像条狗一样，踢到一边就完事了，这既不符合人设的转变，也不符合一个正常角色的变化，用通俗的话就是，女主角突然就傻了，只认得性器官了，没有一点点情感，那么你怎么说这个是NTR呢？整个作品表现出来的就是女主角本来就不怎么喜欢男主角，突然出现一个自己更喜欢的就马上喜欢上了，然后就出轨了，没有挣扎，放到现实世界里面就是，你喜欢的女生突然之间告诉你，我们分手吧，我被黄毛操爽了，你自己滚一边去吧。我都不敢想象这样的话被爆出来，女方还能正常生活下去嘛，无论是从感性还是理性分析，你都会得出，女生是TM弱智，这个世界有问题。所以在胁迫篇里面，必须要详细的刻画女主角的内心变化，以及内心的纠结，最重要的是把前面纯爱的内容进行毁灭，用来和胁迫篇的内容进行强烈的对比，用来扭曲女主角的观念，从深爱男主角到舍不得男主角，最后到抉择到底要和谁过下一生的过程，也就是说，胁迫篇要深刻的描写女主角的纠结，描写肉体上的欢愉但是精神上是厌恶的，是憎恨黄毛的，是内心的忏悔和痛苦的面对男主对她的好的。

所以，我们来看两个样例——恶魔五天榨汁机和除灵猎人:第零羔羊，同样是BBQ的作品，为什么我会说这一部会好过他的除灵猎人:第零羔羊，很简单，至少这一部作品还稍微刻画了女主角的痛苦以及迁怒男主的不作为（你tm什么都不说，男主是tm神仙什么都知道是吧），而除灵猎人:第零羔羊就完全没有，女主角从头到位都是存粹的傻逼，在明确和男主角是对象，自己被胁迫的时候，没有任何的作为，无论是反抗还是象征性的抱怨，都没有，黄毛各种肆意妄为，男主角需要24小时拼命保护女主角，女主角没有一点意识，没有感激男主或者主动配合男主的行为，女主角就像是傻逼一样，只要被胁迫就乖乖被威胁，被上，这个过程中，也没有对男主有什么不舍，也没有什么愧疚，她只是单纯的抱着这样的想法——黄毛好坏，妹妹我好爱的过程，但凡她真正意义上反抗过，这个故事第一幕就完结了，不会有后续，整个故事的发展需要建立在女主角降智的大背景下，才能逻辑自洽，但正是这样的逻辑自洽毁掉了NTR的本质——摧毁美好的事物给人们看。

最后，我们来到结尾篇，这一篇章往往有着非常重要的意义，是整个作品真正值得探讨的，及人的精神是否能够被肉体所支配，人所谓的精神自由独立是否从始至终都是一个笑话，再往前延展就是物质基础决定上层社会的逻辑是否也是能够用在人类从古至今一直传颂的“爱”上面，人们一直在各种科幻作品中提到的爱情让人独一无二是否本身就是一个悖论，是经不起推敲的，人们不可避免的要面对乌托邦世界里面的“任务配偶”，这是否是必然发生的，都是值得探讨的。而作品如何表现就是通过女主角的行为，是告知男主角一切后的被男主救赎——原谅，这里的原谅并非是现在广为笑话的“原谅”女方的无底线行为，而是具有救赎意义的理解对方，包容对方，并愿意用余生保护女主脆弱的灵魂（代表作品Fate stay night：Heaven’s Feel），使得女方能够找到一个精神的寄托，真正意义上体现了爱情的伟大，是包容和理解，是无私的奉献，是一生的默默的守候，而不是随口一说的“诺言”。同样，也可以是女主彻底的放弃，彻底的堕落，承认肉体支配精神，精神永远不是自由的，灵魂是局限的，我们不是加缪书中所写的快乐的西西弗，我们只是痛苦束缚的西西弗。这其实也论证了，人生来就是和动物一样，所谓的爱情只是古老的传说，是文艺复兴的额外产物罢了，乌托邦世界的“任务配偶”才是真正的归宿，正因为人是局限的动物，所以只有这样才能保证人类社会的发展，维持文明的延续。（某种意义上，也进一步证明了人和现在的所谓AI——深度学习模型，没有太多的差异，因为本质就是对动物的模拟，人的所谓感情就是纯纯的笑话）

至此，本文论述了NTR存在的意义，它并不是单纯的色色内容，相反，在这里可以深刻的探讨人的行为，人的灵魂，爱情的定义，以及社会发展是否本身反作用于人本身并摧毁人的灵魂，古往今来，多少外国文学著作谈到的爱情往往是出轨和情妇，这是有一定原因和合理之处的，简单的鄙夷这个东西只是说明了现在人的思想文化不如文艺复兴时的自由浪漫罢了，浪漫主义已死，不仅仅体现在生活中，也体现在文化发展中。

长大之后越来越明白一件事

Tue, 01 Jul 2025 05:35:40 GMT

一千个人心中有一千个哈姆雷特，我怎么想的不重要，你觉得我怎么想的也不重要，我不告诉你我到底怎么想的，很重要。

论为什么关注度很高的高考作文其实是很无聊的一个东西

Wed, 11 Jun 2025 02:44:40 GMT

喜欢创作的朋友们应该都明白，写作最重要的无非就是两个因素，一个是叙事逻辑，一个就是情感加持。然而现在高考作文喜欢什么文体？是议论文，传统记叙文几乎快要灭绝了。出题者喜欢让考生读一些抽象的素材，指引学生往宏大叙事上靠。与此同时，文章一味强调结构，修辞，技巧。这种文章还要让考生写出感情，这无异于在马桶上雕花。这样写出来的文章，没有任何感情与灵魂，只有假大空，反手就扔进了垃圾桶。所以你能看到，网络上有很多连话都说不明白的人，简单一件小事能说个七七八八，毫无逻辑可言。抖音上也总有人喜欢发些高深的抒情文案，仔细一品，不过也是把一堆乱七八糟的网络流行假文艺语句缝合成一个四不像。意义不明的意象，物象，一堆八竿子打不着的东西被缝在一起，不是用力过猛就是记流水账，让人看了只觉得空洞混乱。擅长写高考作文的，其实不是作家，而是在办公室里面给领导写材料的那帮人，他们可太会公式化创作了。应用类文章，不需要积累，只需要套模板即可。而且语文教育的阅读理解分数占比很大，学生却很少有机会去读完一本课外名著，导致学生的写作与阅读能力更弱了。写作需要知识积累与生活阅历。而十七八的学生，几乎都没有。我不清楚为什么这么多人喜欢痴迷于每年讨论高考作文，或许这可能是被他们神圣化的高考里，唯一一件能插上几句嘴的东西。毕竟文无第一嘛，公说公有理，婆说婆有理。我甚至能想象出他们眼里公认的高分作文：以吹嘘宏大之物为基本点，举出各种名人案例加以佐证，辅以华丽少见的修辞，加上不知道从哪个短视频偷来的少见的古文名句与西洋哲学黑话。把文章的语言搞得讳莫如深，云里雾里，最后加上令人亢奋的结尾。恭喜你，这就是一篇50+作文。真的想发表一个暴论：做一个晚自习语文题甚至不如花一晚上读一本名著有用。只是做试卷上那些琐碎的公式化阅读题，反而会降低你对文字感知能力。也导致很多人极其讨厌语文课，上课不是讲话就是睡觉，反正语文嘛，再怎么也不会考太低。身边统计学显示，那些爱看闲书的小说痴子，语文成绩都还挺好。语文本来是一门略带艺术性的学科，而如今却如此肤浅与冰冷。尤其是写作，本该是最能抒发思想与情感的方式，但如今考生们只能戴着镣铐跳舞，被逼着写一篇连自己都觉得虚假的现代八股文。所以每年的六月，看到那些各路人马，热衷于讨论那些歌颂宏大的高考作文题目多么多么难的时候，我都会感觉到厌恶。一群没读过几本书，连字都扣不明白的人，这时却热衷于讨论该如何写一篇看似深奥的文章。或许他们不是想展示他们多有文采，而是只想表达他们有多么会做题。

关于＂性压抑＂

Wed, 23 Apr 2025 03:11:18 GMT

什么是性压抑不确定，但什么不是性压抑，齐泽克举过一个很有想象力的例子，《面具与真相》第三章《烽火赤焰万里情》的例子，那里的描述和性压抑截然相反，如果我们把性压抑定义为干某件事情时心里还想着性（比如那个经典梗，男的给女的讲哲就是想上她），那么齐泽克对《烽火赤焰万里情》的解读是截然相反。

在拉康—齐泽克的视野中，“性压抑”并非我们日常所说的“心里老想着性就叫压抑”，而是指那股超越快感原则本身、又带来痛苦与过量的“享乐”（jouissance）被象征秩序所冻结、转向与否定的过程。早在婴儿对母亲的原初依恋中，就注入了象征的大他者：语言、法律、社会规范如同无形的“否定”，告诉我们某些冲动不可触碰、某些快感必须被埋藏。正是因为这种否定的力量，真正的性欲望才不断在潜意识里蠢动，透过梦境、口误或症状反复现身——压抑不是欲望的消散，而是它在层层表象之下的隐秘滋长。

在《面具与真相》第三章中，齐泽克选取《烽火赤焰万里情》这一革命爱情故事，为我们呈现了一个与性压抑截然相反的场景。战火硝烟里，两位革命战士在被集体使命与生存危机包围之时，所有的纪律约束和社会耻感被瞬间悬置：他们不在暗室里低声细语，也不在宾馆里挑灯夜战，而是在炮声稍歇的前沿阵地，把血与汗、尘土与欲望混为一体，毫无遮掩地投入一次狂野的联合狂欢。这一刻，他们并不将性视为需要掩藏或提升为“更高”文化活动的冲动，更无需借助“工作”“艺术”“爱国主义”等外衣来转化那股暴烈的能量。

正因为没有象征法则的介入与否定机制的运行，这场当下的性爱才成为了纯粹的、过量的 jouissance。齐泽克提醒我们，平日里那些被冠以“健康”“文明”的性爱，其实都是经过重重筛选、被迫戴上了理智与规范的面具；而在烽火中被剥离的那种无需羞耻与掩饰的快感，才是真正打破压抑、直抵欲望核心的现象。这并非“越野生越好”，而是让我们看清了压抑的本质：它并非单纯的“否定欲望”，而是欲望在否定之下日益强烈的反抗。

此外，这种“非压抑”状态本身也带有强烈的意识形态色彩——革命理想在此时化作保护伞，使两人的自我羞耻与社会耻感彻底失效，性与政治激情融为一体。与那些通过“科教”“加强体质”“爱情至上”等借口把性能量压平再利用的现代话语相对，这场性爱反而将性与更高的集体目标并置，展现出一种“积极的享乐主义”，让我们看到：性压抑与性释放并不是简单的黑白对立，释放本身也可能是另一种强制，一旦置于某种共同体的需求之中，它就会被赋予新的意义和功能。

从齐泽克对《烽火赤焰万里情》的解读可见，真正的压抑恰恰在于那种“不能说”“不能做”之下的长期隐忍与掩藏——越是刻意隐藏，越在裂缝中积聚能量；而当象征秩序的“否定”被暂停，欲望就以最原始的姿态爆发，带来既痛苦又狂喜的极端体验。理解这一点，才能避免把“做某件事时顺便性幻想”当作压抑，更能看清各种文化与政治话语如何借用、转向或强化性欲望背后的那股“危险的真实”。

浮生梦

Sat, 08 Mar 2025 07:22:55 GMT

蝴蝶隔着玻璃振翅每一粒齿轮都在咬住溺亡的黎明有人用银匙舀起我颅骨里褪色的萤火

鸢尾倒悬成第七阶正在腐烂的紫色泪水潮水褪下盐粒时露出正在结痂的伤口所有倒影都陷进深蓝的溃疡锈蚀的锚长出珊瑚的骨刺

候鸟喉咙里卡着永不融化的冰层当褪色的星群溶化成最后一粒止痛片候车长椅正被风蚀成蜷缩的灰烬

月光漂白指纹的沟壑我们的名字正在被蚀空有人在逆流的时针背面缝补着褪色的胎记有人用冻僵的手指弹奏铁锈的喉咙

直到所有隐喻都渗出盐晶直到蝴蝶翅膀的震颤让所有碑文都开始风化结痂、结痂、结痂

因此，我们离开

Wed, 26 Feb 2025 06:49:13 GMT

候鸟的舌尖最先尝到迁徙的苦味我们在黄昏时清算行李把长满苔藓的誓言和未拆封的地址一同锁进铁盒

潮水褪去时沙滩上尽是盐粒结晶的骸骨有人弯腰捡拾贝壳的空腔却听见多年前的对话仍以漩涡的形态在耳道深处轰鸣

我们曾共用同一具影子在正午的柏油路上融化彼此直到暮色像玻璃刀片划开所有重叠的边界直到月光开始征收每个孤独的直角

而候鸟早已飞离字典的封面它们的翅膀切开季风切开那些淤积在喉咙里的地名此刻我们终于学会如何用沉默丈量距离用缺席确认存在

因此，我们离开成为彼此地图上永远向北方倾斜的虚线成为潮水退却后盐粒在月光下闪烁的永恒瞬息

谈谈炒作带来神奇的权威性，与权相同威力的神药

Tue, 17 Dec 2024 13:03:32 GMT

下面分析炒作的真实目的以及大家为什么讨厌炒作狗由不知道也根本不重要的某个人正式开启网络大炒作时代之后，网络上的很多人便深受炒作所带来的严重信息骚扰。他们不在乎炒作的对象也不在乎炒作的内容，却不得不面对海量的炒作信息，这些信息有时甚至会越过网络的边界向现实延伸，侵扰大家的现实生活。那么究竟是什么让这些人或某种事物如此热衷于炒作，让网上铺天盖地充斥着有关他们的事情呢？答案是这些炒作的人都或多或少的意识到热度=权威性，也可以简单理解为名声。权威性的作用有很多，其中最重要的就是获得不同人的不同程度信任与好感。就像我没有权威性所以你不会点进我的贴子看我长篇大论，就像我没有权威性所以你会觉得我所谈论的东西都是瞎扯淡，是没有意义的废话，空话。反之如果我拥有权威性的话，重要的是在你心中有权威性，那不管我说什么你都要听一听，看一看，我的存在时刻吸引着你的目光，明星效应就是这种现象最好的表达。例子也根本不需要刻意去找，看看吧里或其他地方那些有权威性的人，随便说两句话或分享下日常都能获得一大堆回复，而没有权威性的吧友们说话则大多无人理睬，长篇大论也只有寥寥几个回复。这时有些人便会意识到并试图去获取权威性，这也就是炒作，也就是吸引大众目光，也就是为了获得关注而做出的种种行为。去发些大家喜欢的东西，去喷些大家厌恶的东西，去盘点些大家喜欢看的东西。核心要点在于要碰到大众喜好这个关键物品，最终结果是愉悦大众还是惹恼大众就取决于碰得准不准。获得关注是炒作所结出的硕果之一，这就是为什么马斯克要拿下蓝鸟并在上面没日没夜的到处互动，他之所以深谙炒作的重要意义就是因为他极大的享受到了炒作带来的好处，也是为什么他在发现人们对他逐渐失去兴趣后会立即尝试更换炒作方法以及更积极的去互动炒作。马斯克是典型到不能再典型的炒作狗例子了，但我还是想以另一位跟他同样在蓝鸟上积极甚至狂热频率发言的人做例子。

这个人就是小岛秀夫，我并非是在喷小岛秀夫也是条炒作狗，而是以他为例子更有意义，因为马斯克很聪明的从不在网上提起炒作给他带来的好处，而小岛秀夫提到过。事情是这样，小岛秀夫离开科乐美后成立自己的工作室做游戏，之后他遇到了资金问题，对资金问题的解决办法是找银行借钱，但所有银行给出的答复都是拒绝，除了一家银行，这家银行的管理人称自己是小岛秀夫的狂热粉丝，于是小岛秀夫得到了银行借钱。小岛秀夫说过那些银行用来拒绝他的话，虽然小岛先生很有名气，但作为个人却没有实绩。意思是银行们知道小岛秀夫有权威性，也知道这权威性来自制作游戏方面，但他们不了解游戏，银行们关心的是作为企业家的权威性，而小岛秀夫在开办企业这方面没有名声，所以银行们不觉得小岛秀夫制作游戏能成功于是开办企业也能成功，所以他们拒绝借钱。那为什么这种有理可循的判断到了狂热粉丝所在的那家银行就变了呢？狂热粉丝的判断也理应跟其他的银行相同，然后做出跟其他银行一样的答复。答案是小岛秀夫的权威性在他心中真正存在并且是高权威性，这种高权威性使得作为银行管理人的狂热粉丝相信小岛秀夫有可能开办好企业，于是同意借钱。之后小岛秀夫想租个好办公楼的时候也同样是在狂热粉丝的帮助下得以租到。小岛秀夫这位知名游戏制作人能获得如此大的帮助当然离不开他在游戏制作方面的成就，可如果没有炒作的话，别人又怎么知道他的成就又或者说知道他这个人呢？新闻的曝光，在游戏社交媒体上频频出现，与各类人士的接触，这些都是小岛秀夫自己主动参与的，说明他也或多或少的意识到炒作能给他带来好处，于是便乐此不疲。小岛秀夫的原话我正是借助着人与人之间的连接才能开发出自己的游戏。

下面再举一例，也是典型到不能再典型的例子，不过并不是一个人而是一款游戏。赛博朋克2077，这款游戏在发售前疯狂炒作，各种活动，游戏新闻媒体头条，网上博主发视频大吹特吹，目的当然显而易见，是为了增加销量。这里谈到2077也是为了解释权威性究竟有多大威力。权威性就如同词汇里的褒义词，是绝对正向情感的，虽然炒作有红黑炒作之分，但这里只谈红的那一部分。 2077的一切炒作最终所导向的结果都是让全球玩家觉得它是一款好玩的顶级游戏，进而预购它，那么它是怎么做的？因为不想废话太多所以直接给结果，2077尽自己一切可能来营造出一种极端的氛围，即发展到今天被称作造神的氛围，完美二字在这个氛围中体现得淋漓尽致，它，2077这个游戏在这种氛围中被塑造成没有任何缺点的完美游戏，重点是在这种氛围中没有一句不好的声音，怎么做到的？2077的制作公司在宣发的过程中不断向外界抛出这款游戏的优点，正如其他的炒作狗不断向外界抛出自身的优点，闪光点。而这个过程中观众们连看到游戏缺点的可能都没有，因为这个过程被专门细致打磨抛光，无瑕的光彩在其上闪耀，这也正是所有成功的炒作狗都在干的事。提到赛博朋克2077的意义此时显现，它的炒作成功了，在没有任何实机演示的情况下2077真的做到让大部分人以为它是一款好游戏，我们再来提一下好游戏的概念，一般来说，好游戏是玩过之后得出的结论，然而2077却在人们玩到它之前，甚至是见都没见过它的情况下得出它是好游戏的结论，就如同LPL全球总决赛决赛还没开打，某队获胜的新闻就已经出现在媒体上，就如同DOTA2TI决赛还没开打，就已经有人说出一觉星来又是个冠军这样的话然后等着庆祝，就如同某个奖还没颁给某个游戏，那游戏就已经提起开好香槟准备发表获奖感言。

这样反应不就是高权威性在人们心中植入并让他们相信这种权威性所述说的任何话语吗？重点不在于是否真的能做到而是让别人以为你能做到。炒作是获得权威性的一个便捷途径，而权威性是带来信任与好感的便捷途径。因为各种理由诸如没有时间没有精力甚至是没有渠道之类的去细致了解一个人或某种事物，人们便不得不通过其身上的权威性来让自己信服与否，这样的思维逻辑也让一些人意识到，只要让自己获得权威性便可以轻易博取大部分人的好感与信任。这可不是什么现代才出现的玩意，巧立名目，古代的人们也意识到如果自己没有权威性的话就要通过各种方式来炒作自己赢取名声，进而得到自己想要的东西。关于炒作的真实目的简单概括到这，下面来说为什么大家会讨厌炒作狗。

先提出疑问，如果不炒作的话权威性一般从何而来？以长辈为例子，孩子在出生后成长到少年期之前，在父母正常养育的情况下，孩子会无条件相信父母，认同父母述说的理念，这个阶段父母是具有权威性的。到了接受教育的阶段，青少年又会相信教育系统教给他的舍会知识，这个阶段教育系统是具有权威性的。那长大了呢？长大的人一般是以自己一直以来接受到的知识里所定义出的能让他们认同，尊重的人具有权威感。所以炒作狗们通常会有个正向人设。但问题是有些人对于具有权威性的人有自己独特的定义，所以那些试图炒作出自己权威性的炒作狗在他们眼里就像耍气球的小丑在说自己明天要用气球上太空去殖民卫星。厌恶炒作狗的虚伪正向人设，厌恶虚伪正向行为，理由有很多，关键在于人们看到了炒作的背后真实本质和真实目的。归根结底是在抵抗这种权威性，不愿意因为炒作狗的热度，炒作狗所炒作的东西就去信任和对炒作狗卝产生好感，甚至最后产生出厌恶。

感觉说得已经差不多了，感谢你能够看到这里，可以的话请带着论点直接指出我的不足。还有想再调侃一下以前一直看的一个游戏媒体博主，2077炒作的时候跟着一起疯狂炒作欢呼喝彩精神趋势，结果游戏发售塌房瞬间切割狂喷，让我不得不感慨不愧是做媒体的。

饿殍：明末千里行

Sat, 14 Dec 2024 12:48:05 GMT

这款游戏很早就入库了，但一直没有时间去玩，最近终于找到时间通了。依然是熟悉的味道，和我之前玩《葬花·暗黑桃花源》时候的感觉差不多，但是在许多地方都有了很大的改进，整体看来让我感觉欣喜，甚至有一些惊喜的地方。

首先我表明态度：《饿殍：明末千里行》是一款十分优秀的游戏，它在前作《葬花·暗黑桃花源》的基础上，对短板进行了许多改进，让这部游戏成为了今年我个人认为在制作层面十分“正确”的游戏，我认为游戏的制作风格上已经找到了正确的路子，坚持走下去必然会取得更大的成功。

在说这个游戏“正确”的地方之前，不妨来想想目前的所谓“Galgame”市场存在的问题。许多人说 Galgame 已经是夕阳产业了，日本那边算是半死不活了，在手游和轻小说的夹击之下，销量惨淡。而我国也有许多人想要创造自己理想的 Galgame，近年来看到“国Gal”内容也越来越多，但总归是难以掀起什么波澜，甚至至今为止都有许多人对这种“点点鼠标看故事”的游戏嗤之以鼻，不知道乐趣在哪里。

我玩过的 Gal 也不少，曾经最疯狂的时候一年玩 50 多部，每个月有新作就赶紧去尝试，这种热情持续了有好几年，到了现在开始逐步消退，倒不是说我没时间了，也不是说没热情尝试 Galgame 这种游戏的。更多的问题是我发现这些游戏大多数都“大同小异”且“毫无进步”。

我来说说这类游戏最大的问题：

1，叙事又臭又长一部全价格的 Galgame 的剧情往往有 20-40 小时，而主线故事大概也就 1 个小时就能说清楚，其他的时间全都是所谓的“日常”，你要说日常写的有趣还好，但大多数日常并不有趣，很多都是在玩那些不知道多少年都用烂的俗梗。而且很多所谓“神作”的日常内容不仅不有趣，反而很催眠。许多被“神作”名头吸引来的新玩家都会被这无聊的注水故事所劝退，但总会有“老玩家”充满优越感的告诉你：“这脚本就这样”，“坚持一下，到XXX线就好看了”。在我看来这更像是一种 PUA，既然到了 XXX 线就好看了，那你前面写那么多垃圾给我看干嘛？这种“注水日常”的结构脚本写着痛苦，玩家看着难受，为什么不能进行精简和优化？

2，可玩性极差我要说一点，早些年的 Galgame 的系统其实没有现在这么简单，大多数都会装模做样的设计一个“可玩性”的内容，比如即将倒闭的 Alcot，出道作 Clover Hearts 还有收集成就系统。现在的 Galgame 反而越来越素，有的从头走到尾只有一个选项，有的甚至一本道，选项都懒得给你了。从头鼠标点到尾，甚至 Backlog 都不给你做，我觉得这不仅仅算不上是一个“游戏”，甚至作为一个“可视化有声读物”来看都是不合格的。我坚持认为 Galgame 虽然是以看故事为主，但仍然需要增加一点“互动性”，应该给玩家“探索故事篇章”、“解密”、“与角色互动”之类的操作感，这样才会吸引更多人玩下去并找到乐趣。

3，千篇一律的剧情框架这个其实玩 Galgame 多的人都能明白，大部分 Gal 都离不开“学生会”和“校园”，那永远无法摆脱的“学院祭”，还有那明明一节课堂没描写过，也非要写出来的教室剧情，就连日本人自己都觉得假的不行。更抽象的是国产 Gal 还非要去模仿，这种“全盘照搬”的感觉更像是当今说唱歌曲无脑学习老黑的匪帮一样，人人都 Gang gang，结果玩具枪都没摸过。脱离校园框架的 Galgame 也有，但最终也都无法逃离那擦边的老一套，Galgame 和 Erogame 之间或许有重叠，但并不是同一种东西，目前“Galgame”这个字眼已经基本跟“色情”这个词汇捆绑在一起了，你说你玩 Galgame，十有八九对方会一副恍然大悟的样子“噢噢噢噢，Galgame吗，就是类似艹猫的那个呗。”

接下来看看《饿殍：明末千里行》是怎么做的。

首先，游戏篇幅很精简，很多人说这是缺点，篇幅太短，但在我看来这是最大的优点。一个新玩家基本上半小时就可以切入主线，搞清楚“我是谁”，“我在哪儿”，“我要干啥”，不会给你莫名其妙的又臭又长的所谓“共通线”，更不会让你坐牢一样的看 10 小时不知所云的文字，才会插入一个所谓的 OP 开启正片剧情。这十分有助于玩家快速投入游戏，很快获得剧情上的反馈。

其次，游戏有一定的“可玩性”，这一点主要来自游戏里增加的许多 Bad End，在剧情进展过程中出现的一些选项会迫使玩家做出抉择，抉择的失败直接导致剧情的悲剧结束。这些“坏结局”基本和主线没什么关系，但却不仅给游戏增加了一些紧张感，更多的还是“娱乐性”，选对了剧情继续，选错了也有完善的 Flowchart 可以让你快速定位回来。游戏的多结局搭配 Flowchart 可以快速让玩家多周目解锁，而许多锁定的剧情也暗示了条件，让玩家在不断的尝试中有了“探索”的体验。

虽然这点“游戏性”比起常规的游戏来说只是杯水车薪，但它的确有，而且对于“文字冒险”类来说已经十分充足，也达成了锦上添花的效果。

最后就是游戏的剧情定位：明末时期，十分接地气的中国本土主题，没有任何日系的元素在里面，更没有什么“二次元味道”的用词和文本。游戏的故事谈不上有什么深度和反转，但是很直接和清晰，用“人吃人”之类的手段来加深对历史残忍的描绘，里面也有一些熟悉的元素，闯王啊之类的，也带了一些或许可以影射现实的讽刺，我觉得这样就足够了。

总体看来《饿殍：明末千里行》在之前《葬花·暗黑桃花源》的基础上进行了许多改进，用了更为直接甚至贴近历史有一定人文元素的剧情，更为完善的 Flowchart，更清晰的剧情脉络，更好的画面，当然也保留了那些充满地雷的选项来提升游戏性，这一切都让本作变得十分“简单易上手”，可以说《饿殍：明末千里行》极大程度降低了所谓“Galgame”的门槛，哪怕是没有接触过传统日系 Galgame 的玩家，也可以很容易的尝试并享受其中。

于是我就看到了十分让人忍俊不禁的情况，这个游戏在许多 Galgame 论坛里被类比”原神“。

我是能理解这群人的想法的，他们依仗着”Galgame“这个小众的品类，以及语言的壁垒和游戏极高的门槛，而产生了独有的优越感。他们一边感慨着业界要完，一边也不在乎 Galgame 是否应该吸引更多人来玩，只是希望维持着自己“众人皆醉我独醒”一般获取信息差一样的优越感。

所以当《饿殍：明末千里行》这种上手门槛低的作品出现之后，带来了更多的新玩家和讨论度，这些充满优越感的“老家伙”们自然也就坐不住了，开始极尽嘲讽之事，以求维持自己高冷品味的独特。他们喜欢的还是那种系统简陋，剧情充满中二的“哲学类”词汇拼凑，最好是永远不会被汉化的那些“宝藏冷门神作”，不然怎么体现他们尘缘已断金海尽干呢？殊不知所谓 Galgame 的作品早已过了黄金时代，现在的新作剧情说句不好听的没准还真不如原神 3.0 以后呢。

其实我更欣赏的还是《饿殍：明末千里行》和《葬花·暗黑桃花源》的制作人，我记得多年前他在微博某二次元相亲号上整了个活，也在知乎吐槽过现在的漫展搞起来很抽象，实际上他算是一个十分资深的二次元了，游戏一直坚持找 hanser 配音其实也是他个人的追星行为，我想他应该完全明白那些所谓的“老二次元”理想中的 Galgame 样子。但即使如此，他也在制作游戏的时候保持了极大的克制和清晰的头脑，他十分清楚应该制作怎么样的游戏才能称之为“真正的国产文字冒险作品”。没有做出什么“披着中文皮的日本游戏”，也没有无脑的模仿和拷贝日式 Galgame 的框架。而是选择扎根本土，根据受众和用户群体进行调整产品，做出了门槛更低，更适合大部分玩家的“文字冒险游戏”，也让这个类型的作品出圈，吸引了更多人的关注，实在是难得。

我十分期待他的下一部，也希望他能获得更大的成功。

尼玛的终于修好网站了！！！！！！！

Sat, 14 Dec 2024 12:17:28 GMT

尼玛的自己动手搞了半天，，差点想放弃了

尼玛的还好阿里云帮我备份了云盘，不然真的就say goodbye了~

结果发现只需要从宝塔面板更新下SSL证书就好了

雷姆QAQ

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

コイバナ恋愛：可攻略与否并不是最重要的问题

Sat, 02 Mar 2024 16:16:36 GMT

当我听说 Asa Project 的新游戏《コイバナ恋愛》被冠上“地雷”标签的时候，我直接就惊了。

虽然我认为它们的游戏和之前的各种颜艺话题作相比的确是走了下坡路，但怎么想都应该和“地雷”沾不上边吧？

Asa Project 可是一直在做各种“政治不正确”的游戏类型，突出一个“胡搞瞎搞”，游戏中不但可以给男孩子强行性转成女孩子，各种搞基结局也是信手拈来，我觉得这个品牌的受众群体本身就是乐子人为主，都对 Asa Project 游戏有一定预期，也有一定的心理承受能力，怎么可能会被它们整的活所破防，然后贴上“地雷”标签呢？

而且在我印象中，2023 年 Asa Project 的新作《コイバナ恋愛》更像是那种“青春群像剧”的设定，说白了就是一种“男生女生对对碰”之类的剧情，标题也说明了一切，コイバナ指的就是“和恋爱有关的话题”，コイバナ恋愛就有种“恋爱脑大集合”的感觉。你就告诉我这样的剧情怎么可能会有“地雷”？除非是男主角加入了以“青春”为名的乱交换妻俱乐部之类的。

所以抱着好奇的心态，我就去看了一下这个游戏，初步感受就是本作的确不咋样，我也明白了为啥会有人说这里面有“地雷”了，但造成本作质量不佳的原因却并非是那个“地雷”，而是另有别处。

那么就让我们详细展开谈谈吧：

首先是游戏的剧情十分简单，又是那种写烂的“少子化”+“男女并校”的套路，说的是男生憧憬的女孩和现实不符，反之亦然，进而在并校之后开展的情侣碰撞，只不过加了一个“理想与现实“的外壳。但与众不同的是本作的情侣并非只有男主角一对，而是男主角可攻略四位，剩下的三位女配角则是分给了其他的男配角，最终的结局就是至少会成就四对情侣。

这个设定就触碰了许多 Galgame 玩家的逆鳞了：老子是高贵的 Gal 男主，游戏里的所有角色无论男女的都应该可以被我攻略，结果你这个游戏反而把女配角许配给其他男主，三个性格迥异的妹子，我身为男主居然不可功能攻略？这完全不能忍受，反而带来了“NTR”的感觉，地雷！妥妥的地雷！

然而本人对这种观点一直也是无法理解的，现代大部分 Galgame 中男主角的姓名都已经被确定，即使你扮演第一视角，但故事中的男主也是有自己的性格和名字的，完全无法体现出什么“代入感”，想体会这种感觉的你应该去玩那些可以自定义男主角名字的游戏才对，很显然，Asa Project 并不是这么一款游戏。

那么是不是证明本作在剧情上没什么硬伤了吗？当然不是，不如说本作在剧情上十分的令人不爽，不爽的地方依然是前面说的那个“配角情侣”部分。

本作中虽然我们的男主角可以选择四位美少女来进行攻略，但很明显这四位候选人不仅无聊，甚至有一些远离“恋爱“的范畴，比如口口声声说想要“白马王子”讨厌男生但是还天天和男生打得火热的黑毛，还有一个号称是男主的理想型并且让男主一见钟情，但是完全对男主没有什么恋爱感觉只是把男主当玩具的橘毛，还有一个已经用烂不知道多少次的标准青梅竹马模板的黄毛，还有一个超电波系但和之前的各种颜艺角色相比完全没有竞争力的紫毛，而和这四位极度抽象的可攻略角色比起来，三位配角女主就显得有趣得多，有典型的傲娇型的，有闷骚型的，还有笨蛋型的，每一个都是可以带动剧情节奏的存在。

所以这就导致这个游戏形成了一个十分奇怪的感觉，配角的恋爱故事比主角好看，比主角精彩，甚至戏份占比都比主角来得多。尤其是剧情中期竞选学生会桥段的故事，基友和那个傲娇いのり之间的恋爱博弈完全抢占了其他所有情侣的戏份，而在普通的日常剧情中，围绕着”看胖次“为主轴的两位闷骚配角的剧情夺走了所有的眼球，这种鲜明的对比让男主角和他的四位备选女友看起来就像是纯纯的小丑。加上那些精彩有趣的配角都已经“名花有主”，所以更加凸显了这种游戏过程的不爽。

除了在剧情方面的问题，游戏本身的演出方面问题也不少，最大的一点就是“对话混乱”，游戏从一开始就毫无角色引入与介绍的桥段，在玩家还没分清谁是谁的前提下，直接就进入了正片。游戏中存在大量“至少 6 人同时对话”的场景，而游戏没有对这种”你一言我一语”的混乱模式下进行任何优化，加上本作中的 CV 除了秋野花和奏雨之外都没有什么特色，你很难分清楚目前究竟是谁在说话，听着听着你就晕了。哪怕通过不同颜色和类似漫画分镜的方式来辅助演出，都可以很轻松的解决这个问题，但是 Asa Project 并没有这么做。

除了演出方面的缩水导致的大脑混乱，游戏在素材方面也秉承了一如既往的“能复用就复用”的原则，你不仅可以在本作中看到那个已经用烂的“祖传咖啡厅”背景，还有之前在《一つ飛ばし恋愛》里出现的游泳馆，以及在各种之前作品里出现过的各种场景。游戏在制作成本上的极度省钱甚至导致了许多剧情上的损失，共通线中有大量“打乒乓球”之类的运动对抗桥段，游戏甚至没有对此提供一个专属背景和 CG，仅凭一群人在一个不明所以的背景图片下对着空气挥汗如雨，令人哭笑不得。

所以从整体来看，コイバナ恋愛并不是一个多好的游戏，甚至不如之前的那一作以”劈腿“为主题的游戏。但它失败的地方并非是什么”女配角不可攻略“的问题，而是可攻略女主角的内容太过无聊和敷衍，并且远不如配角的戏份占比大和精彩。加上游戏在本身开发成本上的极度缩减，CG的大量复用，各种演出效果的缺失，直接让本作的游戏体验大打折扣，玩起来会让人十分的不爽，也就不难理解为啥会给许多人负面的感受了。

但还是要强调：原因是游戏本身制作偷工减料没做好的问题，而不是什么“可攻略与否”的问题。

换而言之，本作如果能增加可攻略女主角的戏份，认真描写主线剧情，强化演出效果，让对话的中的主体更加明晰，加一些事件 CG，增加玩家的沉浸感，哪怕那些配角依然是不可攻略，本作也会是一个优秀的游戏的。

当然本作也有一些颇为虚幻的地方，比如有主角配角一群人去游乐园玩的桥段，每个人都有心仪的情侣，大家成双成对的边走边说笑之类的，这种十分“现充”的生活，对于这个游戏的受众可能过于超前。真正的现实可能是死肥宅孤身一人作为电灯泡跟着一群现充情侣去游乐场之类的，这在大学生活中也许更为常见吧。

好像我的大学生活就是如此……算了不提了。

Leetcode 27:移除元素——使用双指针进行查找

Sat, 10 Feb 2024 03:53:21 GMT

先看题目

给你一个数组 nums 和一个值 val，你需要原地移除所有数值等于 val 的元素，并返回移除后数组的新长度。

不要使用额外的数组空间，你必须仅使用 O(1) 额外空间并 原地修改输入数组。

元素的顺序可以改变。你不需要考虑数组中超出新长度后面的元素。

说明:

为什么返回数值是整数，但输出的答案是数组呢?

请注意，输入数组是以「引用」方式传递的，这意味着在函数里修改输入数组对于调用者是可见的。

你可以想象内部操作如下:

// nums 是以“引用”方式传递的。也就是说，不对实参作任何拷贝
int len = removeElement(nums, val);

// 在函数里修改输入数组对于调用者是可见的。
// 根据你的函数返回的长度, 它会打印出数组中 该长度范围内 的所有元素。
for (int i = 0; i < len; i++) {
    print(nums[i]);
}

示例 1：

输入：nums = [3,2,2,3], val = 3
输出：2, nums = [2,2]
解释：函数应该返回新的长度 2, 并且 nums 中的前两个元素均为 2。你不需要考虑数组中超出新长度后面的元素。例如，函数返回的新长度为 2 ，而 nums = [2,2,3,3] 或 nums = [2,2,0,0]，也会被视作正确答案。

示例 2：

输入：nums = [0,1,2,2,3,0,4,2], val = 2
输出：5, nums = [0,1,3,0,4]
解释：函数应该返回新的长度 5, 并且 nums 中的前五个元素为 0, 1, 3, 0, 4。注意这五个元素可为任意顺序。你不需要考虑数组中超出新长度后面的元素。

提示：

0 <= nums.length <= 100
0 <= nums[i] <= 50
0 <= val <= 100

解法

class Solution {
public:
    int removeElement(vector<int>& nums, int val) {
        int l = 0, r = nums.size() - 1;
        while (l <= r) {
            if (nums[l] == val) {
                int temp = nums[l];
                nums[l] = nums[r];
                nums[r] = temp;
                r--;
            } else {
                l++;
            }
        }
        return r+1;
    }
};

Leetcode 2535:数组元素和与数字和的绝对差——一道练习数位求和的好题

Sat, 10 Feb 2024 02:32:58 GMT

先看题目

给你一个正整数数组 nums 。

元素和 是 nums 中的所有元素相加求和。
数字和 是 nums 中每一个元素的每一数位（重复数位需多次求和）相加求和。

返回 元素和 与 数字和 的绝对差。

注意：两个整数 x 和 y 的绝对差定义为 |x - y| 。

示例 1：

输入：nums = [1,15,6,3]
输出：9
解释：
nums 的元素和是 1 + 15 + 6 + 3 = 25 。
nums 的数字和是 1 + 1 + 5 + 6 + 3 = 16 。
元素和与数字和的绝对差是 |25 - 16| = 9 。

示例 2：

输入：nums = [1,2,3,4]
输出：0
解释：
nums 的元素和是 1 + 2 + 3 + 4 = 10 。
nums 的数字和是 1 + 2 + 3 + 4 = 10 。
元素和与数字和的绝对差是 |10 - 10| = 0 。

提示：

1 <= nums.length <= 2000
1 <= nums[i] <= 2000

解法

直接进行遍历求和，最后返回相减结果。

class Solution {
public:
    int differenceOfSum(vector<int>& nums) {
        int sum1=0,sum2=0;
        for(auto &i:nums){
            sum1+=i;
            while(i){
                sum2+=i%10;
                i/=10;
            }
        }
        return abs(sum1-sum2);
    }
};

Leetcode 2057:值相等的最小索引——论我和大佬的差距（2）

Fri, 09 Feb 2024 12:00:48 GMT

没啥好说的，感觉回到了高中，仿佛就像你写一道大题用了各种花活，结果别人几行就搞完了，浪费时间（不是）

先看题目

给你一个下标从 0 开始的整数数组 nums ，返回 nums 中满足 i mod 10 == nums[i] 的最小下标 i ；如果不存在这样的下标，返回 -1 。

x mod y 表示 x 除以 y 的余数。

示例 1：

输入：nums = [0,1,2]
输出：0
解释：
i=0: 0 mod 10 = 0 == nums[0].
i=1: 1 mod 10 = 1 == nums[1].
i=2: 2 mod 10 = 2 == nums[2].
所有下标都满足 i mod 10 == nums[i] ，所以返回最小下标 0

示例 2：

输入：nums = [4,3,2,1]
输出：2
解释：
i=0: 0 mod 10 = 0 != nums[0].
i=1: 1 mod 10 = 1 != nums[1].
i=2: 2 mod 10 = 2 == nums[2].
i=3: 3 mod 10 = 3 != nums[3].
2 唯一一个满足 i mod 10 == nums[i] 的下标

示例 3：

输入：nums = [1,2,3,4,5,6,7,8,9,0]
输出：-1
解释：不存在满足 i mod 10 == nums[i] 的下标

示例 4：

输入：nums = [2,1,3,5,2]
输出：1
解释：1 是唯一一个满足 i mod 10 == nums[i] 的下标

提示：

1 <= nums.length <= 100
0 <= nums[i] <= 9

我写的

我的思路：先创建一个ans数组，再遍历一遍题目给的nums数组，当取到正确的数后，将下表存储在ans数组中，再用三个if语句将结果数组（Tips:求数组中的最小值可用函数*min_element(p, p + n)，就是在p~p+n范围内的最小的数，max类同）

class Solution {
public:
    int smallestEqual(vector<int>& nums) {
        int count = 0, j = 0;
        vector<int> ans;
        for (int i = 0; i < nums.size(); ++i) {
            if (i % 10 == nums[i]) {
                count++;
                ans.push_back(i);
            }
        }
        if (count == 0)
            return -1;
        if (count == nums.size())
            return 0;
        else
            return *min_element(ans.begin(), ans.end());
    }
};

大佬写的

思路就不说了，写得很清楚

class Solution {
public:
    int smallestEqual(vector<int>& nums) 
    {
        int ret = -1;
        for(int i = 0;i < nums.size();++i)
        {
            if(nums[i] == (i % 10))
            {
                ret = i;
                break;
            }
        }
        return ret;
    }
};

还有两个月就是蓝桥杯了，冲刺ing。。。

LCP 06:拿硬币——论我和力扣大佬的区别

Fri, 09 Feb 2024 01:44:17 GMT

一道在力扣上的简单问题，我写了几十行代码，别人几行就搞定了

虽然时间上没区别，但不得不感叹代码的可读性真的很重要，既简洁又高效的才是好程序~

先看问题：

桌上有 n 堆力扣币，每堆的数量保存在数组 coins 中。我们每次可以选择任意一堆，拿走其中的一枚或者两枚，求拿完所有力扣币的最少次数。

示例 1：

输入：[4,2,1]
输出：4

解释：第一堆力扣币最少需要拿 2 次，第二堆最少需要拿 1 次，第三堆最少需要拿 1 次，总共 4 次即可拿完。

示例 2：

输入：[2,3,10]
输出：8

限制：

1 <= n <= 4
1 <= coins[i] <= 10

我的方法

class Solution {
public:
    int minCount(vector<int>& coins) {
        int ans = 0;
        for (int i = 0; i < coins.size(); ++i) {
            while (coins[i] % 2 == 0) {
                coins[i] -= 2;
                ans++;
                if (coins[i] <= 0)
                    break;
            }
            while (coins[i] != 1 && coins[i] % 2 == 1) {
                coins[i] -= 2;
                ans++;
            }
            if (coins[i] == 1) {
                ans++;
                continue;
            }
        }
        return ans;
    }
};

大佬的方法

class Solution {
public:
    int minCount(vector<int>& coins) {
        int cnt = 0;
        for(auto& num : coins) {
            cnt += num / 2 + num % 2;
        }
        return cnt;
    }
};

看来我还有很长一段路要走

Leetcode01:两数之和——使用哈希表进行快速查找

Sun, 04 Feb 2024 05:14:40 GMT

前言

众所周知，当我们在进行数组查找时，通常会碰到较多的数据，使用普通的遍历可能会使时间复杂度达到0(n²)，处理起来十分麻烦，因此我们在这里引入时间复杂度为o(1)的哈希表。

解释

“哈希”，就是指高维到低维的映射，通常来说就是数据大的空间对数据小的空间的映射,在C++中，我们使用unordered_map<>来引用。

应用

先来看看题目：

给定一个整数数组 nums 和一个整数目标值 target，请你在该数组中找出 和为目标值 target 的那两个整数，并返回它们的数组下标。

你可以假设每种输入只会对应一个答案。但是，数组中同一个元素在答案里不能重复出现。

你可以按任意顺序返回答案。

示例 1：

输入：nums = [2,7,11,15], target = 9
输出：[0,1]
解释：因为 nums[0] + nums[1] == 9 ，返回 [0, 1] 。

示例 2：

输入：nums = [3,2,4], target = 6
输出：[1,2]

示例 3：

输入：nums = [3,3], target = 6
输出：[0,1]

提示：

2 <= nums.length <= 10⁴
-10⁹ <= nums[i] <= 10⁹
-10⁹ <= target <= 10⁹
只会存在一个有效答案

进阶：你可以想出一个时间复杂度小于 O(n²) 的算法吗？

对于这题，我们很容易想到利用两个for循环来进行查找，但这样的时间复杂度太高

For循环(时间复杂度o(n²))

class Solution {
public:
    vector<int> twoSum(vector<int>& nums, int target) {
        int n = nums.size();
        for (int i = 0; i < n; ++i) {
            for (int j = i + 1; j < n; ++j) {
                if (nums[i] + nums[j] == target) {
                    return {i, j};
                }
            }
        }
        return {};
    }
};

提交结果：

仅仅在前40%

但当我们使用哈希表时：

哈希表(时间复杂度o(1))

class Solution {
public:
    vector<int> twoSum(vector<int>& nums, int target) {
        unordered_map<int,int> h;
        vector <int> ret(2);
        for(int i=0,I=nums.size();i<I;++i){
            if(h.find(target-nums[i])!=h.end()){
                ret[0]=h[target-nums[i]];
                ret[1]=i;
                break;
            }
            h[nums[i]]=i;
        }
        return ret;
    }
};

提交结果：

可以看到运行速度在前1%

由此可以看出哈希表的强大之处。

数据结构：使用C++实现二叉树的遍历和线索化

Sun, 28 Jan 2024 00:20:59 GMT

#include <iostream>
#include <time.h>
using namespace std;

typedef struct Node{
	int key;
	int ltag,rtag;//1:thread 0:edge
	Node *lchild, *rchild;
}Node;

Node *GetNewNode(int key)
{
	Node *p=new Node;
	p->key=key;
	p->ltag=p->rtag=0;
	p->lchild=p->rchild=NULL;
	return p;
}

Node *insert(Node *root,int key)
{
	if(root==NULL)	return GetNewNode(key);
	if(rand()%2)	root->lchild=insert(root->lchild,key);
	else			root->rchild=insert(root->rchild,key);
	return root;
}

void clear(Node *root)
{
	if(root==NULL)	return;
	if(root->ltag==0)	clear(root->lchild);
	if(root->rtag==0)	clear(root->rchild);
	delete root;
	return;
}

void PRE_order(Node *root)
{
	if(root==NULL)	return;
	cout<<root->key<<' ';
	if(root->ltag==0)	PRE_order(root->lchild);
	if(root->rtag==0)	PRE_order(root->rchild);
	return;
}

void IN_order(Node *root)
{
	if(root==NULL)	return;
	if(root->ltag==0)	IN_order(root->lchild);
	cout<<root->key<<' ';
	if(root->rtag==0)	IN_order(root->rchild);
}

void POST_order(Node *root)
{
	if(root==NULL)	return;
	if(root->ltag==0)	PRE_order(root->lchild);
	if(root->rtag==0)	PRE_order(root->rchild);
	cout<<root->key<<' ';
}

Node *pre_node=NULL,*inorder_root = NULL;
void __build_inorder_thread(Node *root) {
    if (root == NULL) return ;
    if (root->ltag == 0) __build_inorder_thread(root->lchild);
    if (inorder_root == NULL) inorder_root = root;
    if (root->lchild == NULL) {
        root->lchild = pre_node;
        root->ltag = 1;
    }
    if (pre_node && pre_node->rchild == NULL) {
        pre_node->rchild = root;
        pre_node->rtag = 1;
    }
    pre_node = root;
    if (root->rtag == 0) __build_inorder_thread(root->rchild);
    return ;
}

void build_inorder_thread(Node *root)
{
	__build_inorder_thread(root);
	pre_node->rchild=NULL;
	pre_node->rtag=1;
	return;
}

Node *GetNextNode(Node *root)
{
	if(root->rtag==1)	return root->rchild;
	root=root->rchild;
	while(root->ltag==0&&root->lchild)	root=root->lchild;
	return root;
}

int main()
{
	srand(time(0));
	Node *root=NULL;
	#define MAX_NODE 10
	for(int i=0;i<MAX_NODE;++i)
	{
		root=insert(root,rand()%100);
	}
	pre_node = inorder_root = NULL;
	build_inorder_thread(root);
	
	PRE_order(root);cout<<endl;
	IN_order(root);cout<<endl;
	POST_order(root);cout<<endl;
	//Like Linklist
	Node *node=inorder_root;
	while(node){
		cout<<node->key<<' ';
		node=GetNextNode(node);
	}
	cout<<endl;
	clear(root);
	return 0;
}

数据结构：使用C++实现二叉树的深度优先搜索和广度优先搜索

Thu, 25 Jan 2024 13:27:46 GMT

二叉树的搜索主要依靠队列进行搜索，用头尾进行：先进先出，后进后出的原则

实现代码如下：

#include<iostream>
#include<time.h>
using namespace std;

typedef struct Node{
	int key;
	struct Node *lchild, *rchild;
}Node;

Node *getnewNode(int key){
	Node *p = new Node;
	p->key=key;
	p->lchild=p->rchild=NULL;
	return p;
}

Node *insert(Node *root,int key){
	if(root==NULL)	return getnewNode(key);
	if(rand()%2)	root->lchild=insert(root->lchild,key);
	else			root->rchild=insert(root->rchild,key);
	return root;
}

void clear(Node *root)
{
	if(root==NULL)	return;
	clear(root->lchild);
	clear(root->rchild);
	free(root);
	return;
}

#define MAX_NODE 10
Node *queue[MAX_NODE+5];
int head,tail;

void bfs(Node *root){
	head=tail=0;
	queue[tail++]=root;
	while(head<tail){
			Node *node=queue[head];
			cout<<endl<<"node: "<<node->key<<endl;
	if(node->lchild){
			queue[tail++]=node->lchild;
			cout<<' '<<node->key<<"->"<<node->lchild->key<<"(left)"<<endl;
		}
	if(node->rchild){
			queue[tail++]=node->rchild;
			cout<<' '<<node->key<<"->"<<node->rchild->key<<"(right)"<<endl;
		}
		head++;	
	}
	cout<<endl;
	return;
}

int tot=0;
void dfs(Node *root)
{
	if(root==NULL) return;
	int start,end;
	tot+=1;
	start=tot;
	if(root->lchild)	dfs(root->lchild);
	if(root->rchild)	dfs(root->rchild);
	tot+=1;
	end=tot;
	cout<<root->key<<" : "<<"["<<start<<','<<end<<"]"<<endl;
	return;
}


int main()
{
	srand(time(0));
	Node *root=NULL;
	for(int i=0;i<MAX_NODE;i++)
	{
		root=insert(root,rand()%100);
	}
	bfs(root);
	dfs(root);
	return 0;
}

什么是程序员

Fri, 19 Jan 2024 12:28:12 GMT

虽然不知道为什么这只鸟用头飞了起来，但是总归是实现了功能。等等，既然反正是用头飞的，那去掉翅膀应该没事。凭什么去掉翅膀就不能飞了嘛？你TM不是用头飞的嘛？凭什么原封不动把翅膀加回去又不能飞了？我啥也没干啊？艹！为什么这只鸟会用脚飞行？这是什么原理？我把脚去掉试试！绝了！这鸟能飞了！！还是用翅膀正常飞行！虽然它没有脚不能着陆。等等，我上次好像做了一只鹰来着？把那个脚复制过来看看！

完美！这只鸽子现在拥有了完善的飞行功能，并且可以正常着陆。虽然脚是用鹰的脚凑合的，但是没问题！能用！我宣布！这个项目完成了！

Encrypted Post

Mon, 15 Jan 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: /src/assets/images/cover.avif
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.
`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.
`alias`	alias for the post. The post will be accessible at `/posts/{alias}/`. Example: `my-special-article` (will be available at `/posts/my-special-article/`)
`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.
`encrypted`	Whether this post is password protected.
`password`	The password to unlock the encrypted post.
`passwordHint`	A hint to help users remember the password. Displayed below the password input.

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.png
5
    └── index.md

Posts alias#

You can set a alias for any post by adding the alias field to the front-matter:

1
---
2
title: My Special Article
3
published: 2024-01-15
4
alias: "my-special-article"
5
tags: ["Example"]
6
category: "Technology"
7
---

When a alias is set:

The post will be accessible at the custom URL (e.g., /posts/my-special-article/)
The default /posts/{slug}/ URL will still work
RSS/Atom feeds will use the custom alias
All internal links will automatically use the custom alias

Important Notes:

Alias should NOT include /posts/ prefix (it will be added automatically)
Avoid special characters and spaces in alias
Use lowercase letters and hyphens for best SEO practices
Make sure alias are unique across all posts
Don’t include leading or trailing slashes

How It Works#

graph LR A[User Password] --> B[Direct AES Decryption] B --> C{Check Prefix?} C -- "MIZUKI-VERIFY:" found --> D[Success: Render Content] C -- Random/Garbage --> E[Fail: Wrong Password]

Page Encryption#

You can password protect any post by setting encrypted: true and providing a password in the front-matter:

1
---
2
title: My Private Post
3
published: 2024-01-15
4
encrypted: true
5
password: "my-secret-password"
6
passwordHint: "Hint: The password is my dog's name"
7
---

Fields#

Field	Required	Description
`encrypted`	Yes	Set to `true` to enable password protection
`password`	Yes	The password to unlock the post
`passwordHint`	No	A hint displayed below the password input to help users

How the Unlock Box Looks#

The unlock box displays:

A lock icon in the theme’s primary color
The post title “Password Protected”
A description asking for the password
A hint (if passwordHint is provided)
A password input field and unlock button

After entering the correct password, the content is decrypted and displayed. The password is stored in session storage so users don’t need to re-enter it on subsequent page loads within the same session.

闲暇之余写篇文章

Wed, 29 Nov 2023 05:06:14 GMT

额，不知是什么原因，突然就想写篇文章。

想了一下，就从对未来的规划写起吧。学习，生活，以及这个网站。

明年四月份，我要去蓝桥杯试试水，周围很多人都劝我别报，ACM大佬，竞赛的都来这条赛道上了。作为一名零基础，零竞赛的小白想要从中脱颖而出，这个寒假就要开始踏踏实实地学了。

目标C++ A组省三。含金量不高，但对我来说只是想要有一个好的起点。

不得也没事，就像SHOWMAKER所说的：失败总是贯穿人生始终~

对于学习，我总感觉自己提不起劲来，上课总在玩手机，一直走神，还有一个月就要期考了，收收心吧，去图书馆奋斗ing。。。

这个网站，一开始建其实只是偶然，想要跟跟风，但经历了这一个多月，不断从失败中走出，内心也有了要把这个网站维护好的决心。毕竟这是我的心血啊

但我还是没想好这个网站要做什么，是我的一个心灵树洞？是分享资源给大众的一个网站？亦或是改造成做题刷题交流的网站？有太多路可以选择了。

所以我目前想把它搞成一个综合性网站，什么都有的那种，听上去确实很不现实，走一步看一步吧

迟来的祝李哥四冠

Wed, 22 Nov 2023 04:50:48 GMT

2023年11月19日，这是一个值得所有LOLer记住的日子

就在这一天，FAKER达成了他的四冠成就，前无古人，后无来者。

正如赛前宣传片所说的，S6的他，只是为了自己的高度而取得冠军，7年下山之路，让他重新认识了自己。S13的FAKER，要为队友夺下属于他们的冠军。

LPL1 1：11 是给你这几年戒骄戒躁，砥砺前行的奖励

你的终点还未结束

你是大魔王，大飞，飞老狗，更是山顶上的无上之神

在老一辈LOLer眼中，你更是听到FAKER这个名字就让人闻风丧胆的存在

十年抗韩，抗的是SKT,是T1，更是李相赫

作为一名老玩家，我不是任何战队的粉丝

在今天，我只想为你庆祝

希望你把这游戏带向新高度，让世人看看

这永不言弃的精神！

总算正常了

Fri, 17 Nov 2023 19:22:01 GMT

这几天建站下来我是身心俱疲啊...

自己一个电脑小白，妄想和大佬一样速成，还是太难为自己了...

这几天遇到的麻烦太多，不由得感慨：

1、网站三次无法连接数据库。删删减减发现还是没卵用，最后只能再买一个实例了== 好在阿里云最近又在搞活动，99元送了我一个一年的服务器（最重要的是配置比我200+买的还要好，于是怒而退款）

2、B站上的教程真的是非常非常有用，对我这种干什么都要出问题的新手来说简直不要太友好，附上链接送给同样想要自建网站的朋友们~ https://www.bilibili.com/video/BV1Vg411w7os?p=1&vd_source=3f5a8785a0825ec45e3bd34e3437f81e

3、大学生活真的很忙碌，对于我们这种一周要上十八大节课的计算机人来说更是生不如死O.o 但我还是会找时间更新的，谁让我就是热爱这狗屎专业呢（笑）

大学生活3.0——堂堂连载！

使用正则表达式和文件操作爬取并保存“某吧”某帖子全部内容（该帖不少于5页)

Fri, 17 Nov 2023 19:09:03 GMT

本次选取的是某吧中的抗压背锅吧中的一篇帖子,帖子标题是“faker 你要毁了lpl么？”。爬取的目标是帖子里面的回复内容。

PYTHON代码如下：

import csv
import requests
import re
import time


def main(page):
    url = f'https://tieba.baidu.com/p/8713988388?pn={page}'
    headers = {
        'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36'
    }
    resp = requests.get(url, headers=headers)
    html = resp.text
    # 评论内容
    comments = re.findall('style="display:;">                    (.*?)</div>', html)
    # 评论用户
    users = re.findall('class="p_author_name j_user_card" href=".*?" target="_blank">(.*?)</a>', html)
    # 评论时间
    comment_times = re.findall('楼</span><span class="tail-info">(.*?)</span><div', html)
    for u, c, t in zip(users, comments, comment_times):
        # 筛选数据,过滤掉异常数据
        if 'img' in c or 'div' in c or len(u) > 50:
            continue
        csvwriter.writerow((u, t, c))
        print(u, t, c)
    print(f'第{page}页爬取完毕')


if __name__ == '__main__':
    with open('01.csv', 'a', encoding='utf-8') as f:
        csvwriter = csv.writer(f)
        csvwriter.writerow(('评论用户', '评论时间', '评论内容'))
        for page in range(1, 8):  # 爬取前7页的内容
            main(page)
            time.sleep(2)

爬取效果如下：

D:\study\venv\Scripts\python.exe D:\study\main.py 
船只线饲mu 2023-11-12 19:56 ？疯掉啦
24小时都在想女人 2023-11-12 19:56 现在是幻想时间
第1页爬取完毕
KaspaStar 2023-11-12 19:58 ？
贴吧用户_5G3KU9P 2023-11-12 19:58 369团战比不过对线也打不过选的英雄还不会玩抽象
让我试试 2023-11-12 19:58 别指望我们四号种子，我们就是个混的，一号种子跟真实力二号种子都没打过。wbg走到现在已经血赚
灰先生😎 2023-11-12 20:01 t1挂机一个微博都赢不了
绝望的患者 2023-11-12 20:01 现在是幻想时间
何必强颜欢笑o0 2023-11-12 20:02 梦里啥都有
风不解风情 2023-11-12 20:03 灯神，带大伙登神吧
世事终无常 2023-11-12 20:03 好好好
第2页爬取完毕
贴吧用户_Q4WUSAE 2023-11-12 20:04 闹麻了。
s7的捆仙绳还给你 2023-11-12 20:04 现在是幻想时间
单车少年钱伯斯 2023-11-12 20:04 卡萨呢，不给卡萨混个皮肤？
幼儿园吃糖高手 2023-11-12 20:08 炸饺消音消画打胎嫖娼赌博假赛老赖铜牌赛区，跪下！
键盘战神 2023-11-12 20:10 太讽刺了，顶级晒黑的我要开始支持wbg了😭，晒哥五年前你给LPL带来了光明，这次，再拯救一次LPL吧😭
第3页爬取完毕
😶😑😐 2023-11-12 20:10 不是T1 3-0 WBG？
流汗且黄豆69 2023-11-12 20:12 怎么，你也有原神哥当辅助？
大吼并扑向 2023-11-12 20:12 意淫赛区配意淫粉丝，合理
贴贴哎 2023-11-12 20:12 恭喜wbg，第二个drx！！！
favoritejkgirl 2023-11-12 20:12 做梦是吧
贴贴哎 2023-11-12 20:12 第二个龙叉？！
Marisa038 2023-11-12 20:13 嚯嚯嚯，杂交队又开始YY了
Luccen- 2023-11-12 20:14 现在是，______
第4页爬取完毕
憨态老司机 2023-11-12 20:17 不被3:0就算成功
error 0 2023-11-12 20:18 经典提前开香槟
他想吃酱油炒饭 2023-11-12 20:19 牛
犬子星期天 2023-11-12 20:22 滚旦
深爱着我自己 2023-11-12 20:24 好好好，今天开始我也是js了，啃t1🧠，啃t1水晶，啃t1野区，我啃啃啃啃啃啃啃啃啃啃。
贴吧用户_Q6VP193 2023-11-12 20:24 6666
第5页爬取完毕
浮世英壽 2023-11-12 20:30 幽默
Minatozakii 2023-11-12 20:31 我突然释怀的笑
橘子sss 2023-11-12 20:36 啊？这是。。。
dailylife09 2023-11-12 20:37 寄咯
可爱的无双君王 2023-11-12 20:37 哈哈哈，好好好，顶级，乐死我了
第6页爬取完毕
只喝百事的可乐 2023-11-12 20:41 哥们喝大了，还是GSL串疯了？
还有高手. 2023-11-12 20:41 幽默
我才不爱saber 2023-11-12 20:41 现在是做梦环境
白天都不 2023-11-12 20:43 现在是幻想时间
Tl-Faker 2023-11-12 20:45 癔症了
第7页爬取完毕

Process finished with exit code 0

第一次进行这种大操作，感觉是真的烧脑。。。

但当自己真正完成的那一瞬间，内心便会得到极大满足~

最后私心提前庆祝FAKER四冠~

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)

使用组件#

这是一个图标组件：

import { Icon } from 'astro-icon/components'

<div class="flex items-center gap-2 my-4">
  <Icon name="fa7-solid:rocket" class="text-4xl text-red-500" />
  <span>火箭发射！</span>
</div>

火箭发射！

使用 JSX#

你也可以直接写 HTML/JSX：

<div className="p-4 bg-blue-100 dark:bg-blue-900 rounded-lg my-4">
  这是一个自定义样式的 div 块，使用了 Tailwind CSS 类。
</div>

这是一个自定义样式的 div 块，使用了 Tailwind CSS 类。

简单的变量导出#

export const year = new Date().getFullYear()

今年是 {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 进行完美中心裁剪补充视野。图片边框水平彻底对齐无缝隙，但被裁剪后，只有点击图片通过灯箱才能查看完整图片，所以建议尽量避免使用长宽比例不一致的图片在同一排中。

图注恒定底端对齐： 不论上面的图片长宽如何变化，在同一行的所有图像解释文字（图注）都会对标到一条完美的水平基线上了。

[grid]

示例图片一

示例图片二

[/grid]

基本语法

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 地址，页面端再根据亮暗主题自动切换图源，并支持缩放、拖拽和全屏交互。

如果你想快速上手，可以记住这个最小模板：

1
@startuml
2
Alice -> Bob: Hello
3
Bob --> Alice: Hi
4
@enduml

活动图示例#

1
@startuml
2
start
3
:用户提交订单;
4
if (库存充足?) then (是)
5
  :冻结库存;
6
  :创建支付单;
7
  if (支付成功?) then (是)
8
    :生成发货单;
9
    :通知仓库拣货;
10
  else (否)
11
    :取消订单;
12
    :释放库存;
13
  endif
14
else (否)
15
  :提示缺货;
16
endif
17
stop
18
@enduml

显示更多显示更少

状态图示例#

1
@startuml
2
[*] --> 草稿
3

4
草稿 --> 待审核 : 提交
5
待审核 --> 草稿 : 驳回
6
待审核 --> 已发布 : 审核通过
7
已发布 --> 已归档 : 到期归档
8
已发布 --> 草稿 : 撤回修改
9

10
state 已发布 {
11
  [*] --> 可见
12
  可见 --> 隐藏 : 手动隐藏
13
  隐藏 --> 可见 : 恢复展示
14
}
15

16
已归档 --> [*]
17
@enduml

显示更多显示更少

用例图示例#

1
@startuml
2
left to right direction
3
actor 游客
4
actor 用户
5
actor 管理员
6

7
rectangle 博客系统 {
8
  usecase "浏览文章" as UC1
9
  usecase "搜索内容" as UC2
10
  usecase "发表评论" as UC3
11
  usecase "点赞收藏" as UC4
12
  usecase "审核评论" as UC5
13
  usecase "发布文章" as UC6
14
}
15

16
游客 --> UC1
17
游客 --> UC2
18
用户 --> UC1
19
用户 --> UC2
20
用户 --> UC3
21
用户 --> UC4
22
管理员 --> UC5
23
管理员 --> UC6
24
@enduml

显示更多显示更少

组件图示例#

1
@startuml
2
package "Firefly Site" {
3
  [Astro App] as App
4
  [Markdown Parser] as Parser
5
  [PlantUML Encoder] as Encoder
6
  [Theme Switcher] as Theme
7
  [Search Indexer] as Search
8
}
9

10
cloud "PlantUML Server" as PU
11
database "Content Store" as Content
12

13
App --> Parser : parse markdown
14
Parser --> Encoder : encode plantuml blocks
15
Encoder --> PU : request svg
16
App --> Theme : switch dark/light src
17
App --> Search : build page index
18
Parser --> Content : read posts
19
@enduml

显示更多显示更少

部署图示例#

1
@startuml
2
node "User Device" {
3
  artifact "Browser"
4
}
5

6
node "CDN / Edge" {
7
  artifact "Static Assets"
8
}
9

10
node "Cloudflare Worker" {
11
  artifact "SSR Handler"
12
}
13

14
node "PlantUML Service" {
15
  artifact "SVG Renderer"
16
}
17

18
database "Object Storage" {
19
  artifact "Markdown Content"
20
}
21

22
"Browser" --> "Static Assets" : GET js/css/img
23
"Browser" --> "SSR Handler" : request page
24
"SSR Handler" --> "Markdown Content" : read post
25
"Browser" --> "SVG Renderer" : fetch diagram svg
26
@enduml

显示更多显示更少

ER 图示例#

1
@startuml
2
entity User {
3
  *id : uuid <<PK>>
4
  --
5
  username : varchar
6
  email : varchar
7
  created_at : datetime
8
}
9

10
entity Post {
11
  *id : uuid <<PK>>
12
  --
13
  author_id : uuid <<FK>>
14
  title : varchar
15
  content : text
16
  published_at : datetime
17
}
18

19
entity Comment {
20
  *id : uuid <<PK>>
21
  --
22
  post_id : uuid <<FK>>
23
  user_id : uuid <<FK>>
24
  body : text
25
  created_at : datetime
26
}
27

28
User ||--o{ Post : writes
29
User ||--o{ Comment : creates
30
Post ||--o{ Comment : has
31
@enduml

显示更多显示更少

时序图示例（登录与刷新令牌）#

1
@startuml
2
autonumber
3
actor User as 用户
4
participant Web as 前端页面
5
participant API as 网关接口
6
participant Auth as 认证服务
7
database Redis as 会话缓存
8

9
用户 -> 前端页面 : 输入账号密码并提交
10
前端页面 -> 网关接口 : POST /login
11
网关接口 -> 认证服务 : 校验凭据
12
认证服务 -> 会话缓存 : 写入 refresh_token
13
认证服务 --> 网关接口 : access_token + refresh_token
14
网关接口 --> 前端页面 : 200 登录成功
15

16
... access_token 过期 ...
17

18
前端页面 -> 网关接口 : POST /refresh
19
网关接口 -> 认证服务 : 校验 refresh_token
20
认证服务 -> 会话缓存 : 轮换 refresh_token
21
认证服务 --> 网关接口 : 新 access_token
22
网关接口 --> 前端页面 : 200 新令牌
23
@enduml

显示更多显示更少

C4 风格容器图示例#

1
@startuml
2
!includeurl https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml
3

4
Person(user, "博客访客", "阅读文章与搜索内容")
5

6
System_Boundary(system, "Firefly Blog") {
7
  Container(web, "Web App", "Astro + Svelte", "渲染页面与交互")
8
  Container(worker, "SSR Worker", "Cloudflare Workers", "处理服务端渲染请求")
9
  ContainerDb(content, "Content Store", "Markdown / Object Storage", "存储文章与资源元数据")
10
  Container(search, "Search Index", "Pagefind", "提供全文检索")
11
}
12

13
System_Ext(plantuml, "PlantUML Server", "生成 SVG 图表")
14

15
Rel(user, web, "访问", "HTTPS")
16
Rel(web, worker, "请求 SSR 页面", "HTTPS")
17
Rel(worker, content, "读取文章")
18
Rel(web, search, "查询关键词")
19
Rel(web, plantuml, "请求图表 SVG")
20

21
LAYOUT_LEFT_RIGHT()
22
@enduml

显示更多显示更少

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**

***

MrBin的博客

测试

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

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

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

1. 图床是什么#

2. 为什么选本方案#

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

可以做ip优选#

二、部署前期准备#

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

第二步：准备 Cloudflare 资源#

2.1 获取 Account ID + API Token#

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

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

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

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

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

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

方式 1：手动触发部署#

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

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

五、后续更新维护#

1. 自动更新（推荐）#

2. 手动更新#

六、常见问题#

七、总结#

上天会一直出同一道题给你，直到你做出改变

Cloudflare IP优选

一、Cloudflare IP优选#

步骤1：添加路由规则#

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

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

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

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

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

Firefly 博客搭建教程

Firefly 博客部署教程#

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

一、前言#

二、必备软件清单#

三、分步安装教程#

1. 安装 Node.js#

2. 安装 pnpm#

3. 安装 Git#

4. 安装 VS Code（可选）#

四、常见环境问题排查#

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

一、前言#

二、前置准备#

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

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

一、前言#

二、前置准备#

三、分步操作教程#

四、克隆你自己的仓库到本地#

2. 安装本地依赖（仅用于本地预览）#

3. 启动本地预览服务#

4. 本地简单调试#

5. 本地开发完成后#

第四篇：部署配置｜Cloudflare 关联GitHub自动构建#

一、前言#

二、前置准备#

三、分步配置教程#

1. 新建 Cloudflare Worker 应用#

2. 验证自动部署是否成功#

第五篇：绑定域名（Spaceship 平台域名适配）#

一、绑定前准备（必做）#

二、Step 1：在 Cloudflare 中添加自定义域名#

三、Step 2：在 Spaceship 平台配置 DNS 解析（核心步骤）#

四、Step 4：验证域名绑定是否成功#

Git 使用教程 测试

Git 详细使用教程（命令行版，附命令作用解释）#

一、Git 前期准备（必做）#

1. 安装 Git#

2. 初始配置（绑定身份，关键步骤）#

二、Git 核心概念（先理解，再操作）#

三、本地仓库操作（最基础，必练）#

1. 初始化本地仓库（创建新项目）#

2. 查看工作区状态（高频命令）#

Git 使用教程测试

3. `actions/github-script` 负责把 GitHub 上下文交给本地脚本#

1. `.github/ISSUE_TEMPLATE/friend-request.yml`#

2. `.github/workflows/friend-link-checker.yml`#

3. `.github/scripts/process-friend-request.cjs`#

4. `src/config/friendsConfig.ts`#

5. `.github/workflows/biome.yml`#

第 9 步：通过后如何写入 `friendsConfig.ts`#

为什么不是直接 `JSON.parse`#