export const ownerAvatar = siteConfig.avatar.owner;

MDX 是 Markdown 的超集：在普通 Markdown 里可以直接写 JSX/Astro 组件，让文章从纯文本变成可交互的内容。本站把常用的正文能力封装成 MDX 组件，写文章时用一套简短的指令即可插入提示框、标签页、时间线、链接卡片、图片和视频等内容。

组件按写法分为两类：

• 行级：以 ::name{...} 或 :::name{...} 独占一行，适合提示框、时间线、标签页、链接卡片等块状内容。
• 行内：以 :name[文字]{...} 嵌在句子中，适合徽章、键帽、术语提示、复制、艺术字等文字级标记。

本站目前提供的组件：

行级组件

行内组件

使用前有三条约定：

1. 组件要在 MDX 顶部 import，指令只负责生成对应的组件。
2. 非字符串参数用 $变量，变量在顶层 import 或 export const 定义。
3. {} 会被 MDX 当作表达式，Accordion / Timeline 的行式 DSL 必须放在代码围栏内。

行级组件

手风琴 Accordion

分组卡片手风琴。分组行控制标题和默认展开状态，卡品行定义名称、描述、链接和图标。

参数

语法

:::accordion{label="MDX 组件速查"}
```accordion
{基础组件 · open}
- Badge | 行内小标签 | https://mdxjs.com | material-symbols:label | #00a29b
- Key | 键帽样式 | https://developer.mozilla.org/docs/Web/HTML/Element/kbd | material-symbols:keyboard-arrow-up-rounded | #8b5cf6

{内容容器}
- Folding | 折叠面板 | https://developer.mozilla.org/docs/Web/HTML/Element/details | material-symbols:folder-outline | #2563eb
- CardList | 卡片式列表 | https://developer.mozilla.org/docs/Web/HTML/Element/ul | material-symbols:format-list-bulleted-rounded | #d97706
```
:::

演示

:::accordion{label="MDX 组件速查"}

{基础组件 · open}
- Badge | 行内小标签 | https://mdxjs.com | material-symbols:label | #00a29b
- Key | 键帽样式 | https://developer.mozilla.org/docs/Web/HTML/Element/kbd | material-symbols:keyboard-arrow-up-rounded | #8b5cf6

{内容容器}
- Folding | 折叠面板 | https://developer.mozilla.org/docs/Web/HTML/Element/details | material-symbols:folder-outline | #2563eb
- CardList | 卡片式列表 | https://developer.mozilla.org/docs/Web/HTML/Element/ul | material-symbols:format-list-bulleted-rounded | #d97706

:::

时间线 Timeline

可展开的时间线。每条记录包含时间、标题、可选标签、图标和色调，详情写在记录行下方。

参数

语法

:::timeline{label="MDX 组件时间线"}
```timeline
{2026.05 · 建立组件目录 · 起点 · icon=mdi:source-fork}
把散落在关于页的专属组件收进统一的 MDX 组件库。

{2026.10 · 接入指令糖 · icon=material-symbols:auto-awesome · tone=success}
::: 容器与 :badge[] 行内指令可以直接映射到 Astro 组件。

{2026.10 · 补齐通用组件 · icon=material-symbols:sync-rounded}
新增 Chat、Folding、LinkCard 等正文组件。
```
:::

演示

:::timeline{label="MDX 组件时间线"}

{2026.05 · 建立组件目录 · 起点 · icon=mdi:source-fork}
把散落在关于页的专属组件收进统一的 MDX 组件库。

{2026.10 · 接入指令糖 · icon=material-symbols:auto-awesome · tone=success}
::: 容器与 :badge[] 行内指令可以直接映射到 Astro 组件。

{2026.10 · 补齐通用组件 · icon=material-symbols:sync-rounded}
新增 Chat、Folding、LinkCard 等正文组件。

:::

对话 Chat

对话气泡。角色行区分用户、助手和系统消息，消息文本按纯文本渲染。

参数

语法

::chat
:s 下面是一段组件演示
:u{name="访客"} 这些指令需要提前 import 吗
:a 要的，指令只负责换节点，组件作用域还得自己建。
::

演示

::chat :s 下面是一段组件演示 :u{name="访客"} 这些指令需要提前 import 吗 :a 要的，指令只负责换节点，组件作用域还得自己建。 ::

社交链接 SocialLinks

社交头像组。账号行按固定字段顺序填写，渲染时并入前一段末尾；超过 max 会折叠为 +N。

参数

语法

头像组会自动接在上一段文字末尾，适合放在一句介绍之后：

:::social-links{label="演示社交账号"}
- GitHub | MmzMing | 代码与项目 | https://github.com/MmzMing | fa7-brands:github | github | online
- B站 | Mmz明崽 | 关注一下 | https://space.bilibili.com/15446538 | fa7-brands:bilibili | bilibili | offline
- QQ群 | 加入群聊 | 吹水摸鱼 | https://qm.qq.com/q/2R07cjGTZ0 | fa7-brands:qq | qq | none
:::

演示

头像组会自动接在上一段文字末尾，适合放在一句介绍之后：

:::social-links{label="演示社交账号"}

• GitHub | MmzMing | 代码与项目 | https://github.com/MmzMing | fa7-brands:github | github | online
• B站 | Mmz明崽 | 关注一下 | https://space.bilibili.com/15446538 | fa7-brands:bilibili | bilibili | offline
• QQ群 | 加入群聊 | 吹水摸鱼 | https://qm.qq.com/q/2R07cjGTZ0 | fa7-brands:qq | qq | none :::

折叠面板 Folding

纸面折叠面板，正文支持普通 Markdown；沿用 Accordion 的毛边纸面，但内边距、字号和展开动效更轻量。

参数

语法

:::folding{title="展开查看参数说明"}
- `title`：折叠标题，默认“展开查看”。
- 正文支持列表、代码块、链接等 Markdown 语法。
:::

演示

:::folding{title="展开查看参数说明"}

• title：折叠标题，默认“展开查看”。
• 正文支持列表、代码块、链接等 Markdown 语法。 :::

卡片列表 CardList

把一组 Markdown 列表项渲染成卡片，桌面默认三列，窄屏自动降为两列或一列。

参数

语法

:::card-list
- **行级指令**：`::` 或 `:::` 开头的指令独占一行，渲染为块级组件。
- **行内指令**：`:name[文字]` 嵌在段落中，适合标签、键帽、术语解释。
- **数据驱动**：Accordion、Timeline 只接收结构化数据，内容仍留在 MDX。
:::

演示

:::card-list

• 行级指令：:: 或 ::: 开头的指令独占一行，渲染为块级组件。
• 行内指令：:name[文字] 嵌在段落中，适合标签、键帽、术语解释。
• 数据驱动：Accordion、Timeline 只接收结构化数据，内容仍留在 MDX。 :::

链接卡片 LinkCard

站外链接卡片。外观与友链卡片一致：1px 边框、卡片底色、双层投影，悬停时放大到 1.03 并加深背景、边框和阴影。单张最大宽度 24rem 并水平居中；连续写多个会自动合并为水平居中的网格，网格宽度 ≥ 44rem 时 3 列，≥ 29rem 时 2 列，其余 1 列；末行未占满时整体居中。

设置 banner 后，封面固定高度 9.5rem，图片居中裁切，下方保留图标、标题和描述；无图卡片保持紧凑横向布局。连续卡片之间插入段落、标题等块级内容会打断自动合并。

参数

语法

::link-card{link="https://astro.build/" title="Astro 官方站点" desc="内容驱动的静态站点框架" icon="simple-icons:astro" banner="/assets/images/example.webp"}

::link-card{link="https://mdxjs.com/" title="MDX 官方文档" desc="在 Markdown 中直接写 JSX" icon="simple-icons:mdx" banner="/assets/images/example.webp"}

::link-card{link="https://github.com/MmzMing/my-blog" title="博客源码" desc="本站的完整实现" icon="fa7-brands:github" banner="/assets/images/example.webp"}

::link-card{link="https://developer.mozilla.org/" title="MDN Web Docs" desc="Web 开发文档" icon="simple-icons:mdnwebdocs"}

演示

::link-card{link="https://astro.build/" title="Astro 官方站点" desc="内容驱动的静态站点框架" icon="simple-icons:astro" banner="/assets/images/example.webp"}

::link-card{link="https://mdxjs.com/" title="MDX 官方文档" desc="在 Markdown 中直接写 JSX" icon="simple-icons:mdx" banner="/assets/images/example.webp"}

::link-card{link="https://github.com/MmzMing/my-blog" title="博客源码" desc="本站的完整实现" icon="fa7-brands:github" banner="/assets/images/example.webp"}

::link-card{link="https://developer.mozilla.org/" title="MDN Web Docs" desc="Web 开发文档" icon="simple-icons:mdnwebdocs"}

链接横幅 LinkBanner

横向大图链接横幅，适合展示站点入口或专题；外观与友链卡片一致。

参数

语法

::link-banner{link="https://astro.build/" title="Astro 官方站点" desc="内容驱动的静态站点框架" banner="/assets/images/example.webp" icon="simple-icons:astro"}

演示

::link-banner{link="https://astro.build/" title="Astro 官方站点" desc="内容驱动的静态站点框架" banner="/assets/images/example.webp" icon="simple-icons:astro"}

提示框 Alert

带类型配色的提示块，支持普通、卡片和轻量三种外观。

参数

语法

:::alert{type="tip" title="小提示"}
这里是提示框正文，支持 **加粗** 与 [链接](/about)。
:::

:::alert{type="warning" title="自定义配色" color="#7c3aed" card}
卡片风格使用顶部光晕和阴影，适合放在重点段落前。
:::

演示

:::alert{type="tip" title="小提示"} 这里是提示框正文，支持 加粗 与 链接。 :::

:::alert{type="warning" title="自定义配色" color="#7c3aed" card} 卡片风格使用顶部光晕和阴影，适合放在重点段落前。 :::

标签页 Tabs

多标签内容容器。提供 pill、underline 两种样式：pill 为胶囊分段，underline 为底部下划线。标签由子 Tab 提供；外层用 4 个冒号包裹内层 :::tab。设置 centered 可让标签栏水平居中，切换标签时指示器会平滑滑动到目标标签，面板按方向淡入淡出，容器高度平滑过渡。

参数

语法

**Pill**

::::tabs{label="Pill 示例" variant="pill"}
:::tab{label="概览"}
高层摘要。
:::
:::tab{label="动态"}
最近的用户活动与日志。
:::
:::tab{label="设置"}
管理账户偏好。
:::
::::

**Underline**

::::tabs{label="Underline 示例"}
:::tab{label="全部"}
显示全部工单。
:::
:::tab{label="进行中"}
显示需要处理的工单。
:::
:::tab{label="已关闭"}
已归档和已解决的请求。
:::
::::

**Pill + centered**

::::tabs{label="居中示例" variant="pill" centered}
:::tab{label="概览"}
标签栏在容器内水平居中。
:::
:::tab{label="设置"}
切换标签后内容同步更新。
:::
::::

演示

Pill

::::tabs{label="Pill 示例" variant="pill"} :::tab{label="概览"} 高层摘要。 ::: :::tab{label="动态"} 最近的用户活动与日志。 ::: :::tab{label="设置"} 管理账户偏好。 ::: ::::

Underline

::::tabs{label="Underline 示例"} :::tab{label="全部"} 显示全部工单。 ::: :::tab{label="进行中"} 显示需要处理的工单。 ::: :::tab{label="已关闭"} 已归档和已解决的请求。 ::: ::::

Pill + centered

::::tabs{label="居中示例" variant="pill" centered} :::tab{label="概览"} 标签栏在容器内水平居中。 ::: :::tab{label="设置"} 切换标签后内容同步更新。 ::: ::::

金句 Quote

带装饰图标的引用块，正文支持 Markdown。

参数

语法

:::quote
知识要能被重新发现，而不是只靠标题记忆。
:::

演示

:::quote 知识要能被重新发现，而不是只靠标题记忆。 :::

标题装饰 Title

在正文中插入带装饰线的标题块。

参数

语法

:::title
这里是装饰标题
:::

演示

:::title 这里是装饰标题 :::

图片画廊 Pic

单图或宫格图片。单图默认限制在 36rem × 24rem 内完整显示，设置 full 可取消上限；宫格提供 duo 双列、feature 首图放大两种布局，图片按格子裁切填充。

参数

语法

::pic{src="/assets/images/example.webp" caption="示例图片"}

演示

::pic{src="/assets/images/example.webp" caption="示例图片"}

宫格布局

feature 首图占左侧两行，右侧由一张宽图和两张小图填充；duo 是等宽双列。容器内每行一张图片，格式为 - 地址 | 说明 | alt，说明和 alt 可省略；宫格图片不带外框和背景，说明文字居中排在图片下方。

语法

:::pic{layout="feature"}
- /assets/images/example.webp | 示例图片一
- /assets/images/example.webp | 示例图片二
- /assets/images/example.webp | 示例图片三
- /assets/images/example.webp | 示例图片四
:::

:::pic{layout="duo"}
- /assets/images/example.webp | 示例图片一
- /assets/images/example.webp | 示例图片二
- /assets/images/example.webp | 示例图片三
- /assets/images/example.webp | 示例图片四
:::

演示

:::pic{layout="feature"}

• /assets/images/example.webp | 示例图片一
• /assets/images/example.webp | 示例图片二
• /assets/images/example.webp | 示例图片三
• /assets/images/example.webp | 示例图片四 :::

:::pic{layout="duo"}

• /assets/images/example.webp | 示例图片一
• /assets/images/example.webp | 示例图片二
• /assets/images/example.webp | 示例图片三
• /assets/images/example.webp | 示例图片四 :::

视频嵌入 VideoEmbed

嵌入白名单域名下的视频，目前支持 Bilibili 与 YouTube；其他地址回退为原链接。

参数

语法

::video-embed{src="https://www.bilibili.com/video/BV1GJ411x7h7"}

演示

::video-embed{src="https://www.bilibili.com/video/BV1GJ411x7h7"}

表情包背景 EmojiTail

表情堆叠在正文后方，悬停时整体提亮并轻微上浮。

参数

语法

:::emoji-tail{emojis="📄,🦌,🙌"}
这是配了表情包背景装饰的正文，透明底无边框，hover 会让表情轻轻上浮。
:::

演示

:::emoji-tail{emojis="📄,🦌,🙌"} 这是配了表情包背景装饰的正文，透明底无边框，hover 会让表情轻轻上浮。 :::

行内组件

行内组件直接嵌在句子里，适合强调、标注和补充信息。

徽章 Badge

胶囊标签，可选外链。

参数

语法

状态标签 :badge[Astro 7]、:badge[MDX]，带链接的 :badge[组件文档]{link="https://docs.astro.build/"}。

演示

状态标签 :badge[Astro 7]、:badge[MDX]，带链接的 :badge[组件文档]{link="https://docs.astro.build/"}。

键帽 Key

键帽样式，适合快捷键说明。

参数

语法

在编辑器里按 :key[Ctrl] + :key[K] 打开命令面板。

演示

在编辑器里按 :key[Ctrl] + :key[K] 打开命令面板。

术语提示 Tip

术语下划线加悬停提示。

参数

语法

Astro 的岛屿架构会把交互组件单独 :tip[水合]{tip="浏览器接管静态 HTML 并绑定事件的过程"}，其余部分保持静态。

演示

Astro 的岛屿架构会把交互组件单独 :tip[水合]{tip="浏览器接管静态 HTML 并绑定事件的过程"}，其余部分保持静态。

行内复制 Copy

点击复制正文内容，适合命令和短代码。

参数

语法

构建命令：:copy[npm run build]。

演示

构建命令：:copy[npm run build]。

代码语言标 CodeLang

带语言标签的行内代码。

参数

语法

构建命令：:code[npm run build]{lang="bash"}。

演示

构建命令：:code[npm run build]{lang="bash"}。

人物名片 ProfileCard

人物名片。正文里显示触发词，悬停或聚焦后展开姓名、身份和简介。

参数

语法

有没有想过，这个博客背后其实是一个 :profile-card{id="owner" trigger="全干工程师" name="MmzMing" role="全干工程师" description="白天处理业务代码，空闲时折腾 AI、博客和各种小项目。" avatar="$ownerAvatar"} 在维护？

演示

有没有想过，这个博客背后其实是一个 :profile-card{id="owner" trigger="全干工程师" name="MmzMing" role="全干工程师" description="白天处理业务代码，空闲时折腾 AI、博客和各种小项目。" avatar="$ownerAvatar"} 在维护？

模糊 Blur

模糊文字，悬停或键盘聚焦后显现；支持行内与块级。

参数

语法

遇到报错时，正确的顺序是 :blur[先看文档再改代码]。整段内容也可以隐藏：

:::blur
块级模糊会把整段内容一起遮住，适合答案、剧透或折叠前的提示。
:::

演示

遇到报错时，正确的顺序是 :blur[先看文档再改代码]。整段内容也可以隐藏：

:::blur 块级模糊会把整段内容一起遮住，适合答案、剧透或折叠前的提示。 :::

艺术字 ArtText

四种行内艺术字变体：cre 流动渐变、story 衬线批注、zoom 滚动放大、repeat 跟手回声（悬停拖影，点击扩散）。

参数

语法

四种效果：[!cre:流动渐变] [!story:故事感] [!zoom:放大] [!repeat:回声]。

演示

四种效果：[!cre:流动渐变] [!story:故事感] [!zoom:放大] [!repeat:回声]。

以上是本站 MDX 组件的完整说明。::github、callout、Mermaid 属于 Markdown 扩展，不在这批组件范围内。

参考来源

本文的组件设计参考了 RAGnote 的组件语法指南：

::link-card{link="https://ragnote.top/article/c636666dc6644140919010e78008e287" title="RAGnote 组件语法完全指南" desc="参考来源：RAGnote 富文本组件说明" icon="https://api.ragnote.top/files/bussiness/site_logo/4543f719e787499f8f3fb47782532368_1544604283489600.webp"}

[!NOTE] 提示 本文记录基于 Firefly 主题进行二次开发的实现取舍，覆盖首页动效、音乐播放器、标签图谱、留言板、Cloudflare 集成和部署流程。项目目标是保留 Astro 内容系统，同时将交互功能拆分为可独立维护的模块。

选型背景

项目最初定位为个人主页，后续增加了文章、评论、搜索和统计能力，因此选择继续在 Astro 内容系统上演进。没有迁移到 Fuwari 的主要原因是现有文章、组件和部署配置已经围绕 Astro 组织，迁移成本高于继续维护。

截至本文发布时，项目本地构建时间约为 24 s；性能结果取决于图片数量、网络环境和部署平台，不能直接作为所有环境的基准。后续重构的主要成本来自交互组件、Swup 生命周期和外部服务配置之间的耦合。

项目地址

https://github.com/MmzMing/my-blog

项目属于二次开发，代码和配置以仓库当前版本为准。

一、重点

1、首页

1. Hero 区域采用 Galgame 风格
2. 站点地图一览
3. 作品展示和博客主要方向

2、音乐播放器

保留全局音乐播放器：桌面悬浮组件与移动端 dock 共用同一播放引擎，支持 Meting API、本地曲目、播放列表与歌词，不包含独立的 3D 音乐页面。

3、分类标签

分类页现在只保留标签关系图谱：标签是节点，同一篇文章中同时出现的标签会连成边，边越粗表示共现次数越多。

实现上，构建阶段会遍历所有文章的 tags：每个标签生成一个节点，并记录它关联的文章；同一篇文章内的任意两个标签生成一条共现边，边的权重就是它们共同出现的次数。客户端按连通关系给节点分组，再交给 D3 力导向模拟进行排布；Canvas 根据模拟结果逐帧绘制图谱。节点大小由文章数量决定，边的透明度和粗细由共现权重决定。用户可以缩放、拖拽节点、悬停查看关联文章，点击或按回车跳转到对应标签页；同时支持键盘选择、减少动态效果偏好和亮暗主题切换。

4、留言

转变UI为聊天室，并复用 Waline 的登录、审核、表情和访问量能力。原本做了个翻卡牌的，因为这个在KV上面天天给我报警告，后面就取消了。

Waline 服务独立部署，博客只保存服务地址和客户端配置；项目 Worker 不保存评论内容，也不维护留言数据库或登录系统。

留言板调用的接口如下。读取接口每 30 s 轮询一次；页面不可见或浏览器离线时停止发起无效请求。

管理员 Token 仅保存到 sessionStorage；普通用户根据"记住登录"选项保存到 sessionStorage 或 localStorage。任何读取、发布、修改或删除请求返回鉴权错误时，页面都会清除本地 Token 并要求重新登录。

4.1 接口列表

以下为 @waline/api 中留言板实际调用的 CRUD 接口。

// GET /api/comment?path=...&pageSize=...&page=...&lang=...&sortBy=...
// Headers: (token 存在时) Authorization: Bearer <token>
// 读取留言列表（分页，首次加载 + 轮询 + 加载历史）
getComment({
  serverURL: string,     // Waline 服务端地址
  lang: string,          // 语言
  path: string,          // 页面路径（留言板固定为 /guestbook/）
  page: number,          // 页码，从 1 开始
  pageSize: number,      // 每页条数
  sortBy: string,        // 排序方式（如 "insertedAt_desc"）
  token?: string,        // 登录令牌（可选，管理员可看到待审核留言）
  signal?: AbortSignal,  // 取消请求信号
})
// Response: { count: number, page: number, pageSize: number, totalPages: number, data: WalineRootComment[] }

// --------------------------------------------------------------------------

// POST /api/comment?lang=<string>
// Headers: Content-Type: application/json
//         (token 存在时) Authorization: Bearer <token>
// Body: { nick, mail?, link?, comment, ua, url, pid?, rid?, at? }
// 发布留言
addComment({
  serverURL: string,
  lang: string,
  token?: string,           // 登录令牌（登录用户可选，匿名时不需要）
  comment: {                // WalineCommentData
    nick: string,           // 昵称
    mail?: string,          // 邮箱
    link?: string,          // 网站地址
    comment: string,        // 留言内容（含回复标记 HTML 注释）
    ua: string,             // User Agent
    url: string,            // 页面路径
    pid?: number,           // 父评论 ID（回复时）
    rid?: number,           // 根评论 ID（回复时）
    at?: string,            // @用户 ID（回复时）
  },
})
// Response: { errno: number, errmsg?: string, data?: WalineComment }

// --------------------------------------------------------------------------

// PUT /api/comment/<objectId>?lang=<string>
// Headers: Content-Type: application/json
//          Authorization: Bearer <token>
// Body: { comment?, status?, sticky?, like? }
// 编辑留言（仅本人或管理员可编辑）
updateComment({
  serverURL: string,
  lang: string,
  token: string,            // 登录令牌（必需）
  objectId: number,         // 留言 objectId
  comment?: {               // UpdateWalineCommentData
    comment?: string,       // 修改后的内容
    status?: "approved" | "waiting" | "spam",  // 审核状态（管理员）
    sticky?: 0 | 1,         // 置顶状态（管理员）
    like?: boolean,         // 点赞/取消点赞
  },
})
// Response: { errno: number, errmsg?: string, data: WalineComment }

// --------------------------------------------------------------------------

// DELETE /api/comment/<objectId>?lang=<string>
// Headers: Authorization: Bearer <token>
// 删除留言（仅本人或管理员可删除）
deleteComment({
  serverURL: string,
  lang: string,
  token: string,            // 登录令牌（必需）
  objectId: number,         // 留言 objectId
})
// Response: { errno: number, errmsg: string, data: "" }

// --------------------------------------------------------------------------

// GET /api/token?lang=<string>
// Headers: Authorization: Bearer <token>
// 登录回调 Token 校验（Waline OAuth 重定向回博客后验证身份）
fetch(`${serverURL}/api/token?lang=${lang}`, {
  headers: { Authorization: `Bearer ${token}` },
})
// Response: { errno: number, errmsg?: string, data?: UserInfo }

4.2 登录流程

sequenceDiagram
    participant User as 用户
    participant Page as 博客页面
    participant Waline as Waline 服务端
    participant Window as 浏览器窗口

    Note over User, Page: 桌面端：弹窗 + postMessage
    User->>Page: 点击"登录"
    Page->>Waline: 打开登录弹窗 (window.open)
    Waline->>Waline: 用户完成 OAuth 认证
    Waline-->>Window: postMessage ({ type: "userInfo", data: UserInfo })
    Page->>Page: 验证 UserInfo 合法性

    alt 验证成功
        Page->>Page: 进入存储策略
    else 验证失败
        Page->>Page: 清除 Token，提示重新登录
    end

    Note over User, Page: 移动端：跳转 + token 回传
    User->>Page: 点击"登录"
    Page->>Waline: location.href 跳转到登录页
    Waline->>Waline: 用户完成 OAuth 认证
    Waline-->>Page: 302 重定向回博客 (?token=...)
    Page->>Waline: GET /api/token (Authorization: Bearer <token>)
    alt 验证成功
        Waline-->>Page: 返回用户信息
        Page->>Page: 进入存储策略
    else 验证失败
        Waline-->>Page: 返回错误
        Page->>Page: 清除 Token，提示重新登录
    end

    Note over Page: 存储策略
    alt 管理员
        Page->>Page: 存入 sessionStorage
    else 普通用户 + 勾选"记住登录"
        Page->>Page: 存入 localStorage
    else 普通用户 + 未勾选"记住登录"
        Page->>Page: 存入 sessionStorage
    end

    Page->>Page: 刷新留言列表

5、关于

关于页内容使用 MDX 编写，正文里直接内嵌 Astro 组件（资料卡、技术栈卡片、时间线、社交链接和聊天气泡），排版交给框架的 Markdown 渲染管线，无需手动处理换行。页面底部附带一张更新日志图谱：构建时解析 log.md 的变更记录，生成按类型着色的日志卡片，并用 SVG 连线标注条目之间的关联页面。

6、日历

日历以全局小组件形式提供，聚合文章发布日期、法定节假日、内置节日和生日/纪念日，在固定的 6 × 7 月视图中展示公历和农历信息，并提供近期事件与当天详情。

6.1 接口列表

以下两个内部 API 在构建时预渲染为静态 JSON；日历小组件在浏览器端运行时 fetch 这两份数据。其中 /api/holidays.json 在构建时会调用第三方节假日 API 获取数据。

// --------------------------------------------------------------------------

// GET /api/allPostMeta.json
// Headers: 无
// 调用方：日历小组件客户端脚本（浏览器运行时 fetch）
// 构建时由 Astro Content Collections 生成并预渲染为静态 JSON，包含所有文章的元数据
fetch("/api/allPostMeta.json")
// Response: Array<{ id: string, title: string, published: number, category?: string, password?: boolean }>

// --------------------------------------------------------------------------

// GET /api/holidays.json
// Headers: 无
// 调用方：日历小组件客户端脚本（浏览器运行时 fetch）
// 构建时内部调用第三方 API 获取节假日数据后合并内置节日，预渲染为静态 JSON
fetch("/api/holidays.json")
// Response: Array<{ date: string, name: string, isOfficial?: boolean, isWorkday?: boolean, icon?: string, source: "api" | "builtin", rest?: number }>

// --------------------------------------------------------------------------

// GET https://timor.tech/api/holiday/year/<year>
// Headers: Accept: application/json
// 调用方：/api/holidays.json 内部（构建时由 holidayApi 配置驱动）
// 获取中国法定节假日、调休补班日
// 配置路径：src/config/calendarConfig.ts → holidayApi.url
fetch("https://timor.tech/api/holiday/year/2026")
// Response: { code: number, holiday: Record<string, { holiday: boolean, name: string, rest?: number }> }

两个内部 API 只在 astro build 时执行并输出为静态 JSON，生产环境由静态资源直接返回，浏览器端 fetch 到的是静态文件。文章或节假日更新后需要重新构建才能反映到日历上。

7、归档

归档页按年、月和文章组织时间线，支持分类和标签筛选，并显示年度文章进度。文章列表与统计在构建时根据文章元数据生成；由于静态构建无法读取查询参数，分类和标签筛选在客户端执行，不依赖额外的动态接口。

8、其他

1. 取消了侧边栏，首页和文章页将主要导航集中到顶部与移动端 Dock。
2. 修改了整体 UI 风格，保留亮色与暗色两种主题，不再维护背景图和多套背景配置。
3. 添加了日历功能，按文章发布日期展示内容；节假日数据在构建时从第三方 API 拉取并合并内置节日，运行时只读静态 JSON。
4. 删除了追番功能，避免相关数据请求和资源处理进入构建流程。
5. 使用 Pagefind 1.5.2 构建本地全文索引，并在构建期生成 LLM Wiki 的 JSON / Markdown 机器入口。
6. 站点完全静态生成，可直接部署到 Cloudflare Pages、Vercel、Netlify 或其他静态托管平台；评论和统计使用各自的外部服务。

二、用到的AI模型

• MIMO V2.5/PRO（送的百亿补贴）
• claude opus 4.64.74.8fable 5
• GPT 5.5/5.6
• antigravity的gemini 3.1/3.5
• TRAE上的 GLM/豆包/KIMI/QWEN/DeepSeek（都是拿来测试性能好在工作上确定是否实用）

本次试用成本约为 30 元。不同平台的模型、上下文管理和工具链存在差异，不能仅凭一次试用归因于模型或平台。实际接入时应使用小任务验证代码质量，并通过测试和审查控制回归风险。

三、优点与UI复制

纯静态，部署快，维护简单，成本低（只需要域名的费用）。

外部 UI 参考可以加速原型制作，但接入前需要统一交互规范、无障碍要求和许可证边界，避免把不兼容的组件直接拼接到站点中。

::github{repo="MmzMing/my-blog"}

为了让写博客这件事变得赏心悦目，我重构了整套博客系统：前端上了 Cloudflare Pages，后台让 AI 帮我写了一套，评论也迁了新家（小猪手没迁好，小鸡限速，好难好难呜呜），好在重要评论都还在，就是格式乱了。万事俱备之后，灵异事件来了——我在电脑上打开自己的博客，慢得要死；手机打开，秒开。

装备升级：让写作成为一种享受

后台这事我调研得很认真：Qexo、Hexo CMS 看着不够漂亮，Kirameku 的毛玻璃、Halo 的清爽、ColaMD 的主题各有各的好，但没有一个完全对胃口。最后我的选择是——一个都不用，让 AI 帮我自己写一套。

成果就是 Alexander Console。思路是：不要数据库，不要后端服务器，GitHub 仓库就是后台。GitHub OAuth 登录，所有内容保存即一次 commit，仓库在，数据就在。仔细检查调试之后，发现它管的东西比我预想的多：

• 全站可管：文章、动态、相册（带加密相册和上下排序）、导航栏分组、首页 12 张卡片、书签、时间线、公告栏、碎碎念，连 Waline 评论审核都做成了内置页，躺床上拿手机就能审评论；
• 写稿不丢：编辑器草稿自动保存，写一半杀后台回来接着写；再加一道基于文件版本的守卫，别处改过的新版本，永远不会被旧草稿覆盖；新建文件撞名自动改名顺延，删除前必须二次确认；
• 图片自由：图床走 Cloudflare R2；四处背景（桌面/手机 × 登录/内页）都能攒多张自定义图，可固定、可进轮换、可单张删；
• 颜值与仪式感：日夜双主题、毛玻璃细边框、波奇酱背景、CRT 开关机加虫洞切换动画，还能以 PWA 形态装到桌面和手机主屏，像个正经 App；
• 彩蛋：它会记操作日志，月底自己弹一份小红书周报风的总结报告，告诉我这个月写了几篇、折腾了什么。

话虽如此：写作的地方顺眼，人是真的更愿意打开它码字。而这一整套，是我提需求、AI 写代码、人机配合一点点攒出来的。

基建优化：Waline 评论系统的零成本新家

评论系统 Waline 最终落在 Vercel + MongoDB Atlas 免费层，零成本零运维。避坑点留三个，全是实锤：

• 数据库连接参数（AI可查）必须拆开填：主机分片、端口数组、副本集逐项配，整串粘贴进去，部署会在你以为成功时起不来；
• 导入历史评论绝不能带管理员令牌，否则所有评论都会挂在博主本人名下；
• 社区有 Workers 移植版，但官方原版和 Workers 运行时不兼容，这条路我没走，看冷汐成功了评论系统 Twikoo 好多 bug！被迫换成了 Waline。有兴趣可以去学习下！

系统全景：我的博客长什么样

都已经到这个地步了，我觉得有必要先上全景。目前我的博客是一套「仓库即后台」的静态架构：

lanerc.me（Cloudflare Pages · Astro 静态站）
├─ 内容：GitHub 仓库（文章、动态、相册、导航全是文件）
│    └─ Alexander Console → GitHub API 读写 → 保存即 commit → 自动重建
├─ 图片/视频：Cloudflare R2（img.lanerc.me）
├─ 评论：Waline（Vercel + MongoDB Atlas）
│    └─ zhz-ai 机器人：轮询新评论，自动回复
├─ 统计：Umami 自建，前端直连公开接口
└─ 构建：数据脚本五件套 → pnpm build → Pagefind 站内搜索

拆开看就三层：写作层是控制台和仓库，我只管写，保存就是提交；托管层是 Pages，代码一推全站自动重建上线；服务层是评论、图床、统计三个独立小服务，各自跑在最适合的免费额度上，坏一个不影响其他。

更详细的可以查看站点博客日志，文章最后我也会说一下的。

排错：为什么 CF Pages 自定义域名「慢得要死」？

先摆现象：.pages.dev 默认域名飞快，绑定的自定义域名 lanerc.me 在电脑上巨慢，手机平板一切正常。注意前提：没开任何代理，电脑连的是校园网 Wi-Fi（SEU-WLAN）。

嫌疑人一：豪华网卡阵容与跃点数。 打开网络连接一看，好家伙：Radmin VPN、VPN Client、深信服 aTrust 的虚拟网卡，加上正在用的 WLAN，四块网卡同台竞技。

PowerShell 一查，当场抓到异常：

Get-NetIPInterface | Sort-Object InterfaceMetric | Format-Table InterfaceAlias, InterfaceMetric, AddressFamily

结果：VPN - VPN Client 的 IPv4 跃点数是 1，正在上网的 WLAN 是 35。Windows 的规矩是跃点数越小优先级越高——系统会优先扑向那块没在干活的虚拟网卡，DNS 查询死等超时再回退，慢就慢在这儿。听起来严丝合缝，于是继续动手查查：

Set-NetIPInterface -InterfaceAlias "VPN - VPN Client" -InterfaceMetric 50

然后，反转来了。 改成 50 之后，自定义域名没变快，连原本飞快的 .pages.dev 也跟着慢了。这说明那块虚拟网卡的低跃点数没准还在替系统扛着什么，或者这条链压根不是主因。没有对照证据，我不硬撑结论——把跃点数改回去了，恢复原状。

嫌疑人二：校园网 DNS 与 IPv6。 清掉缓存再对比解析（示例）：

ipconfig /flushdns
nslookup lanerc.me
nslookup firefly-6sp.pages.dev

实锤：校园网 DNS（172.19.2.2）给 lanerc.me 先返回两个 IPv6 地址再给 IPv4，而校园网的 IPv6 路由质量一向一言难尽；查 .pages.dev 时 DNS 干脆先超时一次才给出结果。嫌疑很大，但关 IPv6、换公共 DNS 这些候选解法，我还没逐一验证出唯一真凶，所以这一节的结论是：未破案。

总结与启发

这篇没有漂亮的破案结尾，只有一份完整的排查记录和一次老实的回滚。我的体会是：排错最忌讳把「改过参数」当成「破了案」——假设要验证，改坏了就回滚，现象记录清楚，下次接着查。折腾的乐趣有一半在坑里，愿你踩坑时手边有日志，改参数前记得留好退路。

顺带交代一下：博客本体是Astro静态站，跑在 Cloudflare Pages 上；内容全部存在GitHub 仓库里，我用自研的 Alexander Console 经 GitHub API 读写，保存即提交、提交即自动重建；图片和视频走 Cloudflare R2（img.lanerc.me），评论是 Vercel + MongoDB Atlas 上的 Waline（另有 AI 机器人自动回复），统计用自建的 Umami。整套架构只有一台服务器是为博客本体付费的（Azure的免费学生机）。

想法的萌生

首先来说一下为什么会想着重新搭建一个博客，是因为原本的不好吗？当然有一定的原因，但是并不是全部，这里来讲一下我的旧站的维护吧。

旧站采取Fuwari + Cloudflare Pages自托管的模式，是现在的一个性价比很高的搭建方式，Fuwari 负责提供极致的视觉与性能体验，Cloudflare Pages 负责提供稳定、免费且高速的全球分发。但是我为什么要放弃呢，其实我想最主要的原因是，目前我的推送流程的阻碍，现在推送的主要流程是： 本地文件更新 —git push — github push推送 — Cloudflare pages自动推送 —部署完成 看似很好很轻松的过程，但是其中隐含的缺点也有很多：

1. 写作被工具链绑架：改一个错别字、换一张图，也要走 commit/push/build，灵感场景下很重。

2. 反馈链路过长：push 成功不等于部署成功，还要等构建、看日志、处理失败；故障点分散很难查找。

3. 移动端和多设备不友好：手机上很难完成完整 Git 流程，临时修改只能等电脑。

4. 频繁小提交会消耗构建额度：Cloudflare Pages 免费版 Git 集成有每月构建次数限制，频繁 push 会浪费额度。 但更准确地说：我打算放弃的并不是Fuwari + Cloudflare Pages，而是“每次更新都必须自动触发 Git 构建”的方式。

所以我改为了VPS加AI自托管的模式：

在旧方案里，发布一篇文章本质上是一次软件部署：修改文件、commit、push、等待构建、处理构建失败。我的写作意愿被这条链路的摩擦不断消耗。而更新频率也确实如所看到的一样。

在 VPS + AI 托管模式下，发布变成了直接的内容操作。新方案（VPS + AI）通过一个具备操作能力的 AI 代理，直接接管了发布与运营这个最消耗精力的环节，完全绕过了 Git 和自动构建。

但是这并不足以让我放弃Fuwari ，这个基于 Astro 框架的静态博客模板，在设计感和开箱即用的优秀体验上有着极大的吸引力的一个静态博客。而原因在于我最近经常混迹于各种论坛，也和许多优秀的人交流中不定时的读一读他们的项目经历，在这其中我就发现了一位大佬，他的基于Firefly魔改版本的个人网站深深吸引我了 —— [折腾进行时 - 9LL.UK
所以我也萌生了魔改的想法，附上HY站长的几张siteshot：

经过调查我发现：

Firefly 直接把评论、说说/动态做成了内置的功能。根据一些迁移者的对比，它内置了评论系统、说说/动态、赞助页面和实验室/工具，大部分定制都可以通过配置文件完成，不再需要魔改核心代码。对我来说，这意味着 AI 可以操作和发布的“内容类型”变多了——它不仅能写文章，还能直接处理动态、管理内置评论，而不需要我先花时间搭建这些基础设施。这里要致敬一下大佬——[[夏夜流萤 - 飞萤之火自无梦的长夜亮起，绽放在终竟的明天。]]

将调研成果实际落地

一个很直接的证据是，社区里已经出现了专门适配 Firefly 的 AI Agent Skill（firefly-post-writing）。这个技能让 AI 能够按照 Firefly 的内容集合（Content Collections）规范，自动将 Markdown 内容放入 src/content/posts/ 下的正确位置，并生成符合其 schema 的 frontmatter（标题、日期、标签、分类等）。这意味着你的 AI 托管不需要自己去摸索 Firefly 的文件结构，可以直接调用现成的技能来完成发布，降低了 AI 操作出错的概率。链接：firefly-post-writing Agent Skill | GodBlf/godblf.github.io

那有了这些基础，选哪个模型呢？我想起来前几天白嫖了 170亿 token 的 Muse，Meta 旗下刚出的类似沙盒功能的 AI 助手，平时只帮助我处理一些 Outlook 邮件。评估一下折腾项目的评分，这次为何不挑战一下自己呢？

（PS:现在想想有点胡闹了）

然而，这次博客重构，我决定拿它当主力，看看一个 AI Agent 到底能不能独立扛下一个完整的建站项目。

我要的不是一个能聊天的模型，而是一个能动手干活的助手：读写文件、跑构建脚本、调 GitHub API、看日志、修 bug。Muse 的定位正好包含这些吧？是这个吗？。

现在给出结论：能，但是真的很累。

实战：从 Fuwari 到 Firefly 的迁移

选型

Firefly 是 CuteLeaf 基于Astro写的博客主题，Fuwari 的继任者。选它有三个原因：

1. 配置集中化：所有定制项都在 src/config/ 下，十几个 TypeScript 配置文件，改配置就能换脸，不用动核心代码
2. 功能内置：评论、动态、赞助页、实验室都是内置的，Fuwari 时代要自己搭的，Firefly 直接给了
3. AI 友好：目录结构清晰，src/content/posts/ 放文章，src/content/dynamic/ 放动态，AI 读写不容易出错

HY 站长（9ll.uk）的魔改版是我的视觉目标：卡片式布局、3px 纯黑边框、青绿色主题（hue 174）。我没直接抄代码，只定了视觉规范，让 Muse 按这个调。

迁移过程

第一步：内容迁移

旧站 11 篇文章 + About 页，直接拷到 src/content/posts/。Fuwari 和 Firefly 的 frontmatter 大体兼容，title、published、tags、category 都能直接用。有问题的手动修——比如图片路径，Fuwari 用 ./1.jpg，Firefly 推荐用 ./images/ 子目录，但实测发现 Fuwari 的构建认不出子目录（这个后面单独说）。

第二步：视觉定制

按 HY 风格改了这几处：

• 全站 hue 174 青绿，卡片 3px 纯黑边框
• 首页可拖拽贴纸（4 张 AI 生成的图，src/config/stickerConfig.ts）
• Live2D：雪初音（主）+ 金发 z16（右），桌面端显示
• 轮播图按横竖版分离：横版放桌面，竖版放手机

魔改过程：Firefly 的配置分层

Firefly 相比 Fuwari 最大的变化，是把魔改分成了两层。理解这两层，就理解了怎么在不碰核心代码的情况下，把站点改成 HY 那味。

第一层：配置驱动（零代码改动）

所有定制项集中在 src/config/ 下，十几个独立的 TypeScript 文件：

• siteConfig.ts：站点标题、描述、URL。我的站名 "Alexander"，横幅 "Lovely Life"
• navBarConfig.ts：顶部导航。我在"我的"下拉里加了 Steam（番组计划下面）、书签分组
• profileConfig.ts：侧边栏个人卡。名字 "zhz"，bio "Hello, I'm zhz."
• commentConfig.ts：评论系统。切到 Waline，waline.lanerc.me
• backgroundWallpaper.ts：背景壁纸模式
• stickerConfig.ts：首页可拖拽贴纸（我自研的，4 张 AI 图）

这一层覆盖了 80% 的视觉差异。HY 站的卡片布局、配色，基本都是改配置就能实现。AI 改这一层最安全——改错了也只是显示问题，不会构建失败。

第二层：组件与样式微调

配置搞不定的，才进 src/components/ 和样式层：

• 统计页（src/pages/analytics.astro）：HY 式卡片，加了 GitHub 推送热力图、数据卡。卡片视觉冻结后只改数据层，整体的Umami数据拉取还是不尽人意。
• Steam 页（src/pages/steam.astro）：照着 HY 的 steam 页抄的布局（玩家卡 + 统计卡 + 游戏网格），配色换成咱的青绿 oklch(0.65 0.15 174)
• 全站 hue 174、卡片 3px 纯黑边框：在全局样式里定的

这一层我让 Muse 打下手，但主要板权在我。AI 生成 diff，我 review 后再合——它今天就因为多手改了不该改的，被我骂了四次。（一共让我生气了不下16次了吧，应该是。。没数到，反正最后的包体来到了117版）

两层之间的边界

内容层（src/content/）AI 全权负责写，配置层（src/config/）AI 改完我要看一眼，组件层（src/components/、src/pages/）AI 只给建议不动手。这个边界是血泪教训：v108 那次 AI 自作主张换了头像文件，差点把友链的头像地址搞崩。

第三步：评论系统

从 Artalk 换回 Waline（Artalk 2.10.0 停服了）。Waline 跑在 HK 机 Docker 里，127.0.0.1:8360，SQLite 存数据。配了个 AI 自动回复 zhz-ai——访客留言后，跑在 ID 机上的 Python 服务（智谱 glm-4-flash）60 秒轮询一次，自动回评论。昵称显示 zhz-ai + 🤖 勋章，回复内容自称"zhz"。

第四步：统计系统

Umami 自托管，跑在 HK 机 Docker（127.0.0.1:8362）。前端不直连，走了三层：

1. 构建时 scripts/fetch-umami-stats.py 拉一份静态数据兜底
2. HK 机 cron 每 5 分钟生成 /api/stats.json
3. 前端优先读 /api/stats.json，8 秒超时后降级读构建时数据

统计页还加了 GitHub 推送热力图（构建时 scripts/fetch-github-activity.py 拉 52 周 commit 数据）。

整体上效果待定吧，这个也是以后修改的一个方向

踩坑记录

1：Fuwari 图片子目录

新文章的图片放在 images/ 子目录，./images/img22.png 这种引用，Fuwari 构建直接报 ImageNotFound。旧站 11 篇文章都是图片放根目录，Fuwari 的 Astro 配置认不出子目录。总结了一下：同步到旧站的文章，图片必须打平，./images/X 改成 ./X。

2：Cloudflare 构建队列

用 GitHub API 一篇一篇推文章，每篇一个 commit，Cloudflare Pages 疯狂触发构建，队列堵死，大部分显示 "No deployment available"。后来给AI讲批量操作要打包，用 Git Data API 把一篇文章的所有文件打成一个 commit。

3：Waline 容器 OOM

HK 机只有 887MB 内存，Waline 的 better-sqlite3 原生模块直接崩了，nginx 报 502。容器自动重启后恢复，但内存还是紧张。把不用的 whatsapp-proxy 停了，也只释放了 6MB。2C/887MB 跑 Waline + Umami + Postgres 就是勉强。（后悔没用其他机子了）

大佬们如果以后光临本站发现评论加载不出来那多半是挂了，访问的人数一多，刷新一多的话香港机子跑的就很勉强了

坑 4：Umami 分享 token 调不到 realtime

统计页的"在线人数"用分享 token 调 /api/realtime/ 返回 401。排查发现是前端 localStorage 缓存了过期的 token，换了缓存 key（v2）强制刷新后解决。

这个部分是AI做的最差的部分，目前解决起来确实很困难，但是访客视觉上不会收到太大影响。

AI 托管的工作流

现在的工作流是：

我在聊天里下指令/提交推文
→ Muse 写 Markdown 到 src/content/posts/
→ Muse 跑 ./build.sh（8 步：清缓存 → 拉 Umami → 拉 Steam → 拉 GitHub → 建索引 → AI 摘要 → Astro 构建 → Pagefind）（够复杂！！）
→ 打包 dist（148MB，split 成 80M 两卷） （免费版最大了吗？） → 我手动在 HK 机部署（curl 下载 → 解压 → chmod → purge CF 缓存）

其实这个流程也很糟心，主要是Muse应对魔改的需求还是太勉强了，其实很大部分是因为VPS的问题，跑不起那些Muse改的再好也是落地实现不了。

AI 负责写和构建，我负责部署和构思采用。配置层（src/config/）的改动我人工确认，内容层（src/content/）AI 直接写。这个边界守住的话，AI 再抽风也只影响文章，不会把站点布局搞崩。（当然他天生不是这么智能，已经把站点搞崩了3次了吧，印象中）firefly-post-writing 的护栏本身也体现了这个倾向：它要求 AI 不去改动非内容配置文件，不删除必需的 frontmatter，保持日期格式稳定。

致谢

 9LL.UK   夏夜流萤 - 飞萤之火自无梦的长夜亮起，绽放在终竟的明天。

附录

这几天烧了这么多token，Muse的量还是大啊。用不完根本用不完！

博客评论区一直是我心里的一个结——访客留言了，我不能 24 小时蹲着回。于是有了这个想法：搞个 AI 自动回评论，简单的它搞定，难的再叫我。

说干就干，一天时间，从 0 到 1，外加三个离谱 bug。记录一下。

起名：从"暮色"到 zhz-ai

一开始叫"Muse"，太直白了。后改"暮色"——汉字版的 muse，有点味道。但最后还是定了 zhz-ai，简单直接，一看就知道是站长的 AI 分身。

头像用 QQ 邮箱头像（2099621514@qq.com），Waline 认邮箱不认 avatar 字段，踩了个小坑。

架构：Flask + 智谱 + 轮询兜底

服务跑在 ID 那台机子上（HK 机子内存太小了，887MB 跑不动），Flask + gunicorn 单 worker，60 秒轮询一次 Waline 的 recent API。

为啥不用 webhook？Waline 的 WEBHOOK 是服务端环境变量，配了，但真实评论就是不触发。原因没查清——先跑起来，轮询兜底。

模型试了一圈：glm-4.7-flash 过载，glm-4.5-flash 返回空，只有 glm-4-flash 稳定。就它了。

提示词写了双风格：随笔类短平快玩梗，技术类大胆展开给建议。之前测试时回得太水（"发给我看看"这种空话），被我骂了一顿重写了——现在技术类会针对具体技术点给建议。

三个离谱的 bug

Bug 1：轮询线程从没启动过

最离谱的一个。部署了两次，AI 就是不回评论。查了半天，发现轮询启动代码写在 if __name__ == "__main__": 里——gunicorn 导入模块根本不执行这个块！

改成模块加载时直接启动线程。两分钟的事，找了一小时。🤡

Bug 2：重复回复

修好轮询后，AI 开始回了——一次回两条，一模一样。

原因：webhook 处理完没把 objectId 记到已处理集合里，轮询又扫到同一条，又回一遍。修法：在生成回复之前先标记已处理，防竞态。

Bug 3：改了 systemd 没生效

想把 gunicorn 从双 worker 改成单 worker（省内存），改完重启，没变化。查了半天——改错文件了！

systemd 实际用的是 /etc/systemd/system/ 下的 service 文件，我改的是 /opt/ 下的副本。Linux 老坑了，记录一下。

评论区自动刷新

访客发完评论，AI 回了，但页面不刷新，得按 F5 才看得到。这体验不行。

调研了 Waline 官方源码：init() 返回的 update() 只在 path 变化时重拉，同页调用无效。唯一靠谱的办法是 destroy() + 重新 init()。

最后方案：每 30 秒查一次服务端评论数，有新增且用户没在输入框打字时，才重建评论区。无新增零打扰，用户打字时不打断——草稿丢了是要骂人的。

小修小补

• 实验报告《Analog Basic Amplifier》的电路图乱码了：ASCII 电路图转 Markdown 时对齐全丢，换成原图
• 转换速率表格重排成标准 Markdown 表格
• 两篇报告清掉 Word 分页符残留（\x0c，渲染会出怪字符）
• Circuit Lab 6 的仿真截图放错了（放了张公式图），换成正确的 Multisim 截图
• 友链加了番茄主理人（排第一）、Pasule

还没搞定的

• 轮询 60 秒还是有点慢，AI 回复要 70-80 秒才可见。想改 15 秒，还在犹豫（怕被智谱限流）
• Webhook 不触发的原因还没查清
• 统计页 Swup 导航时的数据竞态修了，等验证

折腾一天，博客又活过来一点。AI 评论员已上岗，欢迎来调戏——它现在叫 zhz-ai，别叫错了。

一、为什么慢

先捋一下原来的流程：

浏览器 → Cloudflare → umami.lanerc.me → VPS 上的 Umami → PostgreSQL 查数据 → 原路返回

一次页面加载要调 4 个接口：

1. GET /api/share/{shareId} —— 拿 websiteId 和 token（token 缓存 24h）
2. GET /api/websites/{id}/stats?startAt=...&endAt=... —— 30 天统计
3. GET /api/websites/{id}/stats?... —— 今日统计
4. GET /api/realtime/{id} —— 实时在线

慢的原因：

• Umami 的 stats 查询是实时聚合，30 天的数据要在数据库里扫一遍，本身就要几百毫秒到几秒
• 多一跳 Cloudflare，每个请求都要过 CDN
• 浏览器到 Cloudflare 的链路如果差，每个请求都要等

HY（9ll.uk）快是因为他的访客到 Cloudflare 的路好，架构跟我是一样的。

二、方案：静态 JSON 缓存

核心思路：把慢查询挪到服务器端定时做，浏览器只读一个静态文件。

VPS cron（每5分钟）→ Umami localhost（快）→ 写 /api/stats.json
浏览器 → Cloudflare CDN（缓存）→ /api/stats.json（毫秒级）

好处：

• 浏览器只拉一个几百字节的 JSON，走 CDN 缓存，基本是毫秒级
• Umami 的慢查询在服务器端做，用户无感
• 数据最多 5 分钟延迟，对统计页来说完全够用

代价：

• 不是严格实时，有 5 分钟延迟（但比之前刷不出来强多了）
• 需要 VPS 上多一个 cron 任务

三、VPS 定时脚本

脚本放在 VPS 上，比如 /opt/umami-stats-cron.sh：

#!/bin/bash
# Umami 统计数据定时拉取脚本
# 每 5 分钟跑一次，把数据写成静态 JSON，供博客统计页优先读取

set -e

# ===== 配置区 =====
UMAMI_BASE="https://umami.lanerc.me"
SHARE_ID="EG15WwHeRvz2lmd2"  # 换成你自己的 share ID
# 网站根目录（nginx 的 root），stats.json 会写到 $WEB_ROOT/api/stats.json
WEB_ROOT="/var/www/lanerc"
# ==================

API_DIR="$WEB_ROOT/api"
OUT_FILE="$API_DIR/stats.json"
TMP_FILE="$API_DIR/.stats.json.tmp"

mkdir -p "$API_DIR"

# 1. 拿 websiteId 和 token
SHARE_JSON=$(curl -s --max-time 15 "$UMAMI_BASE/api/share/$SHARE_ID")
WEBSITE_ID=$(echo "$SHARE_JSON" | python3 -c "import sys,json; print(json.load(sys.stdin).get('websiteId',''))")
TOKEN=$(echo "$SHARE_JSON" | python3 -c "import sys,json; print(json.load(sys.stdin).get('token',''))")

if [ -z "$WEBSITE_ID" ] || [ -z "$TOKEN" ]; then
  echo "[$(date '+%F %T')] ERROR: 获取 share token 失败"
  exit 1
fi

NOW_MS=$(date +%s)000
DAY_MS=86400000
P30_START=$(( $(date +%s) * 1000 - 30 * DAY_MS ))
TODAY_START=$(date -d "$(date +%F) 00:00:00" +%s)000

HDR=(-H "x-umami-share-token: $TOKEN" -H "x-umami-share-context: 1")

# 2. 拉 30 天统计、今日统计、实时数据（并行写临时文件）
curl -s --max-time 20 "${HDR[@]}" "$UMAMI_BASE/api/websites/$WEBSITE_ID/stats?startAt=$P30_START&endAt=$NOW_MS&unit=day&timezone=Asia/Shanghai" -o /tmp/umami_s30.json &
P1=$!
curl -s --max-time 20 "${HDR[@]}" "$UMAMI_BASE/api/websites/$WEBSITE_ID/stats?startAt=$TODAY_START&endAt=$NOW_MS&unit=day&timezone=Asia/Shanghai" -o /tmp/umami_today.json &
P2=$!
curl -s --max-time 20 "${HDR[@]}" "$UMAMI_BASE/api/realtime/$WEBSITE_ID" -o /tmp/umami_rt.json &
P3=$!
wait $P1 $P2 $P3 || true

# 3. 组装成前端需要的格式
python3 << 'PYEOF'
import json, time

def load(p):
    try:
        with open(p) as f:
            return json.load(f)
    except Exception:
        return None

s30 = load('/tmp/umami_s30.json') or {}
today = load('/tmp/umami_today.json') or {}
rt = load('/tmp/umami_rt.json') or {}

# 在线人数：5 分钟内有活动的去重 session
online = 0
try:
    seen = set()
    cutoff = time.time() * 1000 - 5 * 60 * 1000
    for e in (rt.get('events') or []):
        from datetime import datetime
        ts = e.get('createdAt', '')
        try:
            t = datetime.fromisoformat(ts.replace('Z', '+00:00')).timestamp() * 1000
        except Exception:
            continue
        sid = e.get('sessionId')
        if t >= cutoff and sid and sid not in seen:
            seen.add(sid)
            online += 1
except Exception:
    pass

out = {
    'totalVisitors': s30.get('visitors'),
    'totalPageviews': s30.get('pageviews'),
    'todayVisitors': today.get('visitors'),
    'todayPageviews': today.get('pageviews'),
    'online': online,
    'generatedAt': time.strftime('%Y-%m-%d %H:%M:%S', time.localtime()),
}
with open('/tmp/umami_stats_out.json', 'w') as f:
    json.dump(out, f)
print('OK', out.get('generatedAt'))
PYEOF

# 4. 原子写入（先写临时文件再 mv，避免读到一半的文件）
mv /tmp/umami_stats_out.json "$TMP_FILE"
mv "$TMP_FILE" "$OUT_FILE"
chmod 644 "$OUT_FILE"
echo "[$(date '+%F %T')] stats.json 已更新"

设置 cron

# 给脚本执行权限
chmod +x /opt/umami-stats-cron.sh

# 先手动跑一次，确认能生成文件
/opt/umami-stats-cron.sh
cat /var/www/lanerc/api/stats.json

# 加到 crontab，每 5 分钟跑一次
crontab -e
# 添加这一行：
*/5 * * * * /opt/umami-stats-cron.sh >> /var/log/umami-stats.log 2>&1

nginx 配置

确保 /api/stats.json 能被访问。如果你的 nginx root 已经是 /var/www/lanerc，那 https://lanerc.me/api/stats.json 会自动生效。不需要额外配置。

建议给这个文件加个短缓存（CDN 层面），比如 1 分钟：

location = /api/stats.json {
    expires 1m;
    add_header Cache-Control "public, max-age=60";
}

四、前端改造

前端逻辑：先尝试拉 /api/stats.json，成功就用它；失败则走原来的 Umami API（原逻辑一行不动，作为兜底）。

我在 analytics.astro 里加了一个独立的 <script> 块，放在主逻辑之前：

<script is:inline>
// 静态 JSON 优先尝试：VPS 定时任务每 5 分钟生成 /api/stats.json
// 成功则渲染并设置标志，主 script 会直接返回；失败则静默，主 script 走原有 API 逻辑
(function () {
    function fmt(n) { return Number(n || 0).toLocaleString(); }
    function renderStatic(d) {
        var map = {
            totalVisitors: d.totalVisitors,
            totalPageviews: d.totalPageviews,
            todayVisitors: d.todayVisitors,
            todayPageviews: d.todayPageviews
        };
        Object.keys(map).forEach(function (k) {
            var el = document.querySelector('[data-stat="' + k + '"]');
            if (el && map[k] != null) el.textContent = fmt(map[k]);
        });
        var onlineEl = document.getElementById("live-online");
        if (onlineEl && d.online != null) {
            onlineEl.innerHTML = '<span class="online-dot"></span>' +
                (d.online > 0 ? d.online + " 人在线" : "在线");
        }
        var updatedEl = document.getElementById("live-updated");
        if (updatedEl) {
            var t = new Date().toLocaleString("zh-CN", { hour12: false }).slice(0, 16);
            updatedEl.textContent = "实时更新于 " + t + " · 30天区间";
        }
        try {
            localStorage.setItem("lanerc-umami-live",
                JSON.stringify({ ts: Date.now(), data: d }));
        } catch (e) {}
    }
    fetch("/api/stats.json", { cache: "no-store" })
        .then(function (r) { if (!r.ok) throw 0; return r.json(); })
        .then(function (d) {
            if (d && (d.totalVisitors != null || d.totalPageviews != null)) {
                renderStatic(d);
                window.__lanercStatsDone = true;  // 标记已命中
            }
        })
        .catch(function () {});  // 失败静默，主逻辑会兜底
})();
</script>

主 script 开头加一行检查：

(function () {
    if (window.__lanercStatsDone) return;  // 静态 JSON 已命中，直接返回
    // ... 原有 Umami API 逻辑（未改动）
})();

关键点：

• 两个 script 块互相独立，静态 JSON 的那个失败了不会影响主逻辑
• 用 window.__lanercStatsDone 做标记，避免重复渲染
• fetch 用 { cache: "no-store" }，确保拿到的是最新的（CDN 层面可以设 1 分钟缓存，平衡实时性和速度）
• 原有 API 逻辑一行没动，JSON 文件不存在或拉取失败时自动降级

注意 is:inline：Astro 构建时会处理 <script> 标签，不加 is:inline 的会被打包优化掉，导致线上不执行。这个坑我踩过两次了，血的教训。

五、效果对比

六、踩坑记录

1. Astro 的 is:inline：内联 script 必须加 is:inline，否则构建时会被 Astro 处理掉，线上 JS 根本不执行。我之前已经因为这个坑修过两次统计页了。

2. 原子写入：cron 脚本写 JSON 时先写临时文件再 mv，避免浏览器读到写一半的文件。

3. 时区：Umami API 的 timezone=Asia/Shanghai 参数别漏，否则今日数据会对不上。

4. 在线人数计算：realtime 接口返回的是 events 列表，需要按 sessionId 去重，只算 5 分钟内有活动的。这个逻辑在前后端都要保持一致。

七、总结

这个方案的核心就是用空间换时间：VPS 上多一个 cron 任务，换来前端毫秒级的加载体验。对于统计页这种"数据可以容忍几分钟延迟"的场景，非常划算。

如果你也在用 Umami 做博客统计，且访客网络环境复杂，可以试试这套方案。完整脚本在上面，直接拿去改改配置就能用。

一、Waline：评论系统

1. Docker 部署

Waline 官方镜像 lizheming/waline，用 SQLite 就行，不用额外数据库。

# 生成随机 JWT 密钥（在你自己的终端执行）
openssl rand -hex 32

# 启动容器（把上面生成的密钥填进去）
sudo docker run -d \
  --name waline \
  --restart always \
  -p 127.0.0.1:8360:8360 \
  -v waline-data:/app/data \
  -e SQLITE_PATH=/app/data \
  -e JWT_TOKEN=你生成的密钥 \
  -e SERVER_URL=https://waline.lanerc.me \
  lizheming/waline:latest

三个必加的环境变量，一个都不能少（都是 10-16 亲测踩坑）：

验证：

curl -s http://127.0.0.1:8360/api/comment | head -c 200
# 应返回 {"errno":0,...}，不是 000

2. 手动建表（必须）

Waline 镜像不会自动建表。首次部署后手动建三张表：

# 起个临时容器连上 waline-data 卷
sudo docker run --rm -it -v waline-data:/app/data alpine sh
apk add sqlite
sqlite3 /app/data/waline.sqlite

-- wl_Comment（注意必须有 sticky 列，漏了查评论列表会报错）
CREATE TABLE wl_Comment (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  user_id INTEGER, comment TEXT, insertedAt TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  ip VARCHAR(100), link VARCHAR(255), mail VARCHAR(255), nick VARCHAR(255),
  pid INTEGER DEFAULT 0, rid INTEGER DEFAULT 0, sticky INTEGER DEFAULT 0,
  status VARCHAR(50) DEFAULT 'approved', like INTEGER DEFAULT 0,
  ua TEXT, url VARCHAR(255), createdAt TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  updatedAt TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE wl_Counter (id INTEGER PRIMARY KEY AUTOINCREMENT, time INTEGER, url VARCHAR(255), createdAt TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updatedAt TIMESTAMP DEFAULT CURRENT_TIMESTAMP);
CREATE TABLE wl_Users (id INTEGER PRIMARY KEY AUTOINCREMENT, display_name VARCHAR(255), email VARCHAR(255), password VARCHAR(255), type VARCHAR(50) DEFAULT 'guest', url VARCHAR(255), avatar VARCHAR(255), github VARCHAR(255), twitter VARCHAR(255), facebook VARCHAR(255), google VARCHAR(255), weibo VARCHAR(255), qq VARCHAR(255), createdAt TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updatedAt TIMESTAMP DEFAULT CURRENT_TIMESTAMP);

真正的库文件是 /app/data/waline.sqlite（waline.db 是 0 字节空文件，别搞错）。

3. nginx 反代 + Cloudflare

/etc/nginx/conf.d/waline.conf：

server {
    listen 80;
    server_name waline.lanerc.me;
    location / {
        proxy_pass http://127.0.0.1:8360;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

sudo nginx -t && sudo systemctl reload nginx

Cloudflare 加 A 记录 waline → VPS IP，橙色云朵（代理），SSL 设 Flexible。

4. 博客端接入

src/config/commentConfig.ts：

export const commentConfig = {
  type: 'waline',
  waline: {
    serverURL: 'https://waline.lanerc.me',
    // 其他按需
  },
};

管理员机制：第一个注册的用户自动成为管理员。如果之前测试账号先注册占了位置，查库：

SELECT id, display_name, email, type FROM wl_Users;
-- 把测试账号删掉，真实账号 type 改成 'administrator'
UPDATE wl_Users SET type='administrator' WHERE email='你的邮箱';

5. 时间戳坑（1970 问题）

Waline 前端有个 bug：用 createdAt 而不用 insertedAt 会导致 1970 时间。博客首页的"最近评论"组件用的是 insertedAt，记得统一。老数据用触发器回填，存北京时间。

二、Umami：访问统计

1. 为什么不用 Umami Cloud

自建免费、数据在自己手里。代价是要个 PostgreSQL（Umami 不支持 SQLite/MySQL）。

2. Docker 部署（纯 docker run 版）

注意：我这台香港 VPS 的 Docker 29.1.3 没有 compose 插件，所以用纯 docker run 脚本。包在 ~/workspace/blog-build/umami/，两个文件：deploy-umami-docker-run.sh + nginx-umami.conf。

mkdir ~/umami && cd ~/umami
# 把 umami-deploy.tar.gz 解压到这里
tar -xzf umami-deploy.tar.gz
sudo bash deploy-umami-docker-run.sh

脚本做的事情：

1. 自动生成 .env（强密码，600 权限，复跑沿用）
2. 建 umami-net 独立 Docker 网络
3. 起 umami-db（postgres:15-alpine，带 healthcheck，轮询等 healthy）
4. 起 umami（ghcr.io/umami-software/umami:3.4.0，只绑 127.0.0.1:8362）
5. 等 /api/heartbeat 通

关键环境变量（脚本自动处理，手动部署时注意）：

# umami 容器必需
-e DATABASE_URL=postgresql://umami:密码@umami-db:5432/umami
-e APP_SECRET=随机字符串  # 必须显式设置，不设静默降级有安全隐患

首次启动自动建表 + 创建 admin / umami 账号——立刻改掉默认密码。

数据不丢：PostgreSQL 用命名卷 umami-db-data，重装容器数据还在。

3. nginx 反代

nginx-umami.conf（脚本包里自带，拷到 /etc/nginx/conf.d/）：

server {
    listen 80;
    server_name umami.lanerc.me;
    location / {
        proxy_pass http://127.0.0.1:8362;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Cloudflare 加 A 记录 umami → VPS IP，橙色云朵。

4. 创建网站 + 拿 Website ID

登录 https://umami.lanerc.me → Settings → Websites → Add website，填域名 lanerc.me。创建后点进网站详情，URL 里那串 UUID 就是 Website ID。

博客 src/config/analyticsConfig.ts：

export const analyticsConfig = {
  umami: {
    enabled: true,
    websiteId: '你的-website-id',
    scriptUrl: 'https://umami.lanerc.me/script.js',
    // 会话回放（可选，v3.1+）
    replays: {
      enabled: true,
      scriptUrl: 'https://umami.lanerc.me/recorder.js',
    },
  },
};

5. 构建时拉数据（给统计页用）

统计页 /analytics/ 的数据是构建时从 Umami API 拉的，不是实时查：

# 在你自己的终端（不要贴 key 到聊天里）
export UMAMI_API_KEY="你的api-key"
python3 scripts/fetch-umami-stats.py

脚本拉取：

• 90 天 daily（给 7/30/90 天切换）
• 30 天 hourly（给 7×24 热力图）
• devices / browsers / topPages / referrers

输出 src/data/umami-stats.json。

两个坑：

1. 403 限流：Umami 对密集请求返回 403，不是 key 错。脚本里每个请求间隔 2 秒。
2. type 参数：metrics 接口用 type=path，type=url 会 400。realtime 接口路径是 /api/realtime/{websiteId}。

API Key 在 Umami 后台 Settings → API Keys 创建。Key 只显示一次，丢了就重新生成。

三、统计页前端：SVG 环形图

数据有了，前端展示。学 HY 的 donut 图，不用 ECharts，SVG 手画：

---
const R = 54, C = 2 * Math.PI * R;
let offset = 25;
const segs = items.map((item, i) => {
  const len = (item.count / total) * C;
  const el = (
    <circle cx="70" cy="70" r={R} fill="none"
      stroke={colors[i]} stroke-width="18"
      stroke-dasharray={`${len} ${C - len}`}
      stroke-dashoffset={-offset}
      transform="rotate(-90 70 70)" />
  );
  offset += len;
  return { el, pct: Math.round((item.count / total) * 100) };
});
---
<svg viewBox="0 0 140 140">
  <circle cx="70" cy="70" r={R} fill="none" stroke="#f3f0ea" stroke-width="18" />
  {segs.map(s => s.el)}
</svg>

原理：stroke-dasharray 控制每段弧的显示长度，stroke-dashoffset 累加实现拼接，rotate(-90) 让起点从顶部开始。

淡背景图必须用 CSS background-image，不要用 <img> 绝对定位：

.device-card {
  background-image:
    linear-gradient(rgba(255,255,255,0.9), rgba(255,255,255,0.9)),
    url('/images/analytics/card-11.jpg');
  background-size: cover;
  background-position: center;
}

踩坑总表

两套服务跑下来，评论和统计全在自己手里，不依赖第三方 SaaS。备份记得带上 waline-data 和 umami-db-data 两个 Docker 卷。

四、站点统计页：设计思路

为什么学 HY

HY 的 9ll.uk/analytics 是我见过最好看的个人站统计页。核心三招：

1. 双栏错落：左宽右窄，卡片高低错开，不是一排排堆下去——单栏看着像后台管理系统，双栏才像"展示页"。
2. 环形图 + 条排布：设备、浏览器用 donut 图，左边图右边图例（彩色圆点 + 名称 + 百分比），信息密度高又不挤。
3. 淡背景：二次元妹子图 8-10% 透明度铺底，若隐若现。纯白卡片太素，全图背景太吵，淡化是中间解。

卡片规划（11 张）

地域和来源暂无数据（站太新），先上架子等数据——总比"即将上线"强。

技术选型

• 不用 ECharts：donut 图用 SVG 原生 <circle> + stroke-dasharray 手画，零依赖，加载快。
• 构建时拉数据：Umami 和 GitHub 都是构建时跑 Python 脚本写 JSON，页面纯静态。坏处是不是实时，好处是访问快、不怕 API 挂。
• Waline 评论客户端拉：评论需要实时性，用 client:load + 2 分钟本地缓存。

五、调试过程：三次翻车

翻车一：Cloudflare 缓存（两次）

症状：部署完 v46，打开网站一看——导航栏没有"站点统计"按钮。本地构建明明有。

排查：

# 查线上 HTML
curl -s https://lanerc.me/ | grep -c 'href="/analytics/"'
# 输出 0

# 查 8880 直连（不走 Cloudflare）
curl -s http://20.239.49.52:8880/ | grep -c 'href="/analytics/"'
# 输出 2

8880 有，lanerc.me 没有——Cloudflare 把旧 HTML 缓存了。

解法：Cloudflare 后台 purge 缓存。或者先用 8880 验证，确认没问题再清缓存看正式站。

教训：部署完第一件事不是问"看到了吗"，而是先 purge。

翻车二：img 冒充背景图

症状：设备卡和推送卡的淡背景图，我用 <img class="device-bg"> 绝对定位实现。一看效果：这叫背景图？语义完全错了，重做。

原因：<img> 绝对定位虽然视觉上像背景，但语义错了，而且要额外处理 z-index、pointer-events。CSS background-image 才是正解。

修复：

/* 错误示范（已删） */
.device-bg { position: absolute; inset: 0; opacity: 0.1; }

/* 正确做法 */
.device-card {
  background-image:
    linear-gradient(rgba(255,255,255,0.9), rgba(255,255,255,0.9)),
    url('/images/analytics/card-11.jpg');
  background-size: cover;
}

翻车三：图片被裁得只剩一条

症状：推送卡热力图下方加了张樱花图，设了 height: 120px + object-fit: cover，结果一看：这叫调整大小？？？整个图片被裁得只剩中间一条。

原因：想着固定高度更整齐，但我要的是完整图片。object-fit: cover 会裁掉上下，16:9 的图只剩中间一条。

修复：height: auto，宽度 100% 顶满，完整显示。

教训：图片展示这事，整齐和完整只能二选一，先想清楚你要哪个。

六、优化过程：v46 → v62

一晚上 16 个版本，每个版本只改一件事：

优化原则：

1. 一次只改一件事：方便回滚，v56 重做 v54、v60 重做 v59 都是这么来的。
2. 截图即需求：自己截图标红的地方，就是下一版的改动点，不用猜。
3. 字体只调小不调大：从第 6 张卡开始，标题 1.35rem、小节 0.95rem，信息密度上来了就不吵了。
4. 动画克制：落樱每个卡 3 片，opacity 0.45，多了就是杀马特。

源码在 src/pages/analytics.astro，单个文件 800+ 行。想抄的直接看文件，比看这篇管用。

七、后续方向：国内访问加速

目前博客在国内访问很慢，这是下一步要解决的。思路：

先分析原因：到底是 Cloudflare 边缘节点问题、VPS 到国内的线路问题，还是纯粹的备案缺失导致的绕路？得先抓数据——不同地区、不同运营商的延迟和丢包率，找出瓶颈在哪。这部分分析后续补充。

备案的打算：如果分析下来是线路问题，考虑给域名做 ICP 备案，然后上国内 CDN。但备案意味着服务器要迁回国内，整套 Docker（Waline、Umami）都要跟着迁，成本不小。还在看，先把原因分析清楚再决定。

总之：先诊断，再开药。盲目上 CDN 烧钱没意义。

迁移：11 篇文章，一次过

Firefly 用 Astro 的 content collections 管内容，文章丢进 src/content/posts/ 就行。旧站 11 篇文章加 About 页，图片路径改成相对路径，构建一次通过，没出幺蛾子。新域名 lanerc.me，旧站留着 www.lanerc.me，导航栏加个"开往旧站"，体面分手。

构建：别在 VPS 上作死

第一个坑出现在构建环节。pnpm build 会先跑一堆联网的生成脚本（GitHub 卡片数据、封面抓取之类的），在网络差的环境直接卡死。解决办法：只改内容的时候直接跑 ./node_modules/.bin/astro build，跳过那些脚本。

第二个坑更狠：之前试过在 VPS 上直接构建，结果 Node 进程被 OOM killer 干掉，exit 133。887MB 内存的小鸡就别想本地构建这种事了。从此定下规矩：本地构建 dist，VPS 只做静态托管，nginx 伺候。

还有个玄学坑：删掉 src/content/posts/ 下的 md 文件后重新构建，dist 里居然还有已删除文章的残留——Astro 的 content 层缓存在 node_modules/.astro 里没失效。删文件后构建前先 rm -rf node_modules/.astro，百试百灵。

样式：3px 黑边框的执念

看中了某个站长的方框质感，卡片统一改成 3px solid #1c1c1c 粗黑边框，hue 调到 174 的青绿色。favicon 换成双猫图，深浅色自动切换——最骚的是把主题里所有旧 favicon 文件名的内容全都替换成新图，防止任何回退路径冒出旧图标。别问，问就是被浏览器缓存坑过。

页脚加了萌 ICP 备案和实时运行时间计数器。侧栏的建站时长一开始显示 653 天，原因是 siteStartDate 写着 2025-01-01，改成今天，世界清净了。

音乐：下载站的攻防战

站内播放器加了三首歌。下载的时候发现下载站耍花招："下载"按钮实际是打开新标签页播放，根本不触发文件下载。绕过去的办法是让它暴露音频直链，然后 curl 直接抓——网易云的签名 URL 有效期大概一小时，手要快。

更绝的是这站现在加了"口令解锁"，要拿快手极速版扫码。行吧，以后再下歌就手动过。

Live2D：从五个到一个

主角色雪初音常驻，旁边最多的时候摆了五个小伙伴：白猫 tororo、金发 z16、chitose、shizuku、wanko。中间还闹过笑话——把西装男 chitose 认成 z16 删错了，又换回来。

技术上有个坑：l2d-widget 的根节点是个没有 class 的 position: fixed div，没法用常规选择器定位。最后用的办法是记录组件创建前后的 DOM 差集，找到带 canvas 的 fixed div 来定位每个小伙伴。

最后还是决定做减法：只留金发 z16 一个站在右下角，和主角色左右对称。五个确实太吵了。

项目页与书签：从占位到自家东西

主题自带的"Firefly 主题模版"和"示例项目"两个占位直接删掉，换上自己的五个：Folia、Komari Monitor、哪吒管理面板、Cloud Mail、IP 检测工具，每个都配了主页截图。Komari 的介绍里专门写了后台可视化和 WebSSH——电脑没电的时候，手机平板开网页就能 SSH 连服务器，这体验谁用谁知道。

书签导航加了"论坛"分组（Linux Do、NodeSeek、NodeLoc、奶昔论坛），工具分组塞了硬核指南，图标一个不少。

部署：一键脚本

写了个 deploy.sh，做几件事：装 nginx、删 Debian 默认站点、解压 dist、修权限防 403、监听 80 和 8880（高位端口方便直连预览）。VPS 上跑一遍，完事。

一天下来发了 22 个版本，博客算是彻底换了个样子。剩下的就是慢慢写文章了。

先交代一下背景：上周收到短信说卡到网点了，我兴冲冲杀过去，结果——没带身份证。 柜员小姐姐保持着职业微笑：「先生，没有身份证我们没办法给您发卡。」再一看表，支行 16:30 关门。我站在门口，像个没交作业被赶出教室的小学生。

很巧的是晚上招行的联名花嫁卡也下来了，五天真是神速啊，正好顺手一起拿

一天后，也就是昨天，身份证揣兜里揣得死死的，趁中午短休时间，两张卡，一次拿下！

第一张：中银 × b 站万事达 —— 干活的卡

这张是冲着「海外支付」去的。万事达通道，境外网站、各种订阅扣款就靠它了。

说实话，办它的理由特别务实：VPS 续费、域名续费、时不时冒出来的境外小额订阅，以前总要绕来绕去。现在一张万事达在手，全球 200 多个国家和地区的商户都能刷，省心。

卡面是 b 站联名设计，低调里带点二次元味，不会太社死，拿得出手。

第二张：招行 × b 站纯白花嫁 —— 好看的卡

如果说中银那张是干活的，这张就是纯粹的颜值消费。

纯白卡面，2233 娘的花嫁装，拿到手第一反应是：这哪是银行卡，这是收藏品。白色卡身干干净净，阳光下看还有点质感，刷卡的时候掏出来，收银员都得多看两眼。

至于权益？不重要。好看，就是它最大的权益。

总结

一对卡，一个负责征战海外，一个负责貌美如花，分工明确，配合默契。

唯一的问题是：卡是拿下了，额度是银行的，账单可是我的。。。

补充：

招商银行的服务质量确实好啊，两次拿卡都非常的丝滑流畅

一直听说 LINUX DO 是个技术氛围很好的地方，最近便想着去注册一个账号看看。

结果去了解了一下申请规则，心凉了半截——常规申请要求 GitHub 账号注册满 5 年。看了看自己那个才建了两年多的 GitHub 主页，只能默默关掉页面。当时确实有点失落，感觉硬性门槛就把自己挡在门外了。

后来不甘心又去翻论坛的帖子，发现社区其实还有个预申请系统 | 预申请系统，也就是大家俗称的“年轻版”，专门给 GitHub 年限不够的用户准备的通道。于是抱着试一试的心态，认真填写了申请，之后就进入了等待。

这里想给想申请的小白朋友一个建议就是认真写明自己是从哪来，想要来这个社区做什么事情即可，感情真挚管理员一般会通过的。

今天晚上，手机突然弹出 QQ 邮箱的提醒。点开一看，是来自 noreply 的邮件：

✓ 审核通过 🎉 预申请已通过 恭喜！你的预申请已通过审核，请根据指导意见完成... 看到“审核通过”那几个字的时候，心里还是挺高兴的。连忙按照邮件里的指引完成了注册流程。

新手教程与年轻版的限制

进站第一件事当然是过新手教程。跟着流程走完，收到了 @discobot 的消息，还发了一张专属的证书。

不过，申请通过是一回事，年轻版的限制确实是存在的。在论坛里逛了逛才发现，因为走的是预申请通道，账号在初期有很多权限受限。比如一些热门板块（像“资源荟萃”之类的）可能进不去，或者只能看不能回，另外信任等级的提升也会比较慢。

其实这也完全能理解，毕竟社区要控制质量，防范小号和水军。对我这种 GitHub 年限不够的人来说，能有个“先上车”的机会已经很感激了。

接下来的日子，大概率就是老老实实潜水，多看看大佬们的开发调优帖。遵守社区规则，慢慢攒信任等级。

能进来就好。Hello, LINUX DO。

• 我本人是在YouTube上根据博主：Porter科技迷 的视频一步步做的，我本人使用的是身份证进行的KYC认证，后续如果有小伙伴想要买币有疑问的尽管去学习博主的视频，非常高质。
• 视频网址是：【最强U卡】Bybit Card格鲁吉亚卡｜支持订阅GPT｜支持微信、支付宝、Apple Pay等｜中国大陆身份免费申请｜0门槛线上开卡 | 新客福利拉满 | 从申请Bybit交易所到入金充值全过程

核心区别

视频发布时可能还不支持绑定微信支付宝还有apple pay以及Google play商店，但是主包目前实测是可以的，感兴趣的小伙伴可以去尝试一下！

PS:绑定的过程均不需要挂代理哦

**申请网址为：爱沙尼亚乌龟卡eSIM申请及写入过程

背景

用 EasyEUICC 把 eSIM 写入小白卡，写卡成功后却收不到短信，折腾了一圈终于搞定。把过程整理出来，供后来人参考。

• 上网浏览了一下很多人买的加0欧的收不到消息，这个具体什么原理我也不清楚，主播买的号段是5704段0欧的，前前后后一共花费了44RMB，保号现在政策能保到6-7年，也是非常有性价比啊。*
• 第一次入坑的小白浏览网页经常遇到类似这样的评论，大家不要慌啊，我也是被这些搞得破崩了，放弃的两天后试试结果成了，关键在于等待吧。*

一、写卡流程（Android）

1. 小白卡插入安卓手机卡槽。
2. 打开 EasyEUICC → 右上角菜单 → 兼容性检查，通过后重启 App。
3. 右下角 “+” → 选择’二维码写入‘，“手动输入”或“从剪贴板读取”。
4. 粘贴 LPA:1$... 格式激活码。
5. 写入完成后，点卡片菜单 → 启用，等待信号出现。

注意：

• 激活码必须以 LPA:1$ 开头。
• EasyEUICC 只能操作小白卡，管不了手机自带 eSIM。
• 写卡后建议先关闭数据漫游。

以下内容来自Linux do社区

二、有信号但收不到短信？

1. 先确认信号

• 看状态栏是否有 “R” 和 4G/5G。
• 完全无信号 → 可能是运营商限制，联系卖家。

• 成功标志可以看屏幕左上栏：

2. 检查短信中心号码（SMSC）

• 路径：设置 → 关于手机 → SIM卡状态 → 短信中心号码
• 常见正确值示例：+37256100020
• 保持默认也可以
• 号码错误会导致短信收发全废。

3. 检查拦截与默认卡

• 短信 App 的“拦截记录/垃圾箱”翻一翻。
• 设置 → 移动网络 → SIM卡管理，默认短信卡切到小白卡。

4. 手动选网

• 关闭“自动选择”，手动搜索运营商，选信号最好的，重启手机。

5. 平台风控（重点）

• 官网测试短信能收到，但小红书/Telegram/Google 等收不到。
• 原因：平台对境外号段、虚拟运营商号有风控，从源头不下发。
• 平台提示“需要 1–2 天设置”是风控观察期，如果只能收到卖家发来的短信其他的收不到的话，建议等满 24 小时再试，别频繁点。
• 换干净节点有时也有帮助。

6. 主播心路历程

这里也是成功了，最后也是松了一口气，按照之前的过程操作之后，给大家展示一下成果： 然后主包这里也尝试注册了一下WhatsApp，也成功了：

三、移动数据与漫游

• 移动数据总开关关闭时，即使有信号也可能收不到短信。
• 打开数据，默认上网卡选小白卡。
• 但要注意流量费：余额低于 0.1 欧会直接断网，国内建议切回国内卡上网，小白卡只收短信。
• 显示“无法识别号码”是正常现象（未写入 MSISDN），不影响收发短信。

四、误删 Profile 昵称怎么办

• 只是删昵称：EasyEUICC 里信息还在，不影响使用。
• 可在 EasyEUICC 菜单里 重命名/编辑 改回来。
• 确认 Profile 状态是 “已启用”。
• 设置 → 移动网络 → SIM卡管理 里确认开关打开，重启手机试试。
• 真正删除 Profile 后旧激活码会失效，需联系客服重新发码。

五、iOS 能用 EasyEUICC 吗？

不能。EasyEUICC 没有 iOS 版。

替代方案：

1. 纯 iPhone：买 USB-C 读卡器或蓝牙 eLPA 读卡器，配合 9eSIM LPA 或 NekokoLPA App 使用。
2. 安卓写卡 + iPhone 用卡：用安卓机写好，拔卡插进 iPhone，通过 STK 菜单切号。

建议：有安卓备用机的话，第二种最省事。

总结

• 写卡不难，难在收短信。
• 优先查：信号 → SMSC → 拦截 → 平台风控。
• “无法识别号码”别慌，不影响用。
• 余额别低于 0.1 欧。

姓名：zhz 学号：06024436

课堂上听完老师解说的《牡丹灯记》之后，我的脑子里一直在盘旋着一个问题：如果你深爱的那个人，有一天你发现她不是人，而是鬼，你还会继续爱下去吗？这个问题看似荒诞，又像是只能出现在志怪小说里的情节，但实际上它问得很现实------我们对感情的坚持到底有多强，当遇到外界压力时，我们真的能守住自己的心吗？

《牡丹灯记》讲述的是书生乔生与女鬼符丽卿之间跨越 "生死鸿沟" 的爱情悲剧。元宵夜邂逅后，符丽卿每晚都会在丫鬟金莲的牡丹灯引路下，来到乔生的书房与他相会。两人朝夕相伴，情意渐浓，宛如寻常恋人般亲密无间。然而，随着乔生日渐憔悴，他在尾随符丽卿时意外发现真相------她原是已故奉化州判之女的魂魄，日夜相伴的不过是一段人鬼殊途的情缘。得知真相后，乔生满心恐惧，虽并未在他人劝说下动摇，但是主动求助了道士。道士赠予他一道符咒，乔生按法安置后，符丽卿便再未出现，两人以这种被动隔绝的方式结束了相处。遗憾的是，乔生后来醉酒忘形，违背道士的告诫重走相遇之路，再次遭遇符丽卿。最终，他被符丽卿拉入棺中同葬，这段跨越阴阳的爱情，终究以两人生死相随的悲剧落幕。

我第一次听到这个故事时，最触动我的，是符丽卿的真心。她虽然是鬼，可她对乔生的情感却比很多活人都要纯粹。没有功利、没有目的，她的出现只是因为喜欢，只是因为想陪伴他。符丽卿拥有的，是一种 "想爱却没有资格爱" 的悲哀------人鬼殊途的宿命早已注定了她的情感没有归途，她的真挚反而在乔生的犹豫面前，更显得珍贵。

乔生作为活生生的人，却在关键时刻暴露了懦弱的本质。最初，他以为符丽卿是普通孤女，两人的相处建立在纯粹的信任与喜欢之上，情意日渐深厚。可当他亲自尾随，亲眼目睹符丽卿进入湖心寺的棺材，才惊觉自己日夜相伴的竟是鬼魂------这一真相如晴天霹雳，瞬间击垮了他的勇气。随后，邻人告知曾窥见她是粉骷髅的惊悚事实，更让他恐惧加深。此时道士、邻人的告诫，不再是凭空而来的劝告，而是恰好击中了他内心的恐惧，成为压垮他的最后一根稻草。他不再念及过往情分，只想逃离这份跨越阴阳的危险，最终主动求助道士，用符咒将符丽卿被动隔绝。这份因恐惧而生的退缩，终究辜负了那段纯粹的陪伴。

读到这里，我忍不住想：究竟是谁更"像人"？谁更"像鬼"？

符丽卿虽然是鬼，但她善良、温柔、真诚，最初并无害人之心，始终以纯粹的情感陪伴乔生。乔生虽然是人，却在外界压力下抛弃了承诺与感情。故事通过这样鲜明的对比，让"鬼"与"人"的边界变得模糊，也让我们意识到：决定一个人是否值得爱的，不是身份，而是心。

放到现实里，这种情况其实一点也不陌生。现在虽然社会比过去开放了很多，但爱情依然会被各种声音干扰------父母反对、经济差距、社会观点、朋友劝告......许多原本坚固的感情，常常就是在这些看似"为你好"的话语中被动摇的。乔生的经历，可能就是现实里许多人的影子。

有时候我会想，如果乔生多一点直面真相的勇气，多一点坚持，是不是就能改变结局？也许符丽卿不会被赶走，也许他们真的能跨越生死，在一起一段时间。哪怕最终没有圆满，至少也不会像故事中那样留下如此深的遗憾。

符丽卿这个角色让我特别心疼。她在生前可能没体验过幸福，死后好不容易遇到乔生这样对她好的男子，却因为自己无法改变的"鬼"的身份被拒绝。她既不能解释，也不能反抗，只能默默接受这一切。这个形象其实带着浓厚的悲剧性，让人感受到一种无奈的爱情宿命------她的身份成了她最无法摆脱的枷锁。

这让我想到现实中被"标签化"的人。有人因为家境普通、因为长相一般、因为学历不高，就被外界轻易否定，连恋爱的资格都好像被剥夺了。但这些外在的条件，真的能决定一个人值得不值得被爱吗？在我看来，完全不能。爱一个人应该是因为她的心，而不是她的条件。

乔生的性格其实很典型。他在感情中有真心，却缺乏担当；有喜欢，却不够坚定；有勇气开始，却没有勇气继续。他的失败并不是因为不爱，而是因为他不敢为爱承担后果。这种"懂得爱，却不会爱"的无力感，在故事的结尾被放大到了极致。

在我看来，《牡丹灯记》不仅是一段人鬼恋，更是一面镜子。它照出了一个人的善良、胆怯、自私、犹豫，也让我们看到外界压力对爱情的破坏力。乔生的故事让我明白一个道理：当你没有勇气保护你爱的人时，你就是在亲手失去她。

故事的结局是悲伤的：本来相互喜欢的人，最终却被命运或人的软弱拆散。在我看来，乔生接受符咒隔绝符丽卿后，并未立刻醒悟这份感情的珍贵，直到一次醉酒忘形，违背道士的告诫重走相遇之路，才再次与符丽卿重逢。此时的他已无退路，最终被拉入棺中同葬。他或许到最后才明白，自己当初因恐惧放弃的，是多么纯粹的真心 ------可这份醒悟来得太晚，连挽回的机会都没有，只留下无法弥补的遗憾。

这种后悔也没用的结局，让我联想到现实中无数错过的爱情。很多人都是在失去后才意识到自己真正想要什么。可是感情从来不等人，错过了，就是错过了。

听完故事，我对瞿佑也有了新的理解。在明初那样保守的社会背景下，他敢写人鬼相恋，并且让读者对这段感情产生同情、产生共鸣，这确实很有突破性。他借"鬼怪"包装爱情，其实是为了更自由地表达自己的观点：真正的感情不该被身份和世俗束缚。

虽然故事里有驱鬼、术法等迷信元素，但这些只是噱头，真正的核心，是对爱情和人性的探讨。在那个时代，作者可能只能通过志怪的方式来暗示自己对封建束缚的不满，对真挚爱情的珍惜。

听完《牡丹灯记》，我也忍不住设想：如果我是乔生，我能不能坚持下去？面对所有人都说"这是危险的"的情况，我有没有勇气坚定地站在恋人这边？坦白说，我也不敢确定。但我知道，如果一个人连在关键时刻保护爱人的勇气都没有，那么这份感情就不够稳固，也经不起考验。

符丽卿给人的感受，是一个既温柔又孤独的灵魂，她的爱真诚到让人心酸。作者在描写她的时候，用了很多细腻的细节，让她的形象鲜活而可怜，让读者不自觉地站在她那边。可以说，她的存在是对"爱需要勇气"这句话最深刻的诠释。

从这个故事里可以看到，无论古今，人对感情的渴望都是相似的。人们希望被选择、被理解、被珍惜，也希望能和心爱的人在一起。古代的障碍是封建礼教，现代的是现实压力；障碍变了，可感情的阻力却并没有减少。

《牡丹灯记》给我最大的启示就是：珍惜眼前人，别让犹豫和恐惧毁掉一段真心。人鬼殊途的宿命或许难以抗衡，但选择能决定是否留下遗憾。如果你确定一个人值得你爱，那就勇敢一些，坚持一下------哪怕有外界压力，有现实困难，也至少为这份真心拼尽全力。就算结局不尽人意，你曾努力过、珍惜过，也不会像乔生那样，直到彻底失去才懂悔恨，最终留下终身无法弥补的遗憾。

总结来说，《剪灯新话》写的是鬼怪，讲的却是人心。瞿佑用奇幻的外壳，说的是真实的情感和人性的弱点。他赞美真挚的感情，也批判那些束缚人的旧规矩。他让读者意识到：身份、背景、世俗眼光，都不应该成为阻挡真爱的理由。

读完这篇小说后，我对爱情也有了更深的体会：爱一个人，不应该看她的身份、条件，而应该看她对你的心意和你们之间的感受。希望我们都能像符丽卿那样真诚地去爱，也希望我们在面对感情时，能比乔生更勇敢一点，不要让本该珍惜的人成为遗憾。

在本学期的音乐鉴赏课程中，我第一次系统而完整地接触到从古典到现代、从西方到东方的多种音乐形式。过去我对音乐的理解更多停留在日常听歌的层面，而这门课却让我发现：音乐从来不只是旋律的组合，更是文化的载体、情感的表达、思想的呈现、以及人与世界沟通的方式。特别是在观看了课程推荐的相关音乐作品与演出片段后，我对音乐的思考有了新的提升，也渐渐明白了"欣赏"与"聆听"的区别。

一、从聆听到理解：音乐不只是"好听"

课程初期，老师让我们接触爵士乐的经典作品。起初我会觉得这些音乐对我有些 "遥远"：节奏又复杂又特别，好多地方都和平时听的流行歌不一样，还有不少即兴的部分，一开始根本跟不上思路，旋律和伴奏的搭配也不像流行歌那么好懂。然而随着课堂的引导，我慢慢学会从节奏特点、演奏方式、音乐背后的故事这些方面去感受爵士乐。我逐渐意识到，爵士乐看似自由随性的表达背后，其实藏着演奏者的用心和真实情绪；它之所以能流传这么久，不仅仅是因为风格独特，更因为里面满是对生活的热爱，能让不同的人都感受到共鸣。音乐鉴赏这门课程教会我的第一个重要收获，就是要带着"理解"去听音乐，而不是只判断"好听或不好听"。

二、音乐与情感的联系：从古典到现代的体验

课程中让我印象最深的，是老师分享的指挥家提奥多库伦奇斯的演出视频。视频中的演奏方式极富张力，他把古典作品诠释得极具情绪冲击力。我过去以为古典音乐应该是"端庄、安静"的，但库伦奇斯的指挥让我第一次看到音乐可以如此狂放、激烈、甚至带着冲突感。他的诠释突破了我对古典音乐的固有印象，让我明白古典并不是"老"或"过时"，而是一种永远可以被重新理解的艺术。

这种体验也让我回头再听一些现代音乐作品，例如课程中推荐的大卫·吉尔摩演唱会视频。吉尔摩的音乐虽然属于摇滚范畴，但他的吉他音色有一种独特的"叙事感"，每一次的演奏都像在讲述心中最柔软的故事。他的音乐没有古典作品那样复杂的结构，却有极强的情绪力量。同样是"表达情感"，摇滚则更直接、更像发自内心的呐喊。

在这段时间的聆听后，我第一次意识到：不同风格的音乐并不是彼此割裂，而是共同构成了我们的情感谱系。音乐的形式虽有不同，但其目的都是表达情感，触动灵魂。

三、音乐与时代：理解作品背后的文化与交叉

课堂上我还了解到了音乐与文化的关系。在听完"传统古琴意向与跨文化创作" 的讲座后，我对音乐和时代、文化的联系有了新感受。古代文人抒发情感常借助于传统古琴，古琴充满了古典文化的韵味。而现今成红雨老师把古琴和德国音乐制作结合，海纳・格兰钦老师将爵士钢琴与古琴创意融合，这就说明音乐不是孤立的，它跟着时代发展、文化碰撞在不断变化。

这让我明白，想要真正感受音乐，得看看它背后的文化。就像古琴在古代是一种意境，现在和外国音乐风格碰撞后，又有了不一样的感觉。每一段琴音、每一种旋律组合，其实都藏着当时人们的生活态度、文化想法。所以音乐就像个 "文化桥梁"，既能带我们回溯传统，又能让我们看到不同文化交融出的新火花。

四、个人感悟：音乐的最终指向

通过本学期的学习，我逐渐意识到一个最重要的观点：音乐终究是关于我们自己。无论是古典作品，还是摇滚音乐，它们之所以能被一代又一代的人欣赏，是因为音乐承载了人的情感、命运、困惑、追问与期待。

在欣赏库伦奇斯的指挥时，我感受到的是一种突破与澎湃；在聆听吉尔摩的吉他独奏时，又体会到一种孤独与温柔并存的情绪。不同的音乐让我在不同的瞬间看见了自己，看见了内心那些难以表达的部分。

音乐鉴赏课程给我的最大收获，并不是让我记住多少作曲家或时期，而是让我明白：音乐真正的力量，是帮助我们更好地理解情感、理解世界、理解自己。

五、结语

这门课不仅拓宽了我对音乐的认知，更改变了我聆听音乐的方式。让我学会了带着思考去听、带着理解去感受，也开始愿意探索更多种类的音乐。未来我会继续保持这种开放的心态，因为音乐本身就是一个永远没有尽头的世界。

实 验 报 告

课程名称： 电路实验

第 2 次实验

实验名称：应用Multisim软件工具设计电路验证网络定理

院 （系）：电子科学与工程学院 专业：电子科学与技术

姓 名： zhz 学 号： 06024436

实 验 室: 403室 实验组别：

同组人员： 实验时间：2025年11 月14日

评定成绩： 审阅教师：xxx

一、实验目的

（1）通过实验加深对参考方向、基尔霍夫定理、叠加定理、戴维南定理的理解； （2）Multisim 软件入门：元器件配置、电路连接、电路参数测试； （3）通过学习对实验结果的分析对比，了解虚拟仿真与实物实验的差异。

二、实验原理

1. 基尔霍夫定理：

   • 电流定理（KCL）:任意时刻，流进和流出电路中节点的电流的代数和等于零。
   • 电压定理（KVL）:在任何一个闭合回路中，所有的电压升或降之和等于零。

2. 叠加定理：

   • 在线性电路中，任一支路的电流或电压等于电路中每一个独立源单独作用时在该支路所产生的电流或电压的代数和。

3. 戴维南定理：

   • 任何复杂的线性有源一端口网络都可以用一个电压源和一个等效电阻的串联来等效。电压源的电压端口的开路电压，而电阻等于端口的全部独立电源置零后的输入电阻。

4. 二极管特性：

   • 二极管的主要特性：单向导电性。当阳极电压高于阴极时电流通过，二极管导通；当阴极电压高于阳极时电流截止。
   • 伏安特性：正向呈指数上升反向几乎为零，直到击穿点。

三、实验内容

1、基尔霍夫定理、叠加定理的验证

（1）按图1所示实验电路建立电路。用电压表和电流表测量各电阻两端电压和各支路电流。分析说明测量结果。

表1 测量数据

实验结果分析：

实验电路中因电流表电压表内阻的微小影响产生了微小的误差，三个仿真电路中KCL和KVL均成立，各条支路的叠加电压电流测量结果基本符合叠加定理，验证了叠加定理。

（2）将300Ω电阻改成1N4009的二极管（正极连接到A点上），自行建立表格，记录测量数据，计算测量结果并分析说明。

表2 测量数据

实验结果分析：

本实验在将R3更换为二极管后，在三个仿真电路中，各节点电压、电流符合基尔霍夫定律；叠加计算值与实际同时加电结果数值上误差保持在7%左右，U3的数值误差较大。二极管属于非线性元件，理论上叠加定理不成立，本实验中其在三种情况下均保持正向导通，使电路较好的拟合为线性电路，因此在本实验中数值上叠加定理基本成立。

2、设计电路，验证戴维南定理

（1）开路电压测量仿真电路

断开R3, 测量A、B端口电压为开路电压Uoc：

测量得到开路电压Uoc=9.435 V

（2）短路电流测量仿真电路

短路R3, 测量A、B端口的短路电流：

测量得到短路电流为Isc=0.065 A

（3）建立等效电路，验证戴维南定理。

表3 测量数据

实验结果分析：

本实验通过开路电压Uoc和短路电流Isc的测量，计算得戴维南等效电阻Ro≈145.154Ω，并构建了等效电路。将等效电路与原负载连接后测得的电流与原电路完全一致，验证了戴维南定理的正确性。实验误差较小，说明仿真连接正确、测量方法合理。

四、实验使用仪器设备（使用软件）

Multisim 14.3

五、实验总结

实验误差分析：

1. 实验中使用的电流表内阻设为 1Ω、电压表为 10MΩ。在实际测量中，电流表串联会改变支路电流大小，电压表并联会造成轻微分流，特别是在小电流（mA级）时，1Ω 内阻对电流影响明显。造成叠加结果与理论结果在 I2、I3上出现毫安级差异，因为短路支路中串入了 1Ω 的表内阻使戴维南短路电流Isc稍低于理论值。
2. 在线性电阻网络中叠加定理电压、电流不完全重合的原因：小误差来自仪表内阻不完全理想。在二极管网络中，二极管为非线性元件，叠加定理理论上不成立。

实验中出现的问题及解决方法：

1. 电流读数为负值：检查电表极性，修正电表方向，使大多数读数满足正值。
2. 仪表无读数：发现电路中未连接公共地线，增补上地线。

思考题：

分析实验过程中测量值出现负值的原因。

实验中出现电压或电流为负值的主要原因是测量参考方向与实际电路中电压、电流方向不一致。负号来自参考方向的差异，并不影响电压、电流大小本身的正确性。

收获体会：

通过这次实验，我对基尔霍夫定理、叠加定理和戴维南定理有了更深刻的理解。自己动手在Multisim中搭建电路、观察电压电流的变化，让我明白了参考方向、仪表内阻以及二极管非线性对测量结果的影响。在叠加和戴维南验证中，我体会到理论条件与实际仿真之间仍存在差异，需要结合元件状态来判断是否适用。实验过程中熟悉了Multisim的使用方法，提高了我分析电路的能力。总体来说，这次实验加深了我对基础电路理论的理解，也让我意识到细心操作和合理分析的重要性。

六、参考资料

1. 东南大学电工电子实验中心，《电路实验教学计划（2025秋学期）（九龙湖）1》
2. 邱关源，《电路第六版》（高等教育出版社）------ 电路模型与电路定律相关内容。

Animeko：开源、自由、无广告的追番神器

如果你厌倦了广告弹窗、会员门槛和资源缺失的烦恼，那么 Animeko 绝对是你的理想之选。作为一款在 GitHub 上开源的跨平台追番软件，Animeko 支持 安卓、iOS、Windows、Mac、Linux 全平台使用，真正实现多设备无缝追番。 注意：iOS端不开放AppStore下载，所以基本面向其他平台开放。

核心亮点：

• 完全免费 & 无广告
  软件本身不植入任何广告，界面简洁清爽，专注于提供纯净的观看体验。虽然部分视频源可能自带广告，但你可以自由切换至无广告源。

• 多源聚合，资源丰富
  内置蜜柑计划、动漫花园、BT 等多种数据源，支持在线播放与离线下载。无论是当季新番还是冷门老番，基本都能找到高清资源。

• 弹幕互动 & 云同步
  支持加载多平台弹幕，增强观看趣味性。登录账号后，还能同步收藏列表与观看进度，换设备也不怕断档。

• 高度自定义
  可手动设置播放源、弹幕源、分辨率、字幕语言甚至指定字幕组，满足资深用户的个性化需求。

• 离线缓存 & 自动预载
  支持提前缓存多集内容，通勤、旅行时也能畅快追番。开启自动缓存功能，系统会智能为你下载最新一集。

注意：Animeko 为开源项目，依赖社区维护，偶尔可能出现数据源失效的情况，建议保持关注更新。

官网地址：Animeko （即为下载地址） 适合人群：追求自由、技术向、多平台同步的深度用户。

Lanerc：简洁流畅、社区活跃的追番新秀

相比 Animeko 的极客风格，Lanerc 更像是为大众用户量身打造的“友好型”追番 App。它专注于提供稳定、合法、易用的动漫观看服务，适合不想折腾、只想安心看番的朋友。

更新内容：不定时出现流氓开屏广告，让你找不到退出按键。

主要特色：

• 海量正版资源
  所有内容均来自合法授权渠道，涵盖日漫、国漫、韩漫及剧场版、OVA 等多种类型，更新及时，追新番毫无压力。

• 高清画质 & 流畅播放
  提供多种清晰度选择（标清/高清/超清），根据网络状况智能切换，确保流畅不卡顿。

• 智能推荐系统
  基于你的观看历史和偏好，自动推荐相似风格的好番，帮你发现更多宝藏作品。

• 多端同步 & 离线下载
  登录账号后，收藏、进度、下载记录全同步，手机、平板、网页端随意切换。支持离线缓存，无网环境也能追番。

• 活跃社区互动
  内置弹幕、评论、分享功能，还能参与话题讨论，与其他动漫爱好者交流心得，感受二次元的温暖社群氛围。

• 入站问答机制
  新用户需通过简单的“入站问答”才能正式使用，既增加了仪式感，也有效防止了滥用和爬虫。

注意：Lanerc 目前主要面向安卓和移动端用户，PC 端体验相对有限。此外，开发商也迫于压力不定时投放广告，但浏览一次之后12小时以内不需要再看广告。

软件发布页： tv.lanerc.app 官网地址：Lanerc 适合人群：喜欢简洁界面、注重版权合规、享受社区氛围的新手或日常用户。

对比总结

结语

如果你渴望自由、无拘束的追番体验，愿意花一点时间配置和探索，Animeko 是目前能找到的最强免费工具之一；而如果你更看重稳定性、合法性和易用性，希望打开即用、安心追番，那么 Lanerc 会是一个更贴心的选择。 愿你每一部想看的番，都能顺利加载，不负热爱，不负青春。

姓名：zhz 实验日期：2025年11月6日

实验目的

1. 认识数字集成电路，能识别各种类型的数字器件和封装
2. 掌握小规模组合逻辑和逻辑函数的工程设计方法
3. 掌握常用中规模组合逻辑器件的功能和使用方法
4. 学习查找器件资料，通过器件手册了解器件
5. 了解面包板的基本结构、掌握面包板连接电路的基本方法和要求
6. 了解实验箱的基本结构，掌握实验箱电源、逻辑开关和LED电平指示的用法
7. 学习基本的数字电路的故障检查和排除方法

实验内容1：数值判别电路

实验仪器

• 数字逻辑电路实验箱及其外设装置---供电、脉冲、边沿和时钟
• 集成芯片：74HC20（双4输入与非门）、74HC00（四2输入与非门）、74HC04（六反相器）
• 外围设备：逻辑电平开关、LED指示灯、导线若干

实验设计方案(a)

1. 真值表

2. 卡诺图

3. 逻辑化简

逻辑表达式：
Y = B̅₃B₂ + B̅₃B₁B̅₀
= B̅₃(B₂ + B₁B̅₀)
= B̅₃(B₂ + B₁)(B₂ + B̅₀)

由于要求只使用与非门和非门，需要将上述表达式转换为与非-与非形式。

4. 逻辑电路图

5. 硬件连接图

6. 实验过程

搭建好电路并进行测试，按照真值表顺序从第一组测到第十组的过程中发现前7组结果正常，第8组理论应输出低电平，实际却输出高电平，继续测试发现后面几组测试结果均正确，经过故障排查发现电路地线接错地方，接到电源的负极输出端。将地线接GND之后重新测试一遍发现电路输出结果正常。

7. 测试方案

8. 实验分析

1. 基于真值表绘制卡诺图并化简，得到逻辑表达式后，转换为与非-与非形式，仅使用与非门和非门完成电路设计
2. 硬件连接采用74HC20和74HC00芯片，通过实验箱的逻辑电平开关输入信号，LED指示灯显示输出
3. 测试遍历所有有效输入组合，输出结果与理论真值表完全一致，电路功能实现正常

实验设计方案（b）

1. 真值表

2. 卡诺图

3. 逻辑化简

逻辑表达式：
Y = B̅₃B₂B̅₁B̅₀ + B̅₃B₂B̅₁B₀ + B̅₃B₂B₁B̅₀ + B̅₃B̅₂B₁B₀
= B̅₃B₂(B̅₁B̅₀ + B̅₁B₀ + B₁B̅₀) + B̅₃B̅₂B₁B₀

4. 逻辑电路图

5. 实验过程

测试前对照逻辑电路图，再次确认74HC系列门电路的引脚定义例如74HC00的输入输出引脚、电源与接地引脚，并检查实验箱的逻辑电平开关、LED指示灯模块是否正常供电。整理所需导线，按信号流向（输入→芯片→输出）规划导线连接路径，避免导线交叉缠绕影响后续排查。

6. 测试方案

7. 实验小结

依据"数值大于2且小于7"的需求构建真值表，无无关项，所有16种输入组合均有明确输出状态。通过卡诺图化简得到逻辑表达式，采用门电路搭建逻辑电路，输入输出连接方式与方案a部分一致。测试覆盖全部16种输入组合，LED显示结果与理论输出完全匹配，电路满足设计要求。

实验内容2：3位二进制原码转补码电路

实验仪器

• 数字逻辑电路实验箱及其外设装置---供电、脉冲、边沿和时钟
• 集成芯片：74HC86（四2输入异或门）、74HC00（四2输入与非门）、74HC04（六反相器）、74HC151(8选一数据选择器)、74HC138(3线-8线译码器)
• 外围设备：逻辑电平开关、LED指示灯（3个）、导线若干

实验设计方案（a）

1. 真值表

2. 卡诺图

Y₂卡诺图：

Y₁卡诺图：

Y₀卡诺图：

3. 逻辑表达式

Y₂ = A̅₂A₁ + A̅₂A₀ + A̅₂A₀A̅₁ = A₂ ⊕ (A̅₁A̅₀)
Y₁ = A₁ ⊕ A₀
Y₀ = A₀

4. 逻辑电路图

5. 验证结果表格

6. 实验分析

硬件连接通过实验箱逻辑电平开关输入原码，3个LED指示灯分别显示补码的三位输出。测试遍历所有8种输入组合，实际输出与理论补码完全一致，所有测试结果均符合要求，电路功能准确实现。

实验设计方案（b）

1. 逻辑表达式

Y₀ = A₀
Y₁ = A₁ ⊕ A₀
Y₂ = Σm(1,2,3,4)

2. 逻辑电路图

3. 硬件连接图

4. 实验过程

整理所需导线，按信号流向（输入→芯片→输出）规划导线连接路径，避免导线交叉缠绕影响后续排查。搭建电路时，先将74HC芯片插入实验箱的IC插座，确保芯片引脚与插座完全贴合，无虚接情况。连接电路后测试得出测试结果。

5. 验证结果表格

6. 实验分析

本实验题目中Y1的输出可用与非门来搭建，相比较两种方法都很省芯片省跳线。和老师沟通之后得知数据选择器一般和与非门来搭配使用，以后的搭建过程中如无特殊要求我会优先选择与非门的使用。

实验设计方案（c）

1. 逻辑表达式

Y₀ = A₀
Y₁ = A₁ ⊕ A₀ = (A₁A̅₀ + A̅₁A₀)
Y₂ = A̅₂A₁ + A̅₂A₀ + A̅₂A₀A̅₁ = (A̅₂A₁ + A̅₂A₀A̅₁)

2. 逻辑电路图

3. 硬件连接图

4. 实验过程

按照逻辑电路图搭建好电路之后，按照3位二进制数真值表的顺序依次调节逻辑电平开关，设置输入组合。每设置一组输入，观察LED指示灯的亮灭状态，并立即记录结果。

5. 验证结果表格

6. 实验小结

本实验使用三种方法设计三位源码转补码的电路，通过三种电路的设计，我深刻理解到电路设计的灵活性与科学性，在设计电路的过程中，应善于从不同角度看待问题，从而选择更简洁更方便的方法，三种设计方案中，我学会了很多74系列芯片的使用方法，也从不同角度理解了电路的灵活性，对我以后的设计有很大的帮助。

实验内容3：血型配对电路

实验器材

• 数据选择器（74HC151）1片
• 逻辑电平开关（4个，对应输入D、C、B、A）
• LED指示灯（1个，对应输出Y）
• 实验面包板、导线若干

实验设计方案

1. 真值表

2. 卡诺图

3. 逻辑化简

逻辑表达式：
Y = D̅C̅ + D̅BA + DCBA + D̅C̅B̅A̅

4. 逻辑电路图

5. 硬件连接图

6. 实验过程

1. 电源连接：将芯片的Vcc和GND分别连接到直流电源的对应端，为芯片供电
2. 芯片放置：将74HC151（数据选择器）插入面包板，确保引脚与电源、地正确连接
3. 输入电路连接：将4个逻辑电平开关分别连接到数据选择器的地址端（D→A₂、C→A₁、B→A₀）和数据端（A），作为输入信号源
4. 逻辑门连接：根据化简后的逻辑，用与非门构建辅助逻辑电路，连接到数据选择器的输入引脚（如D₀~D₇）
5. 输出电路连接：将数据选择器的输出端Y连接到LED指示灯

7. 测试方案

8. 实验分析

调试方案：当输入为O型输血给任意血型（D=0、C=0，B、A任意）时，LED应点亮；当输入为A型输血给A型、AB型（D=0、C=1，B=0、A=1或B=1、A=1）时，LED应点亮；当输入为B型输血给B型、AB型（D=1、C=0，B=1、A=0或B=1、A=1）时，LED应点亮；当输入为AB型输血给AB型（D=1、C=1，B=1、A=1）时，LED应点亮；其他非法组合时，LED应熄灭。

结果分析：根据结果表格，对应真值表发现电路测试结果正确。

实验内容4：保险箱数字密码锁（选做）

实验器材

• 74HC00芯片(2片)、74HC20（1片）
• 逻辑电平开关（4个，对应输入A3、A2、A1、A0）
• LED指示灯（1个，对应输出Y）
• 实验面包板、导线若干

实验设计方案

1. 真值表

2. 逻辑表达式

Z1 = E·A3·A̅₂·A1·A0
Z2 = E·(A̅₃ + A₂ + A̅₁ + A̅₀)

3. 逻辑电路图

4. 硬件连接图

5. 实验过程

使用4个输入信号，通过实验箱上的逻辑电平开关实现；1个输出端连接到实验箱上的LED指示灯。按照真值表要求，拨动逻辑电平开关以改变输入信号的值，遍历所有输入组合，观察并记录输出信号的值。

6. 测试结果

7. 结果分析

测试所有输入组合，结果应与真值表一致。当E=1且密码正确时，Z1输出1；当E=1且密码错误时，Z2输出1；当E=0时，Z1和Z2均输出0。电路功能符合要求，且使用了最少数量的与非门。

实验小结

实验仪器环节

对数字电路实验常用仪器设备形成了清晰认知，熟悉了74HC20（双4输入与非门）、74HC00（四2输入与非门）、74HC86（四2输入异或门）、74HC151（8输入数据选择器）和74HC138（3线-8线译码器）引脚功能与适用场景，掌握了面包板、逻辑电平开关、LED指示灯的操作规范，能够根据实验需求选择并连接仪器，为硬件电路搭建筑牢了实践根基。

实验记录环节

基本学会了规范且细致地记录实验步骤、原始数据、实验过程及故障排查信息。在数值判别电路和补码转换电路的实验记录中，逐步养成了按流程操作、逐点记录数据的习惯，提升了实验操作的条理性。同时，在面对实验故障时，掌握了从硬件连接、芯片引脚到导线接触等多维度排查并解决问题的方法，锻炼了发现、分析和解决问题的能力，增强了实验过程中的应变与动手能力。

实验分析环节

掌握了数字电路实验结果分析比对的方法，通过将实测输出与理论真值表、逻辑推导结果逐一验证，深入理解了逻辑函数化简、门电路选型与电路功能实现的内在关联，提升了对数字电路逻辑关系的分析与验证能力，也切实体会到理论知识在实践中的有效性，强化了"理论指导实践，实践验证理论"的认知。

实验小结环节

对数字电路的完整设计流程有了系统性把握。如从数值判别电路的两种方案设计，到补码转换电路的功能实现，每个环节的实践都让我对数字电路设计的思路、方法及优化策略（如利用无关项简化逻辑）有了更深刻的理解。同时，在总结实验完成情况、讨论设计方案与结果的过程中，明确了自身在数字电路实践中的成长与待提升点，如电路设计有待提升，电路搭建有待提高，排查故障经验需要继续积累等等，为后续学习积累了宝贵的经验与思考。

参考资料

1. 器件数据手册：74HC00、74HC04、74HC20、74HC86、74HC151、74HC138 软件使用和器件数据手册.rar
2. EPI-LITE304数字电路 东南大学文档云
3. 两个基础实验（EPI-m204）东南大学文档云
4. EPI-EWB204+快速上手 东南大学文档云 *word版本文件地址：通过网盘分享的文件：实验一组合逻辑电路实验报告.pdf.docx 链接: https://pan.baidu.com/s/1q8wvtFLdw0oDjZJTxisA7Q 提取码: eybn

注：以上逻辑表达式为deepseek识图识别，个别出现错误，请注意甄别！

指导教师：xxx

姓名：zhz
学号：06024436
桌号：26
日期：2025年10月27日

实验报告格式要求：中文字体宋体、英文字体Times New Roman、字号小四、行间距1.5倍；图表应有题注及编号。

实验报告内容包括：

1. 实验简介（实验背景、原理、实验方法等）
2. 实验仪器
3. 数据与分析（数据表格、数据作图、必要的数据处理过程、结果分析）
4. 实验小结
5. 附录（将课堂上的原始数据拍照附于此处，原始数据上需有教师签字）

实验简介

1、实验背景

霍尔效应是指当载流导体或半导体置于磁场中并通以电流时，在垂直于电流和磁场方向上会产生电势差的现象。该电势差称为霍尔电压。这一现象最早由E. H. Hall于1879年发现。霍尔效应在半导体研究中具有重要意义，可用于测定材料的导电类型、载流子浓度及迁移率等特性。

2、实验原理和测量方法

（1）霍尔电压的产生

把一块宽为b，厚为d的半导体放在磁感应强度为B磁场中,并在半导体中通以电流I，如图所示，在这块半导体横向侧面AA′间会出现一定的电势差UH，这个现象叫做霍尔效应，UH称为霍尔电压。

实验表明，霍尔电压UH的大小正比于磁感应强度的大小B以及电流I，在UH、B、I三者相互垂直时有：

UH=KHBI

式中KH称为该霍尔元件的灵敏度，与载流子浓度n、霍尔片厚度d相关（KH=1/nqd）。

图1

（2）霍尔电压的灵敏度

霍尔元件的灵敏度KH= 1/(nqd)，与载流子浓度和样品厚度成反比。半导体的载流子浓度远低于金属，因此使用薄型半导体霍尔元件能显著增强霍尔效应。

（3）对称测量法求霍尔电压

实验中可能出现不等位电势差和热电、热磁副效应（如厄廷好森效应、能斯脱效应、里纪-勒杜克效应）。通过"对称测量法"，即反转磁场或电流方向取平均，可有效消除这些干扰，提高测量精度。具体方法是通过改变IS和B的方向测4次电压（+IM、+IS，+IM、-IS，-IM、-IS，-IM、+IS，IM为励磁电流）,分别记为U1、U2、U3、U4，综合考虑四种效应的影响：

UAA'=UH +UO+UE +UN+URL

通过四次测量可消除UO、UN、URL的影响：

UH = (-U1 + U2 - U3 + U4)/4

若UE很小，可近似：

UH≈ (-U1 + U2 - U3 + U4)/4

（4）电导率与载流子参数计算

电导率σ：由电极间的电压UAC和IS计算：

σ=ISL/UACS（L为A、C间距，S=bd为霍尔片横截面积，b为宽度）

霍尔系数RH：RH=KHd

载流子浓度n: n=1/eRH（e=1.602×10^−19^C）

通过测量霍尔系数和电导率，可以计算出迁移率。载流子迁移率μ与电导率σ的关系为

σ = neμ

实验内容

（1）确定霍尔片的载流子类型

根据霍尔片上的连接方式、电流源的流向、电磁铁的绕向以及电压表的连接方向，然后依据霍尔电压的正负来判断n型霍尔片和p型霍尔片。

（2）测量p型霍尔片的灵敏度

保持工作电流 Is = 2.00 mA，励磁电流 IM取值 0.200 A ~ 0.700 A，用对称测量法测量 p 型霍尔片的霍尔电压，绘制并分析UH --- IM曲线，用图解法求灵敏度KH值。

（3）测量 p型半导体的电导率，计算霍尔系数、载流子浓度及载流子迁移率

在零磁场条件下，通以合适的工作电流 Is（Is≤0.20 mA）测量 UAC，结合中霍尔片的相关参数，计算本实验中用于制作 p 型霍尔片的半导体材料的电导率σ．计算该半导体的霍尔系数 RH、载流子浓度 n 和载流子迁移率μ。

图2

（4）测量 n型半导体的霍尔系数、载流子浓度及载流子迁移率

按照以上的步骤，选择合适的工作电流和励磁电流，测量 n 型半导体的霍尔系数 RH、载流子浓度 n 和载流子迁移率 μ，并和 p 型半导体进行比较。

（5）利用霍尔效应测量磁场

系统可配合SPARKvue APP进行数字化采集与实时曲线绘制，支持导出 CSV 或 SPKL 文件格式，以便进一步数据分析。

采用数字化方式测量单线圈、不同距离下双线圈轴线上磁场分布情况(时间充足时也可探究更多不同线圈位置下磁场分布情况)，请保证支架处在0 cm时，霍尔探头刚好在线圈中心位置。将采集到的数据导出后进行处理，尝试用matlab或origin等软件在同一坐标系下作出单线圈、不同距离下双线圈的磁场强度位置图。

实验仪器

图3

1、电磁铁

用于产生实验所需的磁场。电磁铁的励磁电流IM由测试仪提供，铁芯气隙中心区域的磁感应强度 B 与IM在一定范围内呈线性关系，可引入电磁铁常数 C，即

B=CIM

不同实验仪的电磁铁常数略有差异，具体数值标示在线圈外壳上。

2、霍尔片与支架

实验中分别使用p型与n型半导体霍尔片，两者几何尺寸相同。霍尔片通常采用薄型半导体材料，以获得较大的霍尔电压信号，其尺寸为：

宽度 b = 4.00 mm，厚度 d = 0.30 mm，电极间距 l = 2.00 mm。

图4

3、开关与接线装置

该系统包含一个五刀双掷开关与三个双刀双掷开关。

五刀双掷开关：用于选择接入电路的霍尔片（p型或n型）。

K₁：K1向上扳时，恒流源输出的电流由D端流进，向下扳时，则由G端流进。

K₂：控制励磁电流方向，K2向上扳时，IM的流向与线圈相同，反之相反。线圈的绕向标示在电磁铁上。

K₃：切换电压测量模式，K3向上扳时，毫伏表测量UAA'，向下扳时测量UAC。

该设计能够快速切换测量参数，实现"对称测量法"以消除副效应带来的误差。

4、霍尔效应测试仪

该装置为实验核心设备，用于提供电源、测量与数据输出。其主要部分包括：

电源开关:用于开启或关闭整机；

数字接口：连接计算机或数据采集系统；

电压表：实时显示霍尔电压或电导电压；

工作电流旋钮：为霍尔元件提供恒定电流；

励磁电流旋钮：为线圈提供励磁电流，顺时针调大、逆时针调小；

注意：切换电流方向或插拔导线前，须将旋钮调至零位，以防突变电流损坏元件。

5、测量与辅助装置

实验装置配备精密导轨，可调整霍尔片在磁场中的具体位置，确保测量区域磁场均匀。电压采用毫伏表测量，以保证对微小电压信号的高精度读取。此外，系统可配合 SPARKvue APP 进行数字化采集与实时曲线绘制，支持导出 CSV 或 SPKL 文件格式，以便进一步数据分析。

整个霍尔效应实验仪器结构完善，功能集成度高。开关系统与数字化采集技术的结合，不仅提高了实验精度，也为霍尔效应研究提供了便捷的操作平台。

数据与分析

1. 载流子类型判断

实验中，控制工作电流流向与磁场方向一定，左侧霍尔片测得的 UAA'> 0，说明载流子为正电荷（空穴），属于p型半导体；右侧霍尔片测得的 UAA'< 0，说明载流子为负电荷（电子），属于n型半导体。

该结果与理论一致，验证了霍尔电压符号与载流子类型的对应关系。

2、测量p型霍尔片的灵敏度

法一：使用霍尔电压和磁场大小的关系

表1 用对称测量法测p型霍尔片的霍尔电压

工作电流 Is = 2.00 mA；电磁铁常数 C = 465mT/A；室温 t = 23.3°C

注：测量时，IM 应单向调节，减小磁滞效应的影响。

数据分析1

根据图像得知：所测量得到的霍尔电压灵敏度KH=3.23 V/($A \cdot T$)

法二：使用霍尔电压和工作电流的关系

表2 用对称测量法测p型霍尔片的霍尔电压

IM=0.7A；Is从1.00A到2.00A变化；电磁铁常数 C = 465mT/A；室温 t = 23.3°C

数据分析2

根据图像得知：所测量得到的霍尔电压灵敏度KH= 3.35 V/($A \cdot T$)

分析与比较：

两种方法均属于对称测量，但方法二（四组电流方向对称）在系统误差消除上更具优势，在霍尔效应测量中抑制系统误差效果更佳显著；方法一的"数据对称"（拟合UH-IM）虽能体现线性关系，但受磁场线性度和Is稳定性影响更大，误差相对偏高。

3.测量p型半导体的电导率，计算霍尔系数、载流子浓度及载流子迁移率

表3 测量p型半导体的电导率

IM=0;室温 t = 23.3°C

数据分析3

根据以上分析总结如下：

P型半导体霍尔片电导率为26.82 S/m

霍尔系数RH=3.23×10^-4^ m^3^/C

载流子浓度n=6.44×10^21^ m^-3^

载流子迁移率μ=2.600×10^-2^ m^2^/($V \cdot S$)

4.测量n型半导体的霍尔系数、载流子浓度及载流子迁移速度

表4 用对称测量法测n型霍尔片的霍尔电压

IM=0.7A；Is从1.00A到2.00A变化；电磁铁常数 C = 465mT/A；室温 t = 23.3°C

数据分析4

由图像可知：n型半导体霍尔片的霍尔电压灵敏度为-10.93 V/($A \cdot T$)

表5 测量n型半导体的电导率

IM=0;室温 t = 23.3°C

数据分析5

根据以上分析总结如下：

n型半导体霍尔片电导率为27.50 S/m

霍尔系数RH=-3.279×10^-4^ m^3^/C

载流子浓度n=1.904×10^21^ m^-3^

载流子迁移率μ=0.902 m^2^/($V \cdot S$)

思考问题：为什么测量之前要先测一组Is置零的情况？

在测量 n 型半导体电导率时，测"置零组Is=0时的UAC）"的核心目的是消除零位误差，具体原因如下：当 Is=0时，理论上半导体中无工作电流，对应的电压UAC应严格为 0。但实际中，由于以下因素会产生 "零位电压"：

（1）霍尔片不等势误差：霍尔片的电极制作不可能完全对称，无电流、无磁场下电极间也会因接触电阻、几何不对称存在微小电压。

（2）仪器零点漂移：电压表、电流源等仪器本身存在固有偏移，导致 "零输入" 时仍有输出读数。

所以在后续计算电导率时，需将每个Is对应的UAC减去置零组的UAC，得到修正后的电压UAC'= UAC - 0.06mV)，以此消除零位误差对线性关系和电导率计算的干扰。

5.利用霍尔效应测磁场

工作电流Is=5mA;励磁电流IM=0.5A;霍尔元件灵敏度KH=2316 V/($A \cdot T$)。

改变线圈之间的长度为R/2、R、2R，软件读取函数如下图：

图5

四、实验小结

本实验我通过对霍尔效应的系统研究，掌握了霍尔电压的测量方法、载流子类型的判断依据，以及半导体材料电导率、霍尔系数、载流子浓度和迁移率的计算方法。

实验结果表明：

1. 通过霍尔电压的正负成功判断出p型与n型半导体，符合理论预期。
2. 采用对称测量法有效消除了不等位电势和热磁副效应的影响，提高了测量精度。
3. 测得p型霍尔片的灵敏度约为3.23～3.35 V/(A·T)，n型霍尔片的灵敏度约为10.93 V/(A·T)，两者差异反映了载流子类型与浓度对霍尔效应的影响。
4. p型与n型半导体的载流子迁移率分别为0.026 m²/(V·s)和0.902 m²/(V·s)，n型迁移率显著高于p型，说明电子为主要载流子时具有更高的运动能力。
5. 载流子浓度与迁移率的数值在常见半导体参杂迁移率范围内合理；所测得的霍尔电压存在正负号，表示空穴/电流方向与所定义正方向之间的关系。

实验中存在的主要误差来源包括：

1. 霍尔灵敏度与电压测量中的不确定度；
2. 电磁铁磁场的非线性与磁滞效应；
3. 环境温度波动对半导体性能的影响。

为提升实验精度，我的反思与改进：

1. 在测量前充分预热仪器，减少零点漂移；
2. 多次测量取平均值，尤其在切换电流与磁场方向时；
3. 对温度敏感的参数进行实时记录与修正。

本次实验深化了我对霍尔效应物理机制的理解，也锻炼了综合运用图解法与数值法处理实验数据的能力。

五、附录

原版文件地址：通过网盘分享的文件：物理实验报告（电子版）.docx 链接: https://pan.baidu.com/s/1MW_uBSQ9oqL6YHXCbgP7ow 提取码: t3vy

好了，前面说了这么多，下面说说需要准备的东西吧。

首先，你需要准备一个GitHub账号登陆在网页上面，方便操作。最好有一个cloudflare账号，没有也没关系，登陆进去使用邮箱注册一个就好。

之后需要把你自己的域名托管在cf上，后续我会出一个申请免费域名并托管到cf上的教程。

这里附上链接： github： https://github.com

cloudflare: https://dash.cloudflare.com/

然后，如果你电脑上没有代理，你需要在你的edge扩展里面下载并运行ilink,用于加速GitHub（如果你有watt tooltik，可以使用它来加速，效果会更好。但是强烈建议要有一个能加速浏览器的代理，例如ilink,保证你自己好。）

废话不多说准备开干！

第一步就是进入到cloudflare账号界面： 图上可以看到啊我现在有三个域名，其实都是免费申请的，这里只需要任意选择一个就好，当作备用。

之后展开computer&AI选项找到workers&pages，点进去： 点击右上角的创建新项目，之后点击最下面的workers栏start with hello world。 稍等片刻进入设计页面:

点击右上角的Edit code白色方块，这个时候我们要进入甬哥的项目，项目地址我放在下面： https://github.com/yonggekkk/Cloudflare-vless-trojan

选择我圈出来的文件夹，这个时候我们可以看到四个代码，其中有几个已经失效，代码说明我放在下面：

我们选择套壳混淆，进去选择copy，这个时候回到cloudflare代码编辑部份，删掉原来的代码，将我们刚复制的部分粘贴到上面。 点击deploy,成功会出现以下图象。

这时候我们要更改一下uuid，可以直接浏览器搜索uuid生成器，复制。

找到变量与密码这一部分，点击添加，第一栏写uuid,第二栏粘贴上刚复制的uuid。

下面呢我们就开始添加域名，便于我们找到部署的节点链接页面，其实你也可以在Domains & Routes 一栏点击cf自动给你生成的地址进入节点部署链接页面。（进入需要代理） 但是我还是建议自己部署一个域名。

找到Domains & Routes 一栏点击add，添加自己的域名，这里可以再往下面写一级，即在域名前面加上"www." 之类的。 下面我们找到uuid，按照以下格式进入上方搜索框：

”www. 自己的域名/uuid“ 的形式回车，就能看到部署页面啦！

推荐使用clash订阅链接，速度超快，看视频毫无压力！

好了，这个内容就写到这里，如果有相关方面的疑问可以联系我。 欢迎大家批评指正！