https://blog.elephantgris.space/ Gray Space Blog 2026-09-22T00:00:00.000Z Chris Gray Firefly v6.16.8 https://blog.elephantgris.space/posts/8f0fc83d5f501213/ Firefly Obsidian 文章同步功能开发 2026-09-02T00:00:00.000Z 2026-09-22T00:00:00.000Z Chris Gray 以 Obsidian 知识库作为文章唯一内容源，将指定文档单向同步到 Firefly 的文章目录。

需求分析#

博客文章首先在 Obsidian 中撰写，过去一篇文章准备发布时，需要先复制到 Firefly 的 src/content/posts 目录，再把 frontmatter 改写成博客所需的。该流程容易漏掉正文或元数据，或是内容出现更新时需要手动在两侧更新。

解决方案#

基本流程#

改造后的流程只保留一个内容源：

1
Obsidian 中撰写并标记文章
2
              ↓
3
        pnpm sync-post
4
              ↓
5
src/content/posts/<category>/<title>.md

Obsidian 保存可继续编辑的原文，博客目录只保存生成的发布副本。所有待同步文章会先完成字段、slug 和路径校验；检查通过后，缺失的文章被创建，已经存在的文章只有在同步字段或正文发生变化时才会更新。

标记文章和同步博客属于两个不同阶段。

Obsidian 端只负责准备发布元数据。这样可以在写作时决定文章是否发布，并自动填充日期、slug 等过程字段，但不需要知道博客仓库位于哪里，也不负责解释 Astro 的内容结构。

博客端负责扫描、字段转换和文件写入。由博客端脚本统一校验更直接，也避免把博客构建逻辑塞进 Obsidian 端。

两步之间以 frontmatter 为接口：只要源文档满足字段约定，博客脚本就能完成后续工作。

功能设计#

配置知识库路径#

在博客项目根目录配置 .env ，指定 Obsidian 知识库的绝对路径：

1
OBSIDIAN_VAULT_ROOT=/absolute/path/to/Obsidian

标记博客文章#

需要发布的文档使用 blog: true 标记，并维护以 blog_ 开头的博客字段：

1
---
2
blog: true
3
blog_title: Firefly Obsidian 文章同步功能开发
4
blog_description: 以 Obsidian 作为唯一内容源，将指定文档同步到 Firefly。
5
blog_category: 开发
6
blog_published: 2026-09-02
7
blog_slug: 8f0fc83d5f501213
8
blog_series: Firefly 改造计划
9
tags:
10
  - Firefly
11
  - Obsidian
12
---

这些字段可以由 Obsidian 端的 QuickAdd 插件 Macro 调用脚本插入：

1
module.exports = async ({ app }) => {
2
  const file = app.workspace.getActiveFile();
3
  if (!file || file.extension !== "md") {
4
    throw new Error("Please open your note for blog.");
5
  }
6


7
  await app.fileManager.processFrontMatter(file, (frontmatter) => {
8
  frontmatter.blog = true;
9


10
  const defaults = {
11
    blog_title: "",
12
    blog_description: "",
13
    blog_category: "",
14
    blog_published: createBlogPublished,
15
    blog_slug: createBlogSlug,
16
    blog_series: "",
17
  };
18


19
  for (const [key, value] of Object.entries(defaults)) {
20
    if (!Object.hasOwn(frontmatter, key)) {
21
    frontmatter[key] =
22
      typeof value === "function" ? value() : value;
23
    }
24
  }
25
  });
26


27
  new Notice("Blog frontmatter updated!");
28
};
29


30
function createBlogPublished() {
31
  const today = new Date();
32
  const year = today.getFullYear();
33
  const month = String(today.getMonth() + 1).padStart(2, "0");
34
  const day = String(today.getDate()).padStart(2, "0");
35


36
  return `${year}-${month}-${day}`;
37
}
38


39
function createBlogSlug() {
40
  return require("node:crypto").randomBytes(8).toString("hex");
41
}
展开收起

同步博客文章#

scripts/sync-post.ts 的入口只组织四个阶段：完整读取源（Obsidian 端）文章、完整读取目标（Firefly 端）文章、检查两端冲突、按变化写入目标文件。

1
async function main(): Promise<void> {
2
  const vaultRootPath = readVaultRootPath();
3
  await fs.access(vaultRootPath);
4


5
  console.log("Reading source and target posts...");
6
  const sourcePosts = await readSourcePosts(vaultRootPath);
7
  const targetPostsBySlug = await readTargetPosts();
8
  assertNoPostSyncConflicts(sourcePosts, targetPostsBySlug);
9
  await syncPosts(sourcePosts, targetPostsBySlug);
10
}

在博客项目根目录运行：

Terminal window
1
pnpm sync-post

上面的源文档将写入：

1
src/content/posts/开发/Firefly Obsidian 文章同步功能开发.md

目标文章只保留博客需要的 frontmatter，正文则来自源文档：

1
---
2
title: Firefly Obsidian 文章同步功能开发
3
published: '2026-09-02'
4
description: 以 Obsidian 作为唯一内容源，将指定文档同步到 Firefly。
5
category: 开发
6
series: Firefly 改造计划
7
slug: 8f0fc83d5f501213
8
tags:
9
  - Firefly
10
  - Obsidian
11
updated: '2026-09-02'
12
---

扫描带有 Blog 标记的文档#

扫描源（Obsidian 知识库）中的 Markdown 文档，同时跳过 Obsidian 配置和回收站目录：

1
const filePaths = await glob("**/*.md", {
2
  absolute: true,
3
  cwd: vaultRootPath,
4
  ignore: [".obsidian/**", ".trash/**"],
5
  nodir: true,
6
});

源端完整扫描后会分批读取文件，每批最多并行读取 32 个，避免大量云盘文件串行读取时长时间没有响应，也避免一次性并发读取给云盘造成过大压力。读取失败时直接报告具体文件路径。

读取源文档的 frontmatter 和正文，只保留 blog 等于 true 的文档：

1
const matterFile = matter(source);
2
if (matterFile.data.blog !== true) {
3
  continue;
4
}

校验并转换 Frontmatter#

源字段与目标字段存在映射关系，同时应满足相应的校验约束：

Obsidian 字段Firefly 字段约束
blog_titletitle非空字符串
blog_descriptiondescription可缺失或为空
blog_categorycategory非空字符串
blog_publishedpublishedYYYY-MM-DD
blog_slugslug非空并复用博客 slug 规则
blog_seriesseries可缺失或为空
tagstags字符串数组，默认为空数组

源端和目标端的字段名不同，但转换后使用同一个 syncFrontmatterSchema。sourceFrontmatterSchema 只负责校验 blog_* 字段并完成名称映射，后续比较和写入统一使用转换后的结构。

用 Slug 确认身份，用路径确认位置#

title 和 category 可能变化，不能单独作为文章的 ID； slug 是业务无关的，正常情况下不会变更，可以用于确认文章的身份，视为文章 ID，用于关联两端的相同文章。

理论上只有相同文章才会写入同一博客端路径，但原则上不同文章也可以配置出相同的路径（仅与 title 与 category 相关），这可能导致原有文章被覆盖的情况。因此同步前仅检查 slug 还不够，还需要建立反向的路径 -> slug 索引，并按以下规则处理：

源文章与博客文章的关系结果
slug 不存在，目标路径未占用新建文章
slug 相同，目标路径相同原地更新
slug 相同，目标路径不同报错，避免保留两个副本
slug 不同，目标路径相同报错，避免覆盖另一篇文章

写入目标文章#

同步以 slug 关联两端文章，并比较转换后的 frontmatter 和 Markdown 正文。比较时不包含目标文章已有的 updated 字段：

情况写入行为updated
目标文章不存在创建新文章与 published 相同
目标文章存在，内容没有变化不写入文件保留原值
目标文章存在，frontmatter 或正文发生变化使用源文档覆盖更新为同步当天日期

因此重复运行同步命令不会主动覆盖未变化的文章，也不会无故刷新文件修改时间和 updated。发生变化时，博客副本中额外添加但源端没有对应字段的 frontmatter 仍不会保留。

同步完成后输出本次创建、更新和未变化的文章数量：

1
Created: 1, updated: 2, unchanged: 3.
]]> https://blog.elephantgris.space/posts/069ba0f6eb66dbf0/ Firefly 文章 slug 自动生成功能开发 2026-08-30T00:00:00.000Z 2026-09-04T00:00:00.000Z Chris Gray 文章 slug 依赖标题拼音，标题变化后链接容易失配；新增随机 slug 模式，在开发阶段补全缺失值，并在新建文章时按分类与标题创建文件、生成并校验唯一 slug。

需求描述#

当前 Firefly 的文章 slug 仅支持依赖文章标题的拼音转写的生成模式，该模式与文章标题强耦合，文章标题修改会导致其与链接不一致。希望新增一种业务无关的 slug 模式，同时支持自动检测并补全缺失 slug 的文章。

功能设计#

新增 Slug 模式配置#

在文章内容页配置中增加 slug 模式配置项：

1
post: {
2
  slug: "random",
3
}

配置类型同步新增：

1
slug: "pinyin" | "random";

其他模块通过 PostSlugMode 复用该配置项的派生类型，避免再次定义相同的模式范围。

1
export type PostSlugMode = SiteConfig["post"]["slug"];

生成业务无关的随机 Slug#

random 模式使用 Node.js 的 crypto.randomBytes 生成 8 字节随机数，再转换为 16 位小写十六进制字符串。

1
function createRandomSlug(): string {
2
  return randomBytes(8).toString("hex");
3
}

随机值不读取文章标题、正文、分类或路径，因此这些业务内容发生变化时不会影响已写入的 slug。

统一 Slug 校验#

随机 slug 和拼音 slug 的格式不同，因此公共校验只要求 slug 是非空字符串：

1
export const postSlugSchema = z.string().trim().min(1);

文章扫描、新建文章和 Obsidian 文章同步复用同一规则，避免不同脚本分别定义 slug 格式。

setup 生命周期阶段补全 Slug#

通过 Astro Integration 接入配置生命周期：

1
integrations: [
2
  postSlugIntegration(siteConfig.post.slug),
3
]

该 Integration 在 astro:config:setup 阶段检查文章，仅允许 dev 命令写入缺失的 slug：

1
const builtSlugs = await buildPostSlugs({
2
  mode,
3
  write: command === "dev",
4
});

运行 pnpm dev 时，缺少 slug 的文章会生成随机 slug 并写回 frontmatter。已有非空 slug 不会重新生成。运行构建、检查、Astro 同步或预览命令时只进行校验，如果仍有文章缺少 slug ，流程会报错提醒。

创建文章时直接生成随机 Slug#

新建文章命令接收必填的分类和可选的标题：

Terminal window
1
pnpm new-post <category> [title]

标题为空时使用 buildPublishedDate() 生成的发布日期，随后直接以分类和标题生成 src/content/posts/<category>/<title>.md。当前配置为 random 时，新文章会立即得到 16 位随机 slug。写入文件前还会检查该值是否已被其他文章占用：

1
const published = buildPublishedDate();
2
const title = titleArgument || published;
3
const filePath = buildPostFilePath(category, title);
4
const slug = createPostSlug(title, siteConfig.post.slug);
5
await assertPostSlugAvailable(slug);

检查通过后，随机 slug 与其他 frontmatter 字段一同写入新文章，使文章从创建时开始就使用稳定的访问路径。文件名由标题决定，访问路径由 slug 决定，二者互不替代。

]]> https://blog.elephantgris.space/posts/37c1d86c687d3b5f/ Firefly Footer 组件页面置底布局功能开发【已过时】 2026-08-29T00:00:00.000Z 2026-09-14T00:00:00.000Z Chris Gray 短页面的 Footer 会紧跟正文而无法贴近视口底部；通过逐层继承最小高度、调整响应式 Grid 行结构并恢复移动端 Grid 布局，使 Footer 在短页面置底、长页面随内容延伸。

需求描述#

当前 Firefly 中 Footer 组件的高度原本由文章内容决定，文章较短时，Footer 会紧跟正文显示。希望修改为始终保持在当前窗口的底部，使得短页面的 Footer 位于视口底部，长页面的 Footer 仍位于全部内容之后。

功能设计#

传递内容面板的最小高度#

.content-panel 已根据内容顶部位置计算视口内的剩余高度，但由于 .content-panel 与 #main-grid 之间还有一层容器， min-height 不会默认传递给子元素。进而导致 Footer 组件无法利用视口内的剩余空间。因此，需要将最小高度逐层传递到实际负责布局的 #main-grid 。

1
<div class="relative min-h-[inherit] ...">
2
  <div id="main-grid" class="... min-h-[inherit] ...">
  • 第一处 min-h-[inherit]：中间容器继承 .content-panel 的最小高度。
  • 第二处 min-h-[inherit]：#main-grid 继续继承中间容器的最小高度。

这里使用最小高度而不是固定高度，目的是使短页面至少占满视口剩余区域，长页面仍可随正文自然增长。

使用 Grid 分配剩余高度并定位 Footer#

仅让 #main-grid 占满视口剩余高度，还不会自动把 Footer 组件推到底部。普通内容仍会从顶部依次排列，并将多余空间留在 Footer 组件之后。同时，移动端底部组件是可选内容，侧边栏数量也会随页面和配置变化，如果完全依赖 Grid 自动排列，Footer 可能进入用于吸收剩余空间的行。因此，需要同时定义响应式 Grid 行结构，并明确 Footer 在其中的行位置。

1
<div
2
  id="main-grid"
3
  class="... grid-rows-[auto_1fr_auto] md:grid-rows-[1fr_auto] ..."
4
>
5
  ...
6
  <div class={`${footerClassName} row-start-3 md:row-start-2`}>
7
    <Footer></Footer>
8
  </div>
9
</div>

移动端分为三行：正文使用第一行，移动端底部组件或剩余空间使用第二行，Footer 使用第三行。第二行的 1fr 会吸收正文之外的剩余高度，row-start-3 则确保 Footer 始终从第三行开始。

平板和桌面端分为两行：正文与侧边栏使用第一行，Footer 使用第二行。第一行的 1fr 吸收剩余高度，第二行的 auto 仅保留 Footer 实际需要的高度，md:row-start-2 则将 Footer 固定在第二行。

原有的 footerClassName 继续负责 Footer 的列位置。当正文较短时， 1fr 将 Footer 推到视口底部；正文较长时，Grid 随内容增长，Footer 继续排列在完整内容之后。

恢复移动端 Grid 布局#

移动端原有样式将 .mobile-no-sidebar 强制设为 display: block !important，会覆盖 #main-grid 的 display: grid。如果继续保留，前面设置的 Grid 行结构、1fr 和 Footer 行号都会失效。因此，需要删除冲突的 display 声明，并继续保留原有宽度规则。

更新后的移动端样式如下：

1
.mobile-no-sidebar {
2
  width: 100% !important;
3
}

删除覆盖后，移动端的 grid-rows-[auto_1fr_auto]、1fr 和 row-start-3 才能生效，其他移动端宽度设置保持不变。

]]> https://blog.elephantgris.space/posts/339b7202f83f6b9b/ Firefly 头像组件圆形旋转效果功能开发 2026-08-28T00:00:00.000Z 2026-09-04T00:00:00.000Z Chris Gray 侧边栏头像原为静态方形，缺少悬停反馈；通过正方形约束和圆形裁切统一外观，并为内部图片添加悬停旋转与移出归位动画。

需求描述#

Firefly 侧边栏的个人资料头像当前为正方形静态效果，希望改为鼠标悬停时旋转一圈，移开时反向旋转归位的效果。为适配该效果，头像应同步修改为圆形，尺寸也可以有所调整。

功能设计#

自适应圆形头像组件#

src/components/widget/Profile.astro 的头像组件保留响应式最大宽度，增加正方形约束和圆形裁切：

1
class="group block relative mx-auto mt-1 lg:mt-0 mb-3
2
  max-w-36 lg:max-w-48 aspect-square overflow-hidden rounded-full active:scale-95"
  • aspect-square ：容器高度始终等于宽度，即使源图片不是正方形。
  • overflow-hidden rounded-full：将容器及内部内容裁为圆形。

悬停旋转#

1
:global(.profile-avatar-image) {
2
  transition: transform 1s ease-out;
3
}
4


5
.group:hover :global(.profile-avatar-image) {
6
  transform: rotate(360deg);
7
}
  • transform 1s ease-out ：设置动画为一秒，效果为以慢速结束的过渡动画。
  • rotate(360deg) ：旋转 360 度。

该元素为 ImageWrapper 生成的图片包装元素的内部元素，故样式需要使用 :global() 才能命中内部组件 profile-avatar-image 。

]]> https://blog.elephantgris.space/posts/04fe8e2f6415ee6e/ Obsidian Kanban Bases View 卡片排序功能开发 2026-08-21T00:00:00.000Z 2026-08-21T00:00:00.000Z Chris Gray Kanban Bases View 的拖动顺序只能隐式保存，无法写入笔记或供其他视图复用；新增可选 Card order 属性，按序号排序并在同列、跨列拖动后回写连续序号。

需求描述#

Obsidian Bases 可以通过 Sort 设置卡片的查询顺序，但原生 Card 视图不能通过拖动任意调整卡片顺序。

Kanban Bases View 支持拖动卡片，但该顺序无法存储在显式属性或被其他视图复用。

本次开发的目标是在保留原有隐式排序方式的基础上，新增一个可选的 Card order 属性：用户需要可见序号时，将拖动结果写入笔记；不配置该属性时，继续使用原有的隐式配置，不增加笔记字段。

功能设计#

新增可选的 Card order 属性#

在视图设置中新增一个可选属性。未选择时维持原有的 cardOrders 隐式存储；选择后，该属性成为卡片顺序的读取和写入位置。两种模式之间不迁移或清理数据。

1
private cardOrderPropertyId: BasesPropertyId | null = null;
2


3
private loadConfig(): void {
4
  this.cardOrderPropertyId = this.config.getAsPropertyId('cardOrderProperty');
5
}
6


7
{
8
  displayName: 'Card order',
9
  type: 'property',
10
  key: 'cardOrderProperty',
11
  filter: (prop: string) => prop.startsWith('note.'),
12
  placeholder: 'Optional: card order property',
13
}

校验显式属性#

Card order 必须是可写的 note.* 属性，并且不能与 Group by 或 Swimlane by 使用同一属性。否则重新编号可能改变卡片所属的列或泳道，插件会停止渲染并显示配置错误。

1
if (
2
  this.cardOrderPropertyId &&
3
  (!this.cardOrderPropertyId.startsWith('note.') ||
4
    this.cardOrderPropertyId === this.groupByPropertyId ||
5
    this.cardOrderPropertyId === this.swimlaneByPropertyId)
6
) {
7
  this.fullReset();
8
  this.containerEl.createDiv({
9
    text: EMPTY_STATE_MESSAGES.CARD_ORDER_PROPERTY_INVALID,
10
    cls: CSS_CLASSES.EMPTY_STATE,
11
  });
12
  return;
13
}

按显式序号排列卡片#

显式属性接受有限数字和可转换为有限数字的字符串，按数值升序排列。空值和非法值没有显式顺序，统一放在已有序号之后。

1
export function readCardOrderValue(value: unknown): number | null {
2
  if (typeof value === 'number') return Number.isFinite(value) ? value : null;
3
  if (typeof value !== 'string') return null;
4
  const trimmed = value.trim();
5
  if (trimmed === '') return null;
6
  const numeric = Number(trimmed);
7
  return Number.isFinite(numeric) ? numeric : null;
8
}
9


10
export function compareCardOrderValues(a: number | null, b: number | null): number {
11
  if (a === null) return b === null ? 0 : 1;
12
  if (b === null) return -1;
13
  return a - b;
14
}

每个列或“泳道 + 列”单元格分别调用该比较逻辑：

1
private sortCardEntriesByOrderProperty(entries: BasesEntry[]): BasesEntry[] {
2
  if (!this.cardOrderPropertyId) return entries;
3
  return [...entries].sort((a, b) =>
4
    compareCardOrderValues(
5
      readCardOrderValue(a.getValue(this.cardOrderPropertyId)?.toString()),
6
      readCardOrderValue(b.getValue(this.cardOrderPropertyId)?.toString()),
7
    ),
8
  );
9
}

拖动后写回显式序号#

同列拖动后，显式模式不再写入 cardOrders，而是按照当前 DOM 顺序更新选定属性。

1
const paths = getColumnPaths(evt.to);
2
if (this.cardOrderPropertyId) {
3
  await this.writeVisibleCardOrder(paths);
4
} else {
5
  this._prefs.cardOrders[newKey] = paths;
6
  this._persistPrefs();
7
}

写回值使用从 1 开始的连续整数。已有值正确时不重复修改；skipPath 用于跳过已经与分组属性一起写入的跨列移动卡片。

1
private async writeVisibleCardOrder(paths: string[], skipPath?: string): Promise<void> {
2
  const propertyId = this.cardOrderPropertyId;
3
  if (!propertyId) return;
4
  if (!propertyId.startsWith('note.')) {
5
    throw new Error(`Card order property must be a writable note property: ${propertyId}`);
6
  }
7
  if (!this.app?.fileManager) {
8
    throw new Error('File manager not available');
9
  }
10


11
  const propertyName = parsePropertyId(propertyId).name;
12
  const updates = paths.flatMap((path, index) => {
13
    if (path === skipPath) return [];
14
    const entry = this._entryMap.get(path);
15
    if (!entry) throw new Error(`Entry not found for card order: ${path}`);
16
    const order = index + 1;
17
    if (readCardOrderValue(entry.getValue(propertyId)?.toString()) === order) return [];
18
    return [
19
      this.app.fileManager.processFrontMatter(entry.file, (frontmatter: Record<string, unknown>) => {
20
        frontmatter[propertyName] = order;
21
      }),
22
    ];
23
  });
24
  await Promise.all(updates);
25
}
展开收起

跨列拖动新增两步处理：先将移动卡片的新分组值和目标序号写入同一次 frontmatter 更新，再重新编号来源单元格和目标单元格。

1
const cardOrderPropertyName = this.cardOrderPropertyId
2
  ? parsePropertyId(this.cardOrderPropertyId).name
3
  : null;
4
const cardOrder = newPaths.indexOf(entryPath) + 1;
5


6
if (cardOrderPropertyName) frontmatter[cardOrderPropertyName] = cardOrder;
7


8
if (this.cardOrderPropertyId) {
9
  await Promise.all([
10
    this.writeVisibleCardOrder(oldPaths),
11
    this.writeVisibleCardOrder(newPaths, entryPath),
12
  ]);
13
}

允许 Base Sort 下保存拖动顺序#

原实现检测到 Base Sort 后会取消同列拖动，并用 Notice 提示用户清除 Sort。本次移除了 sortActive、hasActiveSort() 和该提示。现在显式属性始终决定卡片顺序；未配置显式属性时，已有的隐式拖动顺序也不再被 Base Sort 跳过。

]]> https://blog.elephantgris.space/posts/fd7c9a19fff336c3/ 蛤诞百年祭 2026-08-17T00:00:00.000Z 2026-08-30T00:00:00.000Z Chris Gray 曾经的我以为，膜蛤会是一辈子的事情。 曾经的我以为，膜蛤会是一辈子的事情。

汇文 2015 闭幕式-1
汇文 2015 闭幕式-1

2015 年在汇文闭幕式上，我第一次看到有关长者的视频，那个时候的我还不懂，为什么上至组委学团，下至代表，都在大谈什么膜法；那个时候我还不懂，为什么大家看着江主席谈笑风生的场面会嘻嘻哈哈，说着什么“提高姿势水平”“这是坠吼的”之类半懂不懂的话；那个时候的我还不懂，原来这就是最后一届汇文中国。

汇文 2015 闭幕式-2
汇文 2015 闭幕式-2

后来我成为了一名成熟的膜法师，并且觉得自己一辈子都会是膜法师。我会熟练地吟诵蛤三篇，尽管现在只会讲两句“跑得快”与“谈笑风生”；我会认真研读《葛底斯堡演说》，尽管现在只记得 “of the people, by the people, for the people”；我会张口“苟利社稷”，闭口“历史的进程”，尽管现在看到评论区的神秘接龙只会淡淡一笑；我会在每年的 817 的时候与《盗墓笔记》十年之约的粉丝们在 QQ 空间里争个你死我活，尽管现在“长白山见”与“长者续命”都已是昨日黄花。

98 年抗洪
98 年抗洪

刚读完《长者传》那会儿，对他的事迹不能说是倒背如流，也可算是如数家珍。精通八国语言、在夏威夷弹吉他、合唱毕业歌、建立社会主义市场经济体制、军队一律不得经商……有迹可循的是，“膜蛤文化”最初也许是对政治人物的某种“戏谑”，但真正能够出圈的，也许就是他的某种个人魅力，也许就是他真的做了一点“微小的贡献”。

你我皆是凡人，没有永生的长者，亦没有一辈子的蛤丝。江能泽民，亦可赛艇，江主席，再见。

]]> https://blog.elephantgris.space/posts/1512e01217fe64c7/ 基于 SSH 反向端口转发的服务器联网代理 2026-08-08T00:00:00.000Z 2026-08-08T00:00:00.000Z Chris Gray 服务器无法直接联网，apt 和 uv 无法更新依赖；通过 SSH 反向端口转发复用本机 Clash 代理，并为 apt 与环境变量配置本地代理端口。

需求描述#

当前服务器本身无法直接访问互联网，但存在稳定的联网下载需求，主要包括以下两类场景：

  1. 使用 apt 更新系统源、安装系统依赖；
  2. 使用 uv 安装 Python、安装项目依赖。

本机具备可用的代理环境，代理软件为 Clash Verge，代理端口为 7897 。因此目标是让服务器通过 SSH 隧道复用本机的代理出口访问互联网。

解决方案#

整体流程#

1
服务器 apt / uv
2
  ↓
3
服务器 127.0.0.1:7897
4
  ↓
5
SSH 反向端口转发
6
  ↓
7
本机 Clash Verge 127.0.0.1:7897
8
  ↓
9
互联网

建立 SSH 反向端口转发#

在本机执行以下命令：

Terminal window
1
ssh -R 127.0.0.1:7897:127.0.0.1:7897 \
2
  user@server_ip

执行 expect 脚本：

1
#!/usr/bin/expect -f
2


3
set timeout -1
4


5
set SSH_USER "root"
6
set HOST "10.130.10.166"
7
set PORT "30412"
8
set PASSWORD ""
9


10
spawn ssh \
11
  -p $PORT \
12
  -R 127.0.0.1:7897:127.0.0.1:7897 \
13
  $SSH_USER@$HOST
14


15
expect {
16
  "*yes/no*" {
17
    send -- "yes\r"
18
    exp_continue
19
  }
20
  -re {.*assword.*} {
21
    send -- "$PASSWORD\r"
22
  }
23
}
24


25
interact
展开收起

测试代理链路#

建立隧道后，在服务器上测试代理是否可用：

Terminal window
1
curl -I -x http://127.0.0.1:7897 https://pypi.org

配置 apt 代理#

在服务器上创建或覆盖 apt 代理配置：

Terminal window
1
sudo tee /etc/apt/apt.conf.d/95proxy > /dev/null <<'EOF'
2
Acquire::http::Proxy "http://127.0.0.1:7897";
3
Acquire::https::Proxy "http://127.0.0.1:7897";
4
EOF

然后执行：

Terminal window
1
sudo apt update

配置 uv 代理#

uv 可以直接使用环境变量中的 HTTP/HTTPS 代理配置。建议写入服务器的 /etc/environment ：

Terminal window
1
cat >> ~/.bashrc <<'EOF'
2


3
export HTTP_PROXY=http://127.0.0.1:7897
4
export HTTPS_PROXY=http://127.0.0.1:7897
5
export ALL_PROXY=http://127.0.0.1:7897
6
export NO_PROXY=localhost,127.0.0.1,::1
7
EOF

然后执行

Terminal window
1
source ~/.bashrc
]]> https://blog.elephantgris.space/posts/e38f2b01a758df66/ Codex TRACE 日志写盘问题修复 2026-07-08T00:00:00.000Z 2026-07-08T00:00:00.000Z Chris Gray Codex 桌面端持续写入大量 TRACE 日志，造成 SQLite WAL 频繁写盘；通过 BEFORE INSERT 触发器忽略 TRACE，保留其他级别日志并支持回滚。

需求描述#

Codex 桌面端会将大量 WebSocket 底层事件以 TRACE 级别持续写入 ~/.codex/logs_2.sqlite。活跃会话中，TRACE 占新增日志的绝大多数，并引发频繁的 SQLite 预写日志（WAL）写入和旧日志清理。

目标是在不影响 INFO、DEBUG、WARN 和 ERROR 日志的前提下停止 TRACE 日志落盘，并确保方案可验证、可回滚。

解决方案#

在 logs 表上创建 BEFORE INSERT（插入前）触发器，仅忽略 TRACE 级日志：

1
CREATE TRIGGER block_trace_logs
2
BEFORE INSERT ON logs
3
WHEN NEW.level = 'TRACE'
4
BEGIN
5
  SELECT RAISE(IGNORE);
6
END;

实施前已备份数据库并通过 PRAGMA quick_check 完整性检查。安装后连续验证未发现新增 TRACE，其他级别日志正常写入，Codex 活跃窗口的进程写入量明显下降。该方案只阻止 TRACE 日志落盘，不会停止上游日志生成；Codex 更新后需确认该触发器是否仍存在。

回滚命令：

Terminal window
1
sqlite3 ~/.codex/logs_2.sqlite "DROP TRIGGER IF EXISTS block_trace_logs;"
]]> https://blog.elephantgris.space/posts/9ab89d31cf793aab/ Obsidian Douban 插件图片上传 PicGo 功能修复 2026-03-27T00:00:00.000Z 2026-03-27T00:00:00.000Z Chris Gray 豆瓣图片因 Referer 校验无法下载，部分 WebP 又无法通过 Electron 剪贴板上传；补充请求头、修正高清图地址、等待剪贴板写入，并在 WebP 解析失败时转为 PNG。

需求描述#

  1. 豆瓣图片访问策略发生变化，访问 doubanio 图片链接时需要附带有效的 Referer 请求头，否则会被拒绝访问。
  2. 插件原有的 PicGo 上传链路依赖系统剪贴板，部分 webp 在写入剪贴板时无法被当前 Electron 运行时直接解析，最终导致上传失败。

功能设计#

图片请求新增 Header Referer#

图片请求时，使用豆瓣条目页地址作为 Referer，并在原有请求头基础上清理不适用于图片请求的字段，保证图片能够正常下载。

高清图地址改为使用远端文件名生成#

高清图地址生成时，不再使用本地附件文件名拼接，而是从原始图片 URL 中提取远端文件名，避免生成错误的高清图地址。

剪贴板写入新增显式等待#

保留原有 PicGo 剪贴板上传流程，仅在上传前显式等待剪贴板写入完成，避免写入未完成时提前上传。

1
.then(async (buffer) => {
2
  if (!buffer || buffer.byteLength == 0) {
3
    throw new Error(i18nHelper.getMessage('130109'));
4
  }
5
  await ClipboardUtil.writeImage(buffer);
6
  return await this.uploadClipboardFile(context);
7
})

Webp 格式图片处理#

仍优先使用原有方式写入剪贴板；仅当 webp 图片无法被 Electron 直接解析时，再通过 canvas 转为 png 后写入，保证对原有逻辑改动最小。

1
private static async createNativeImageFromWebp(data: ArrayBuffer) {
2
  const { nativeImage } = require('electron');
3
  const imageElement = await this.loadImage(URL.createObjectURL(new Blob([data], {type: 'image/webp'})));
4
  try {
5
    const canvas = document.createElement('canvas');
6
    canvas.width = imageElement.naturalWidth || imageElement.width;
7
    canvas.height = imageElement.naturalHeight || imageElement.height;
8
    const context = canvas.getContext('2d');
9
    if (!context) {
10
      throw new Error(i18nHelper.getMessage('130110'));
11
    }
12
    context.drawImage(imageElement, 0, 0);
13
    return nativeImage.createFromDataURL(canvas.toDataURL('image/png'));
14
  } finally {
15
    imageElement.src = '';
16
  }
17
}
展开收起
]]>