使用 Obsidian 搭建个人媒体记录库实际效果：我的媒体库 - 北极星的博客我有个需求挺简单的：看过的动画、电影、书、玩过的游戏，能有个地方统一记下来，最好有个画廊视图能翻看，筛选一下"哪些还没看""哪些评分高"。如果还能自动同步到博客上，就更省事了。于是我在 Obsidian 里搭了一套媒体库系统，顺手写了个同步插件，用下来感觉还不错。这篇聊聊怎么搞的。本地媒体库本身的搭建，主要是参考了这个博主的视频和代码来的：Obsidian如何打造智能图书影视库管理系统，兼顾颜值和实用功能！_哔哩哔哩_bilibili整体思路分两块：Obsidian 本地 — 每种媒体类型一个文件夹，每条记录一个 .md 文件，配合 DataviewJS 写一个画廊概览页，支持筛选、排序、搜索、改状态。同步到博客 — 一个 Obsidian 插件，把本地媒体笔记转成 Typecho 兼容格式，上传图片，推到博客。同时生成一个和本地画廊功能一致的云端画廊页面。架构大概长这样：Obsidian 媒体库 (.md + frontmatter) │ ├─ 本地画廊（DataviewJS，可交互） │ └─ 同步插件 → REST API → Typecho 博客 ├─ 文章（每条媒体一篇） └─ 画廊页（独立页面，纯前端渲染）本地部分：在 Obsidian 里建媒体库文件组织目录结构很简单，按类型分文件夹：媒体库/ ├─ 媒体库概览.md ← 画廊页面 ├─ anime/ ← 动画 ├─ book/ ← 书籍 ├─ movie/ ← 电影 ├─ teleplay/ ← 剧集 ├─ game/ ← 游戏 └─ music/ ← 音乐每条记录是一个 markdown 文件，用 frontmatter 存元数据。以一部动画为例：--- title: 葬送的芙莉莲 type: anime score: 8.8 genre: - 奇幻 - 冒险 tags: - 治愈 - 公路片 datePublished: 2023-09-29 观看状态: 看过✅ 集数: "28" ---不同来源的笔记字段名可能不一样——比如 Douban 插件用 title，Bangumi 插件用 中文名 和 原名。画廊页的脚本做了兼容，会自动映射。画廊概览页这是整个媒体库的门面，基于 DataviewJS 写的。核心功能：筛选栏 — 顶部一排下拉菜单，可以按类型、状态、标签、评分、上映时间、季度、创建时间来筛。所有筛选条件实时生效，状态自动保存到 localStorage，下次打开还在。搜索 — 右上角的搜索框支持多关键词，会在标题、创作者、标签、描述等字段里加权匹配，还能高亮结果。排序 — 按评分、标题、日期升降序，最后一个下拉菜单搞定。卡片网格 — 每条媒体一张卡片，包含：封面图（自动从本地附件或网络 URL 加载）左上角类型图标（🎬🎮📚✨ 一眼分辨）右上角状态标签，点击可以切换（想看 → 在看 → 看过 → 搁置 → 抛弃），自动更新文件 frontmatter左下角发布日期，右下角评分标题（点击跳转到详情页）导演/作者/制作方信息anime 和剧集还会显示进度条（已看/总集数）添加新媒体顶部有个"添加媒体"按钮，点了直接调起 Douban 插件的搜索导入——输入名字就能从豆瓣拉取元数据创建笔记，不用手敲。同步部分：一键推到博客本地记着爽，但有时候想分享，或者想在手机上看。我写了个 Obsidian 插件 media-typecho-sync，配合 Typecho 后端的 RESTful 插件，实现一键同步。同步管理面板点击侧边栏的云上传图标，弹出一个管理面板：面板可以：搜索和筛选 — 按名称搜，按类型/观看状态/同步状态/公开状态筛增量同步 — 只同步本地有改动过的文件（按 mtime 判断）强制同步 — 勾选指定条目强制推送，或者全量重推预览变更 — 先看看哪些文件会被同步，确认无误再推逐条设置公开状态 — 每条媒体可以独立设为公开/隐藏/私有删除已选 — 从云端删掉已同步的文章重建画廊 — 只更新画廊页，不动文章同步过程做了什么点击同步后，插件会：测试连接 → 扫描本地媒体库 → 对比缓存，找改动上传新图片（DJB2 内容哈希去重，同一张图不会传两次）转换格式：Wiki 链接 [使用Obsidian搭建个人媒体记录库](https://blog.polaris2333.top/index.php/archives//) → 普通链接、Callout 块 → HTML、DataviewJS → 静态内容通过 REST API 创建/更新文章，附上封面、摘要、标签、分类重建云端画廊页整个过程在面板底部有实时进度，出错了也一目了然。格式转换要点Obsidian 的笔记语法和 Typecho 的 Markdown 解析不太一样，插件在推送前会自动处理：Obsidian 语法转换结果![[xxx.jpg]]![xxx](远程URL)（图片已上传）别名[别名](博客文章链接)> [!info] 标题 ... `= this.score` frontmatter 对应字段的值dataviewjs 代码块静态 HTML（集数列表、描述等）ep-box 集数标记内联样式（紫色=已看，深灰=未看）云端画廊同步后博客上会自动生成一个独立画廊页面，和 Obsidian 里的体验基本一致——筛选、排序、搜索、卡片展示都在，只是不能修改状态（毕竟是静态页面，没 Obsidian API）。一些细节设计差异检测三种模式：正常模式按 mtime 增量同步；强制模式全量重推；白名单模式只同步选中文件——改了一条笔记只想推这一条，没问题。图片去重双层保险：先按路径匹配缓存，再按 DJB2 内容哈希匹配。同一张图在不同笔记里引用多次，只传一次。集数追踪：anime 的集数数据来自 Bangumi 模板的 ep-box，统计 data-status="2"（已看标记）的数量生成进度条。剧集类也是同理。跨插件兼容：画廊脚本同时兼容 Douban 插件和 Bangumi Sync 插件创建的文件，字段名不同也能正常显示。需要准备什么Obsidian 这边：Obsidian ≥ 1.5.0Dataview 插件（画廊页的核心依赖）Douban 插件或 Bangumi Sync（用来导入元数据，可选但推荐）Typecho 这边：RESTful 插件（提供 API）Butterfly 主题（推荐，画廊和自定义字段支持最好）最后这套方案我从自己用着顺手出发，一点点补齐了筛选、进度、同步、管理面板这些功能。用"Obsidian 做本地数据库 + 画廊做可视化 + 插件做发布"的思路，把记录和分享串起来了。插件代码和 RESTful 后端都在 GitHub 上开源了，有兴趣可以看看。有更好的想法也欢迎交流。bluemoon23333/media-typecho-sync: 将obsidian的媒体库页面同步为typecho的一个独立页面的插件
像打游戏一样管理人生——用 Obsidian 搭建个人 OKR 系统前言去年某天，我在 B 站刷到了这样一个视频：都2026了，你还不会用 Obsidian？(终极教程)在此之前，我对 Obsidian 的认知仅仅是"一个有点极客的笔记软件"。我也是从这个视频开始正式使用obsidian的。然后最近看到了这个视频：像打游戏一样科研真的可行吗？我在 Obsidian 里搭了一个万年历系统这个视频提出了一个让我瞬间心动的概念：把人生当成一个 RPG 游戏来经营。每年是大章节，每季度是主线任务，每月是项目进度，每周是具体执行，每天是经验获取。于是，我花了几天时间，在 Obsidian 里搭建了一套完整的个人 OKR 系统。这篇文章，就是我这个系统的完整搭建过程的记录。一、整体架构：从年到天的五层金字塔我的 OKR 系统遵循一个自顶向下的层次结构：年度 OKR（目标愿景） ↓ 季度 OKR（阶段性目标） ↓ 月度 OKR（具体项目及进度） ↓ 周度 OKR（具体执行计划） ↓ 每日日记（时间记录 + 经验值获取）每一层都通过 Obsidian 的 Wiki-link 互相串联，形成一个闭环：年度笔记通过 ![[月度笔记### 核心事项]] 汇总全年十二个月的核心进展季度笔记引用年度核心目标，并嵌入该季度三个月的回顾月度笔记嵌入四周的周记推进情况和反思周度笔记嵌入七天的每日总结和小确幸每日日记中嵌入本周 OKR 计划板，做到"每日都清楚自己该做什么"这个结构看起来很复杂，但实际上在 Obsidian 中只需要一套模板就能自动生成。下面我们逐步拆解。二、日历基础：插件与模板2.1 推荐的日历插件首先是日历显示，我推荐使用 Chinese Calendar 插件：DevilRoshan/obsidian-lunar-calendar这是一个更符合中国用户习惯的日历插件，支持农历显示和节假日标注，比原生日历好用很多。然后是 Periodic Notes 插件，它可以配合模板，在创建每周/每月/每季度/每年笔记时自动调用对应的 Templater 模板来生成内容。这是整个系统得以运转的基石——你不需要手动写一堆东西，只需要点一下按钮，对应周期的笔记就自动生成了。2.2 热力图：把经验值可视化经验值是一个数字，单独看没什么感觉。但如果能像 GitHub 的 Contribution 图一样，把每天的经验值变成一个色块，那就能直观地看到自己这一年的状态起伏。我用的是这个插件：vran-dev/obsidian-contribution-graph它在笔记中嵌入一个 contributionGraph 代码块，读取所有日记页面中的"经验值"属性，生成热力图。我把它放在了年度、季度、月度、周度四个层级的笔记顶部，从不同粒度来审视自己的状态。热力图的配置大概是这样的（放在年度笔记中）：title: 年度经验值热力图 graphType: default dataSource: type: PAGE value: "#日记" dateField: type: FILE_NAME format: yyyy-MM-DD countField: type: PAGE_PROPERTY value: 经验值 cellStyleRules: - id: Ocean_a color: "#cae7ecff" min: "1" max: "20" text: 😅 - id: Ocean_b color: "#adccecff" min: "20" max: "30" - id: Ocean_c color: "#8ea6c8ff" min: "30" max: "40" - id: Ocean_d color: "#5d81a1ff" min: "40" max: "50" - id: Ocean_e min: "50" max: "70" color: "#21537fff" - id: Ocean_f min: "70" max: "1000" color: "#04234bff" text: 🥳颜色从浅蓝到深蓝，分数越高颜色越深。每天看一眼，就知道自己这段时间每天的一个状态是怎么样的。三、模板系统：用 Templater 实现自动化Obsidian 自带的 Templates 插件功能有限，核心的模板引擎我使用的是 Templater 插件。它能执行 JavaScript 代码，实现日期计算、变量提取、条件判断等高级功能。具体的模板相关的内容，想了下还是不赘述了，都是比较细碎的一些内容。况且这种模板只适合自己使用，就不放出来了，后面可能会考虑上传到github的仓库，有感兴趣的可以到我的github仓库去查看。四、核心灵魂：经验值评分系统好了，前面都是"基础设施"。真正让这套系统从"普通的 OKR 管理"变成"像打游戏一样管理人生"的，是这套经验值评分系统。4.1 设计理念这套评分系统不是为了给每一天"打分"——高分不代表"今天过得很爽"，低分也不代表"今天是糟糕的一天"。它的核心目标是：客观量化今天有没有向前走。你可能会想：我今天刷了 8 小时短视频，但我很开心啊，为什么不能给高分？答案很简单——因为这套系统的评分规则是你自己定义的。如果你想成为一个更健康、更高效的人，那就把"健康作息"和"专注工作"设计成高分项。如果你觉得娱乐也同样重要，那就给娱乐设计一个合理的曲线。规则是活的，但一旦定下来，就严格客观执行，不给自己的偷懒找借口。这其实借鉴了游戏设计中的一个核心概念：经验值不等于快乐值，经验值等于成长值。4.2 评分维度总览总分由六个维度组成：维度标准分核心逻辑睡眠质量20入睡时间 + 睡眠时长的双 sigmoid 曲线积分工作学习60时长 S 曲线：太少低分，适中高分，超量收益递减兴趣爱好15有工作基础后加分，纯娱乐不加分，过度递减时间记录完整度5记录越完整分越高，允许 2 小时琐事不记录自我评估10用户自己对今日事项推进的主观评价习惯打卡~10完成已勾选的习惯累计得分总分约 100 分，但各维度都是"标准分"，实际分数可以超过。4.3 时间记录：柳比歇夫时间记录法在讲评分算法之前，必须先讲数据来源——时间记录。我采用的是柳比歇夫时间记录法，简单来说就是：把一天中每个时间段做了什么，诚实地记录下来。格式如下：09:00-12:00 【工作】 [项目A][重要] 14:00-15:30 【学习】 [课程B] 16:00-17:30 【运动】 23:00-07:00 【睡觉】格式：HH:MM-HH:MM 【事件名称】标签是可选的，用 [标签名] 表示，紧跟在事件下一行跨午夜的事件（如睡眠）会自动处理记录放在每日日记的「今日时间记录」板块下。每天睡前花 5 分钟回顾一天，填入时间记录，然后点击插件的星星按钮，一键计算今天获得了多少经验值。4.4 评分算法详解4.4.1 睡眠评分：你睡对时间了吗？睡眠评分的核心思想是：不仅要睡得够，还要睡在对的时间。我设计了一个双 sigmoid 函数来刻画"最佳睡眠窗口"：$$ \text{sleepCurve}(x) = 1 + \frac{9}{1 + e^{-5.0(x - 0.50)}} - \frac{9}{1 + e^{-6.0(x - 9.75)}} $$其中 $x$ 是当天的时间（以小时计，0-24）。这个函数在凌晨 0:30 到早上 9:30 之间取值最高（约 10），在其它时间段迅速衰减到接近 1。计算方法：从时间记录中筛选出标记为"睡觉"的事件将这些事件的时间区间进行合并（处理白天补觉等碎片化睡眠）对每个睡眠区间，用辛普森积分法（n=2000 子区间）计算 sleepCurve 下的面积除以"标准睡眠区间"（0:30-9:30）的积分面积，得到比例最终得分 = 睡眠标准分 × 比例这意味着：如果你从晚上 11 点睡到早上 7 点（8 小时，但部分时间在曲线高分区外），得分大概在 16-18 分如果你从凌晨 4 点睡到中午 12 点（同样 8 小时，但全在低分区），得分可能只有 5-8 分如果你的睡眠碎片化严重（多次小睡），合并后也无法拿到高分这个设计非常关键：它不是在惩罚"睡得少"，而是在奖励"睡得规律"。4.4.2 工作学习评分：拒绝内卷，也拒绝摸鱼工作学习时长评分采用另一个 S 型曲线：$$ \text{workCurve}(x) = 7 + \frac{3}{1 + e^{-1.95(x - 2.40)}} - \frac{10}{1 + e^{-3.30(x - 8.49)}} $$这个设计明确传达了一个信号：每天高效工作 6 - 7 小时是最优解，再往上拼命，收益微乎其微，不如去好好休息、发展兴趣。4.4.3 兴趣爱好评分：先完成正事，再享受生活兴趣爱好的评分有一个独特的前置条件：必须先满足工作学习的最低标准。曲线函数（经平移后）：$$ \text{hobbyCurve}(x') = 10 + \frac{2}{1 + e^{-7.12(x' - 0.75)}} - \frac{12}{1 + e^{-9.42(x' - 2.49)}} $$其中 $x' = x$（兴趣时长）。关键机制是工作系数：$$\text{coefficient} = \begin{cases} 1, & \text{工作小时} \geq 6 \\ \frac{\text{工作小时}}{6}, & \text{工作小时} < 6 \end{cases}$$最终分数 = 标准分 × 兴趣曲线积分比例 × 工作系数。这个设计背后的逻辑是：兴趣爱好是人生的调味剂，但不是主菜。在完成该做的事情之后去享受爱好，是值得鼓励的；而逃避正事钻进爱好里，就不应该获得高经验值。4.4.4 时间记录完整度：诚实面对自己这个维度很简单但很重要：$$\text{得分} = \text{标准分} \times \frac{\text{已记录小时数}}{24 - \text{允许琐事小时数}}$$默认允许 2 小时的琐事时间（上厕所、吃饭、发呆等）不需要精确记录。如果你记录了 22 小时，就拿到满分。如果只记录了 12 小时，就只能拿到约一半的分。这个设计鼓励你尽可能完整地记录时间。因为诚实是自我管理的第一步——你无法优化你看不见的东西。4.4.5 自我评估：你对自己今天的推进满意吗？这个维度不需要算法，完全由用户自己填写。在日记的 YAML 前置元数据中，有一个 自我评分 字段：自我评分: 8你根据自己的感受，给今天的事项推进情况打一个主观分。这是对客观数据的补充——有时候一天下来没做什么"工作学习"，但你可能完成了一件困扰很久的事情，或者做了一个重要的决定，这些无法被时间记录捕捉的价值，就通过自我评估来体现。4.4.6 习惯打卡：小习惯，大积累每日日记模板中有一个 Callout 块：> [!success] 习惯打卡 > - [ ] 习惯1 🍭3 > - [x] 习惯2 🍭1插件会解析这个 Callout 块：找到所有 - [x]（已勾选）的习惯识别每行中 🍭 后面的数字累加所有已勾选习惯的分数五、自制插件：一键计算经验值上一节讲了评分算法，但它们不可能手动计算。为此，我vibe coding 了一个 Obsidian 插件，专门用来解析日记中的时间记录并自动计算经验值。5.1 插件功能概览插件名为「每日经验值计算」（Daily Exp Score），开源在：bluemoon23333/my-obsidian-plugins核心功能：一键计算：点击 Ribbon 栏的星星图标或执行命令「计算今日经验值」自动解析：从日记中提取时间记录板块，解析时间事件关键词匹配：根据设置中的关键词，将事件分类为睡眠/工作学习/兴趣爱好六维评分：分别计算六个维度的分数，汇总后写入日记的 YAML 前置元数据Notice 展示：以弹窗形式展示各维度得分明细具体的实现逻辑就是依照前面的分数加成的逻辑来的，就不进行赘述，基本上就是直接把需求和完整的逻辑设计都给AI就行了六、段落级标签聚合：让碎片化思考不再沉没这是我在搭建这套系统时解决的一个很实际的痛点。6.1 问题每天写日记时，经常会在某个时刻写下一些有价值的思考或重要的事件记录。比如：今天突然想明白了一个道理：拖延的本质不是懒，而是对失败 的恐惧。与其等待完美的时机，不如先做 5 分钟看看。 #关键思考但是，日记一天接一天地积累，几个月后你已经有了上百篇日记。你根本不可能回头去一篇一篇翻看，那些曾经闪光的思考就这样沉没在了日记的海洋里。6.2 解决方案我的做法是：用一个特定的标签标记重要的段落，然后在月度/年度笔记中用 Dataview 自动聚合。在月度 OKR 模板中，我放置了这样一段 DataviewJS 代码：// ===== 配置区域 ===== const folder = "生活/OKR/日记"; // 日记文件夹 const fileTag = "2026/07"; // 按月份标签筛选 const keyTag = "关键思考"; // 段落中的标签 let pages = dv.pages(); // 按文件夹筛选 if (folder) { pages = pages.where(p => p.file.path.startsWith(folder + "/")); } // 按文件标签筛选 if (fileTag) { const fullTag = "#" + fileTag; pages = pages.where(p => p.file.etags && p.file.etags.some(t => t === fullTag)); } let total = 0; for (const p of pages) { const tfile = app.vault.getAbstractFileByPath(p.file.path); if (!tfile || tfile.extension !== "md") continue; const content = await app.vault.cachedRead(tfile); const lines = content.split("\n"); const matches = lines.filter(line => line.includes(`#${keyTag}`)); if (matches.length > 0) { dv.header(3, p.file.link); for (const line of matches) { const cleaned = line.replace(new RegExp(`#${keyTag}`, "g"), "").trim(); if (cleaned) dv.paragraph(cleaned); } total += matches.length; } } if (total === 0) { dv.paragraph("未找到包含 #" + keyTag + " 的段落。"); }核心思路：限定搜索范围（日记文件夹 + 文件级月份标签如 #2026/07）遍历所有匹配的日记文件逐行扫描，找到包含 #关键思考 的行去掉标签后，将段落内容展示在月度笔记中在月度笔记中，同样的代码复制了三份，分别聚合 #关键思考、#兴趣发展 和 #人际变化 三个维度。这样当你打开月度 OKR 笔记时，当月的所有重要瞬间就自动呈现在眼前了。6.3 为什么不用 Block Reference？你可能会问：Obsidian 不是有 Block Reference 吗？为什么不直接 ![[日记^block-id]] 引用？原因是：手动维护 Block ID 太累了。每天写日记时你要记住给重要的段落手动加上 ^block-id，还要确保不重名，时间一长几乎必然放弃。而 #标签 就自然得多——写下思考时顺手敲一个 #关键思考，零额外心智负担。八、写在最后搭建这套系统花了我不少时间，最大的变化不是"效率提高了多少"，而是我对自己的成长有更确切的感知。以前"工作了一整天"可能只是感觉，现在打开热力图一看，那天经验值 25 分——说明其实大部分时间都在摸鱼。以前觉得"这周状态很差"，打开周记一看，其实完成了不少事情，只是最后两天有点松懈而已。相关资源插件源码与说明：bluemoon23333/my-obsidian-pluginsChinese Calendar 插件：DevilRoshan/obsidian-lunar-calendarContribution Graph 插件：vran-dev/obsidian-contribution-graph入睡灵感视频：都2026了，你还不会用 Obsidian？(终极教程)核心灵感视频：像打游戏一样科研真的可行吗？
前言我记笔记的方式比较懒散：想到什么写什么，写完了再想着整理。但整理这件事本身很费脑子，尤其是两件事让我特别烦。一是我用 Obsidian 配合 Typecho 写博客，每篇文章前面都要填 frontmatter：aliases、分类、tags、概述 这些字段。每次发文前我都得自己盯着空字段想：这篇文章该归到哪一类？tags 怎么取才合适？概述一句话怎么说清楚？填一次还好，文章多了之后，每次都要重新动脑，真的很累。二是看视频学习的时候，我习惯把字幕或者逐字稿复制下来，再整理成笔记。但网上常见的提示词模板大多是通用型的，不是偏重知识类就是偏重新闻类，跟我实际看的视频类型对不上。每次都要改提示词、删不需要的模块、调整输出格式，最后整理出来的笔记还是不尽人意。所以我干脆做了两个 Skill：一个叫 fill-frontmatter，一个叫 video-note。fill-frontmatter：让 frontmatter 自己长出来这个 Skill 的想法很简单：我把文章丢给它，它帮我分析全文主题，然后把空的元数据字段填上。它不会乱填。执行的时候，它会先扫描文章的所有小节标题，给每个小节提取几个关键词，再把这些关键词汇总成主题清单。然后根据主题清单去匹配或生成 aliases、分类、tags、概述。如果某个字段本来已经有值，它就不会覆盖。我比较喜欢它的一点是，它会优先参考我已经在 Typecho 里建好的分类和标签，不会每次都给我造一套新的体系。这样我的笔记库和博客站点的分类标签能保持一致，后面找东西也方便。另外，像 banner、slug、保护密码 这种需要人工判断或包含敏感信息的字段，它会主动跳过，不会自作主张。video-note：把视频文案变成能看的笔记video-note 解决的是另一个问题：视频内容太杂，通用提示词不够用。我在设计它的时候，把视频内容分成了五种类型：知识类、资讯类、故事类、技能/教程类、观点/评论类。每种类型对应一套不同的笔记生成策略。比如知识类会梳理概念、补充术语解释；教程类会拆解步骤、标注注意事项；观点类会提炼论点、梳理论据和反方视角。如果视频同时包含几种类型，它也能处理：先判断主类型，再把次要类型里的一两个核心模块融合进来，并在笔记开头标注这是混合类型。输出格式我也固定下来了：最前面是折叠起来的完整原文，后面才是整理好的笔记正文。这样我既能快速看到重点，又保留了原始素材，以后想回看原文也不会丢。怎么使用这两个 Skill 都是围绕我的 Obsidian 工作流来用的，但用法略有不同。fill-frontmatter 需要先运行一个辅助脚本 get-metas.mjs，从 Typecho 站点拉取已有的分类和标签列表。然后在 Obsidian 里打开要发布的文章，调用 Skill，它会把分析结果填充到 frontmatter 里。填完之后我会快速扫一遍，确认分类和 tags 没问题就完事。video-note 更偏提示词。我在 Obsidian 里新建一个笔记，把视频文案贴进去，然后调用对应的提示词。它会先判断视频类型，再按类型输出结构化的笔记，最后直接写回当前文件。两个都不需要我去记复杂的操作流程，核心目标都是一致的：减少重复思考，让我把精力放在内容本身。最后做这两个 Skill 是觉得笔记工作流里有些步骤本来就不该消耗那么多注意力。填 frontmatter、整理视频笔记这些事情，交给一个稳定的规则去做，比每次自己临时想一遍要轻松得多。如果你也有类似的烦恼，也许可以试试看。不是照搬我的做法，而是想想自己笔记流程里有哪些步骤是重复、机械、却又不得不做的，把它们固化成规则，后面会省很多事。
自动化将Obsidian的笔记同步到typecho的方案开发
从「找到合适的发布插件」到「干脆自己改一个」，记录如何让 Obsidian 里的笔记在保存时自动同步到 Typecho 博客，并在这个过程中把通信协议、字段映射、自动推送和图片上传逐一重构。起点：为什么想要一套笔记到博客的同步方案我的笔记和博客长期分属两个系统。Obsidian 负责日常记录、整理和输出，Typecho 负责把成稿发布出去。理想状态下，写完一篇笔记后，应该只需点一下按钮或者保存文件，文章就出现在博客上。如果后续修改，博客上的版本也应该跟着更新，而不需要再登录后台复制粘贴。这个需求听起来并不复杂，但要把体验做得顺畅，涉及几个问题：发布动作要简单、更新要自动、图片等附件要正确上传、Frontmatter 元数据要能控制文章的标题、分类、标签、状态等字段。再加上一些个人偏好，比如用文件名做标题、用中文命令触发、保存后自动推送，现成的方案很难一次性满足。于是我开始在 GitHub 上找相关项目，最终锁定了两个基础仓库作为二次开发的起点。对现有的Obsidian同步到typecho插件的对比可以看这篇文章：三款 Obsidian-Typecho 同步插件横向对比分析两个原项目obsidian-typecho-publisher：已有的 Obsidian 发布插件skyue/obsidian-typecho-publisher 是一个相对成熟的 Obsidian 插件，功能架构很清晰：通过 XML-RPC 协议与 Typecho 通信，支持读取 Frontmatter、上传图片、转换 Wiki-Link、截断内容，并把文章发布或更新到博客上。插件内部有 PublishService、XmlRpcClient、设置面板、i18n 等模块，整体结构对我非常有参考价值。它的核心流程大致如下：flowchart TB A[Obsidian 笔记文件] --> B[解析 Frontmatter] B --> C[图片上传] C --> D[Wiki-Link 转换] D --> E[内容截断] E --> F[剥离 Frontmatter] F --> G[XML-RPC 发布/更新] G --> H[回写 typecho_postid]但在实际测试中，我发现两个关键问题：一是每次更新文章都会新建一篇，无法实现真正的「更新」；这个问题排查了很久，但都找不到为什么，怀疑是 Typecho 服务端 XML-RPC 的实现存在问题。既然服务端肯定要动，那不如把通信协议一并换掉，从 XML-RPC 迁移到 RESTful API。typecho-plugin-Restful：Typecho 的 RESTful 插件Chen2226/typecho-plugin-Restful 提供了一个 Typecho 的 REST API 扩展，包含文章、页面、分类、标签、评论、文件等端点。它正好可以作为新的服务端基础，让我不用再从零写 API 路由和鉴权。不过原版的端点和字段设计比较通用，并没有针对 Obsidian 发布场景做专门优化。例如文章发布接口只支持 title、text、slug、mid 等少量字段，匹配策略是「slug 优先、title 回退」，没有 cid 精确匹配，也没有状态、密码、评论开关、封面图、摘要等字段。因此服务端也需要做比较大的改动，才能配合新的 Obsidian 插件工作。需求梳理与方案取舍在开始写代码之前，我把需求分成三层：必须有的基础功能、希望优化的体验、未来可能做的扩展。基础功能对 Obsidian 中的单篇笔记执行发布，自动推送到 Typecho。保存文件后自动检测变化并同步更新。本地图片和附件上传到博客，博客正文中的相对路径替换为远程 URL。体验优化用文件名作为文章标题，而不是从 Frontmatter 的别名字段读取。评论开关用 Frontmatter 中的布尔值控制。支持封面图、文章摘要、slug 自动回填、公开状态修改、访问密码、分类与标签自动创建等。标题不一致时二次提醒，避免意外覆盖其他文章。扩展想法通过 AI 快速生成标签元数据。（后面打算通过编写一个skill来实现）从头图或图库中自动选择封面图，不用每次手动去复制图片链接。娱乐影音阅读管理类的特殊页面同步。关于附件管理，我一开始想联动自托管的 obsidian-fast-note-sync 服务，让图片由同步服务管理，博客只引用链接。但这两个服务本身没有为这种场景设计，不修改源码很难打通。权衡之后，还是选择最稳妥的方案：图片随文章一起上传到 Typecho 作为附件。二次开发的整体思路最终方案是「保留 obsidian-typecho-publisher 的交互流程和业务逻辑，把底层通信协议从 XML-RPC 换成 RESTful，再补齐两端缺失的字段和能力」。也就是说，Obsidian 端的用户操作、设置面板、发布流程基本沿用原有设计，但 XmlRpcClient 被完全替换为新的 RestfulClient；Typecho 端则在 Restful 插件基础上扩展发布接口、上传接口和后台配置。flowchart LR subgraph Obsidian O1[main.ts] --> O2[PublishService] O2 --> O3[RestfulClient] end subgraph Typecho T1[Plugin.php] --> T2[Action.php] T2 --> T3[postArticle] T2 --> T4[upload] T2 --> T5[fileList] T2 --> T6[deleteFile] end O3 -.->|JSON REST API| T1下面分别记录服务端和客户端的具体改动。服务端改造：typecho-plugin-Restful服务端基于 Chen2226 的 Restful 插件，版本号升级到 1.3.0。最大的改动是 postArticle 接口的重构，其次是上传接口和后台配置面板。文章发布接口的三级匹配策略原版接口用 slug 或 title 匹配文章，在高频修改场景下容易出错。我把它改成三级回退：如果请求里带了 cid 且大于 0，优先按 cid 精确查询并更新。cid 未命中时，按 authorId + slug 查询。都未命中则新建文章。这样只要 Obsidian 端在 Frontmatter 中保留了 cid，后续更新就不会因为标题或 slug 的变化而错改到其他文章。新增和扩展的字段发布接口从只支持少量字段，扩展为支持完整的文章元数据：字段说明cid文章 ID，0 或未匹配到文章时新建；正整数时优先按 cid 匹配，未命中可回退 slug 匹配created自定义发布时间，Unix 时间戳banner封面图 URL，写入自定义字段 thumbdescription文章摘要 / SEO 描述statuspublish / hidden / password / private / waitingpassword访问密码，仅在 status=password 时生效allowComments0 关闭评论，1 允许评论mid分类 / 标签 ID返回值也做了语义化，例如 {"cid": 45, "type": "add", "slug": "my-post"}，让 Obsidian 端能明确知道是新增还是更新，并回写 slug。上传接口的多格式兼容为了让 Obsidian 插件能以不同方式上传图片，上传接口通过新增的 Util.php 支持三种格式：标准的 multipart/form-data 文件上传。JSON 中的 Uint8Array 字节数组，通过 pack('C*', ...$bytes) 还原为文件。Base64 字符串，包括 data:*;base64,xxx 和纯 base64 两种形式。新增文件管理接口除了上传，还增加了 /api/deleteFile 删除附件、/api/fileList 分页获取附件列表，以及 /api/upgrade 插件自更新接口，方便在后台一键检查并拉取最新代码。CORS 与鉴权调整原版 CORS 要求 Origin 在白名单内，否则不返回 Access-Control-Allow-Origin。但 Obsidian 插件作为非浏览器客户端，通常不会携带 Origin 头。我改成：无 Origin 头时自动允许 *，有 Origin 头时再按白名单校验。这样既保留浏览器的安全限制，又让 Obsidian 客户端能直接调用。鉴权方面，高敏接口默认通过 apiToken 校验，并允许关闭登录校验，让纯 Token 认证场景更易用。后台配置面板的小调整服务端插件的配置面板原本已经比较完整，包含 API 状态开关、CORS 域名、字段隐私过滤、设置项白名单、CSRF 盐值、API Token、高敏接口登录校验以及一键升级按钮。每个 API 开关的说明来自代码注释的中文翻译，并会显示对应的端点路径，例如 GET /api/posts。我主要在这个基础上增加了一个 Butterfly 主题检测提示：检测到 Butterfly 时显示绿色提示，未检测到时显示黄色提示并说明摘要会通过 方式实现。这样用户在配置时就能直观知道 description 字段会如何存储。客户端改造：obsidian-typecho-publisherObsidian 端基于 skyue 的插件，版本号升级到 2.0.0。核心变化是通信协议替换、字段映射调整和自动推送机制的增加。通信协议：XML-RPC → RESTful我删除了 xmlrpc-client.ts，新增 restful-client.ts。新的客户端通过 JSON 与 Typecho 通信，主要调用以下端点：端点用途POST /api/postArticle发表或更新文章POST /api/upload上传图片，使用 base64 JSONGET /api/categories获取分类列表GET /api/tags获取标签列表POST /api/addMetas自动创建缺失的分类或标签GET /api/userList获取用户列表，自动填充 authorIdGET /api/post获取文章详情，用于标题比对POST /api/deleteFile删除附件连接配置与字段映射设置面板删除了 xmlrpcUrl、username、password，改为 apiUrl、apiToken、authorId。authorId 旁边加了「获取用户」按钮，可以自动填充。Frontmatter 字段名也做了统一：原版的 typecho_postid 改为 cid，更符合 Typecho 本身的命名习惯。发布成功后，cid 和 slug 会自动回写到 Frontmatter。标题取值与标题不一致提醒新增 useFilenameAsTitle 选项，开启后文章标题直接取文件名，忽略 Frontmatter 中的 title 和正文第一个 # 标题。关闭时则按「Frontmatter → 正文第一个标题 → 文件名」的优先级取值。另一个安全机制是「标题不一致提醒」：当 cid > 0 且手动推送时，插件会先获取云端文章标题与本地比对，如果不一致会弹窗确认，避免 cid 被意外修改后覆盖到别的文章。自动保存推送这是本次改动里最实用的功能之一。文件保存后，插件会在 3 秒防抖后自动推送。为了避免无意义的重复发布，我加了几个保护：基于 DJB2 哈希对比文件内容，内容没有实质变化时跳过。记录 cid 变化，如果发现 Frontmatter 中的 cid 被改成本地不存在的值，停止自动推送并通知用户。用 autoPublishRunning Set 做并发保护，同一文件不会同时被推送多次。因回写 cid/slug 触发的保存会被识别并跳过。图片上传重构图片上传从 XML-RPC 的 newMediaObject 改为 POST /api/upload。缓存策略从「基于 Vault 相对路径」改为「基于文件内容哈希」，相同内容的图片不会重复上传。上传失败时不会阻断整篇文章的发布，而是弹出单张图片的失败通知并继续处理其余图片。同时也保留了 Cloudflare R2 图床的支持，通过 AWS Signature V4 计算签名，适合想把图片放到独立存储的场景。内容截断重写原版内容截断只能匹配 1-3 级标题，且逻辑比较粗糙。我重写了 markdown-utils.ts 中的截断函数，支持 1-6 级所有标题，并只移除匹配标题及其子内容，后续内容保留。这样可以在发布时去掉某些仅在本地使用的章节，而不影响正文其余部分。Wiki-Link 转换与 i18nWiki-Link 转换现在会排除图片链接 !...，只对普通双链 [[...]] 做替换。其实wikilink转换最好是在Obsidian笔记库里面本身完成统一，而不是上传的时候让插件来转换，目前我的笔记库中的所有链接统一使用markdown格式。设置面板、命令面板、右键菜单等处的触发文字统一改为中文「推送到 Typecho」。i18n 字符串表也做了相应更新，移除 XML-RPC 相关文案，增加 RESTful、自动推送、封面图、摘要、状态、密码、评论开关等新文案。摘要与 SEO 描述字段的透传如果 Frontmatter 中填写了 description 字段，插件会把它同时作为文章摘要和 SEO 描述发送给服务端；如果没有填写，则传空值，不会根据正文自动生成摘要。这个功能只是把用户已经写好的描述同步到博客上，而不是替用户生成。服务端会根据是否安装 Butterfly 主题 做不同处理：检测到 Butterfly 时，把 description 写入 summaryContent 和 desc 等独立字段；未检测到时，则把描述包在一个隐藏 div 中，并在正文开头插入 标记，让普通主题也能通过 Typecho 摘要机制展示概述。具体应该会在文章的正文开头显示概述内容，实际效果未经过测试。修复的两个关键 Bug在改造过程中，顺手修复了原版中比较影响体验的问题。标题截断不生效且只支持 1-3 级标题原版的标题取值逻辑和长标题处理在某些 Frontmatter 配置下会异常，导致截断功能失效。新版本通过 useFilenameAsTitle 和更鲁棒的标题解析解决了这个问题，并把截断范围扩展到 1-6 级标题。同步后的文章无法被解析为 Markdown这个问题与服务端有关。Typecho 在保存正文时，如果没有 标记，可能会把 Markdown 当纯文本处理。我在 postArticle 中自动为正文章 prepend 该标记，确保同步后的文章能被正确渲染为 Markdown。原插件这个问题应该是要在typecho的设置中开启对应的XML的解析 markdown 才行，不过我这边反正不走这个就无所谓了目前的效果完成改造后，日常使用流程大致是这样的：在 Obsidian 中写完一篇笔记，点击 Ribbon 按钮或右键选择「推送到 Typecho」，文章就会发布到博客上，并自动在 Frontmatter 中写入 cid 和 slug。之后只要修改笔记并保存，3 秒后博客上的文章会自动更新。flowchart LR A[Obsidian 保存笔记] --> B{已有 cid?} B -->|是| C[自动更新文章] B -->|否| D[弹窗确认新建] D --> E[发布并回写 cid/slug] C --> F[完成] E --> F现在已支持的功能包括：手动推送与保存后自动推送。用文件名作为标题，或按优先级自动提取标题。Frontmatter 控制分类、标签、状态、密码、评论开关、封面图、摘要。本地图片自动上传并替换 URL，支持内容哈希缓存避免重复上传。Wiki-Link 自动转换为博客链接。标题不一致时二次确认，防止误覆盖。Frontmatter 中的 description 同时作为文章摘要与 SEO 描述透传到博客；Butterfly 主题写入独立字段，其他主题通过 实现摘要。尚未完成的主要是娱乐影音阅读管理类的特殊页面同步，这部分需要更独立的界面和模板处理，计划后续单独实现。一些还可以继续做的事这个方案已经能覆盖我 90% 以上的发布需求，但还有一些想法没做进去：发布时自动获取当前笔记的头图链接，或从图库中随机/手动选择封面图，并回写到 Frontmatter。娱乐影音阅读管理页的文章同步，可能需要隐藏首页显示并做成独立入口。这些暂时列在待办里，等实际使用一段时间后再决定优先级。总结这次二次开发本质上是一次「协议替换 + 字段补齐 + 体验优化」的组合改造。obsidian-typecho-publisher 提供了很好的发布流程骨架，typecho-plugin-Restful 提供了 REST API 基础，我把两者对接起来，并针对自己的使用习惯做了一些调整。项目主要使用AI进行的vibe coding，确实好用，主体部分大概只花了一天就开发完成了。两个二开后的仓库地址如下，如果有类似需求可以参考：Obsidian 插件：bluemoon23333/obsidian-typecho-publisherTypecho 服务端插件：bluemoon23333/typecho-plugin-Restful参考链接skyue/obsidian-typecho-publisher — 原版 Obsidian 发布插件Chen2226/typecho-plugin-Restful — 原版 Typecho RESTful 插件bluemoon23333/obsidian-typecho-publisher — 二开后的 Obsidian 插件bluemoon23333/typecho-plugin-Restful — 二开后的 Typecho 服务端插件haierkeys/obsidian-fast-note-sync — 自托管笔记同步服务
AI生成标注此文章由AI生成，不保证正确性，请注意甄别1. 项目概览对比维度obsidian-typechoobsidian-typecho-publishertypecho-xmlrpc-publisher插件 IDtypechotypecho-publishertypecho-xmlrpc-publisher版本0.1.51.0.41.3.0作者ChenSKYueHans J. Han编程语言TypeScriptTypeScriptJavaScript (纯 JS)代码行数~1200+ (9个文件)~1600+ (7个文件)~535 (单文件)文件数量20 (含配置和资源)16 (含配置和资源)2构建工具esbuildesbuild无 (直接分发)运行时依赖i18next无无最低 Obsidian0.15.01.12.01.5.02. 通信协议对比维度obsidian-typechoobsidian-typecho-publishertypecho-xmlrpc-publisher通信协议RESTful API (自定义)XML-RPC (MetaWeblog API)XML-RPC (MetaWeblog + Blogger API)服务端要求需安装配套插件 Typecho Restful仅需 Typecho 原生 XML-RPC仅需 Typecho 原生 XML-RPC鉴权方式Token (Bearer 风格)用户名+密码用户名+密码JSON vs XMLJSON 请求/响应XML 请求/响应XML 请求/响应API 封装层HttpUtils 类 (get/post)XmlRpcClient 类 (call/newPost/editPost/uploadMedia)XmlRpc 静态工具类 (buildCall/parseResponse)开箱即用❌ 需要额外安装服务端插件✅ 原生 XML-RPC 即可✅ 原生 XML-RPC 即可3. 功能特性对比3.1 核心发布功能功能obsidian-typechoobsidian-typecho-publishertypecho-xmlrpc-publisher新建文章✅✅✅更新已有文章❌ (每次都是新建)✅ (通过 typecho_postid)✅ (通过 cid)Frontmatter 自动读取❌✅ (9个字段可映射)✅ (7个字段可映射)Frontmatter 回写✅ (slug/title/tags等)✅ (typecho_postid)✅ (cid/slug/dateCreated等)发布时间处理由服务端决定✅ (从 Frontmatter 读取)✅ (可配置偏移 + 当前时间)Slug 回退策略Hash 自动生成✅ 日期格式模板❌ 留空让 Typecho 生成内容预览✅ (文章摘要 HTML)❌❌发布进度弹窗✅ (Notice)✅ (自定义 Modal + 链接)✅ (Notice)3.2 图片与文件处理功能obsidian-typechoobsidian-typecho-publishertypecho-xmlrpc-publisher粘贴图片自动上传✅ (核心特色)❌❌图片上传到图床上传到 RESTful API 服务端✅ R2 (AWS SigV4) + Typecho 附件❌图片上传缓存❌✅ (path→URL 缓存)❌文件管理✅ (上传/删除/复制URL/预览)❌❌批量文件上传✅ (进度条+取消)❌❌Wiki-Link 转换❌✅ (双链 → 博客 URL)❌3.3 文章管理功能功能obsidian-typechoobsidian-typecho-publishertypecho-xmlrpc-publisher浏览文章列表✅ (分页+筛选)❌✅ (getRecentPosts)删除文章❌❌✅导入文章到 Obsidian✅ (htmlToMarkdown)❌✅ (含 YAML frontmatter)同步发布时间❌❌✅文章预览✅ (HTML 渲染)❌❌分类/标签树形浏览✅ (层级展开)❌❌管理分类/标签✅ (添加)❌❌3.4 高级特性功能obsidian-typechoobsidian-typecho-publishertypecho-xmlrpc-publisherFrontmatter 类型校验❌✅ (严格校验)❌内容截断❌✅ (按标题)❌ 校验❌✅ (可选)❌多种发布状态❌✅ (publish/draft/pending/private/future)✅ (草稿开关)自定义文章类型❌✅ (post/page)❌国际化✅ i18next✅ 内置双语❌ (仅中文)插件图标✅ (自定义 SVG)✅ (send 图标)❌右侧面板集成✅ (ItemView)❌❌4. 代码质量与架构对比维度obsidian-typechoobsidian-typecho-publishertypecho-xmlrpc-publisher类型安全✅ TypeScript✅ TypeScript❌ JavaScript模块化✅ 9个模块文件✅ 7个模块文件❌ 单文件 (内聚但耦合)设计模式基础分层依赖注入 + 策略模式直接过程式可测试性中等高 (依赖注入)低 (全局状态)代码可维护性中等高中低 (单文件但逻辑清晰)ESLint✅❌❌构建复杂度中等 (esbuild + tsc)中等 (esbuild + tsc)无构建PHP 错误处理N/A (RESTful)✅ (自动清理)❌ (未处理)5. 用户体验对比维度obsidian-typechoobsidian-typecho-publishertypecho-xmlrpc-publisher发布触发方式1种 (Ribbon)4种 (Ribbon/Command/FileMenu/EditorMenu)3种 (3个 Command)是否弹窗编辑✅ (界面丰富)❌ (一键发布)✅ (弹窗编辑)新建/编辑确认❌✅ (弹窗确认)❌ (cid 自动判断)发布后反馈Notice 文字Modal (含链接+统计)Notice 文字学习曲线中等 (配置多)较高 (字段映射+图床)低 (配置简单)安装复杂度高 (需服务端插件)低 (原生 XML-RPC)极低 (2个文件)中文文档✅ (README 中英)✅ (README 中英)❌ (仅 manifest 描述)6. 优劣分析6.1 obsidian-typecho — 优势功能最丰富: 不仅支持发布，还有右侧面板、文件管理、图片粘贴上传、文章预览等 IDE 级功能图片粘贴上传: 独有的"粘贴即上传"功能，是内容创作者最需要的工作流优化RESTful API: JSON 格式更现代，调试更友好，可扩展性更强树形分类/标签: 直观的层级结构展示Slug 映射缓存: 自动化 Slug 管理文件管理: 内置文件上传/删除/复制URL/图片预览功能6.2 obsidian-typecho — 劣势需要服务端插件: 最大门槛 — 必须安装额外的 Typecho 插件，限制了用户群体不支持更新: 每次发布都是新建文章，无法更新已有文章版本较低 (0.1.5): 功能可能不够稳定配置项较多: Host + Token + User 三个配置项，相比另两者更复杂不支持 Frontmatter 自动读取: 需要手动在弹窗中填写元数据无发布状态管理: 无法控制草稿/发布/定时等状态6.3 obsidian-typecho-publisher — 优势功能最完善的 XML-RPC 发布器: 一键发布 + 图片处理 + 双链转换 + 内容截断 + 类型校验开箱即用: 无服务端插件依赖，配置 XML-RPC 即可使用严格的类型校验: 确保 Frontmatter 数据类型正确，避免发布失败Cloudflare R2 图床: 支持专业的外部图床，带有 AWS Signature V4 签名和上传缓存Wiki-Link 转换: 独有的 双链 → 博客 URL 功能，连接 Obsidian 知识图谱与博客内容截断: 可以隐藏草稿、变更日志等私密段落依赖注入架构: 代码质量高，易于测试和扩展丰富的发布入口: Ribbon + Command + FileMenu + EditorMenu进度弹窗: 带成功/失败反馈和可点击的文章链接自动新建/编辑: 通过 typecho_postid 自动区分6.4 obsidian-typecho-publisher — 劣势学习曲线较高: 字段映射、URL 模板、截断标题等配置项较多R2 配置复杂: Cloudflare R2 需要 Account ID/Access Key/Secret Key 等多项凭证无文章管理功能: 无法浏览/删除/导入服务器上的文章无文件管理: 不支持文件上传管理6.5 typecho-xmlrpc-publisher — 优势极简部署: 仅 2 个文件，无需构建，即拷即用纯 JavaScript: 不需要 npm/TypeScript 知识即可修改功能最均衡: 同时支持发布、更新、删除、导入、同步发布时间可配置的 Frontmatter 键: 允许用户自定义所有键名时间偏移: 发布和同步两个独立的时区调整文章管理: 支持删除和导入（含完整 YAML frontmatter）版本最高 (1.3.0): 可能迭代次数最多，相对成熟分类必填校验: 防止无分类的"孤儿"文章6.6 typecho-xmlrpc-publisher — 劣势无类型安全: JavaScript 代码存在运行时类型错误风险代码耦合度高: 单文件包含所有逻辑，可维护性相对较低无图片处理: 不支持图床上传或图片处理无国际化: 仅中文界面无内容转换: 不支持 Wiki-Link 转换、内容截断等高级功能XML 解析脆弱性: PHP 8.x 下可能遇到弃用警告打乱 XML7. 技术栈雷达图式对比 obsidian-typecho obsidian-typecho-publisher typecho-xmlrpc-publisher 功能丰富度 ████████████ ██████████ ██████ 开箱即用度 ██ ████████ ██████████ 代码工程质量 ████████ ████████████ ██████ 类型安全 ████████ ████████████ ██ 部署简易度 ████ ██████ ██████████ 图片处理能力 ██████████ ██████████ ██ 文章管理能力 ██████████ ██ ████████ 发布体验 ██████ ██████████ ████████8. 适用场景推荐选择 obsidian-typecho 如果你:愿意安装服务端插件需要图片粘贴自动上传（文字创作者的核心需求）需要在 Obsidian 内管理 Typecho 文件（上传/删除/预览）需要树形分类/标签浏览偏爱 RESTful API 胜过 XML-RPC需要富功能面板体验选择 obsidian-typecho-publisher 如果你:追求一键发布的极致效率使用 Cloudflare R2 作为图床需要 Wiki-Link → 博客链接 转换需要 Frontmatter 类型严格校验需要内容截断隐藏私密段落重视代码质量和可维护性需要多入口发布 (命令/右键/Ribbon)选择 typecho-xmlrpc-publisher 如果你:追求极简部署（2个文件即用）需要发布 + 更新 + 删除 + 导入全套文章管理需要同步发布时间到本地喜欢在发布前弹窗编辑（标题/标签/分类/发布时间）使用纯 JavaScript 项目，不想引入构建工具需要可配置的 Frontmatter 键名9. 综合评分评分维度obsidian-typechoobsidian-typecho-publishertypecho-xmlrpc-publisher功能完整性⭐⭐⭐⭐⭐ (5/5)⭐⭐⭐⭐ (4/5)⭐⭐⭐ (3/5)易用性⭐⭐⭐ (3/5)⭐⭐⭐⭐ (4/5)⭐⭐⭐⭐⭐ (5/5)代码质量⭐⭐⭐⭐ (4/5)⭐⭐⭐⭐⭐ (5/5)⭐⭐⭐ (3/5)部署难度⭐⭐ (2/5)⭐⭐⭐⭐ (4/5)⭐⭐⭐⭐⭐ (5/5)发布体验⭐⭐⭐ (3/5)⭐⭐⭐⭐⭐ (5/5)⭐⭐⭐⭐ (4/5)服务端兼容⭐⭐ (需要插件)⭐⭐⭐⭐⭐ (原生)⭐⭐⭐⭐⭐ (原生)图片处理⭐⭐⭐⭐ (4/5)⭐⭐⭐⭐⭐ (5/5)⭐ (1/5)可扩展性⭐⭐⭐⭐ (4/5)⭐⭐⭐⭐⭐ (5/5)⭐⭐ (2/5)10. 总结这三款插件代表了三种不同的设计哲学：obsidian-typecho 走的是 "平台化" 路线 — 把 Obsidian 变成一个 Typecho 的管理客户端，功能最丰富但代价是需要服务端插件和更多配置。obsidian-typecho-publisher 走的是 "专业发布" 路线 — 专精于发布链路，在图片处理、双链转换、内容截断等方面做到极致，是三个中发布体验最好的。typecho-xmlrpc-publisher 走的是 "极简实用" 路线 — 用最少的代码实现最核心的功能（发布+管理），部署成本最低，学习曲线最平缓。如果只选一个作为长期使用，obsidian-typecho-publisher 是最均衡的选择。它在功能深度和易用性之间取得了最佳平衡，同时代码质量最高，架构最清晰。但如果你的核心需求是"粘贴图片自动上传"或"文章管理面板"，那么 obsidian-typecho 更适合你。