北极星的博客 - 2026年7月
type: channel
link: https://blog.polaris2333.top/index.php/2026/07/
description: 珍惜所有的不期而遇
items: 使用Obsidian搭建个人媒体记录库
items: 痴迷
items: 用 Obsidian 搭建个人 OKR 系统
items: 两个让Obsidian更顺手的辅助skill
items: 如果人生注定要分别，那相遇还有什么意义
items: 自动化将Obsidian的笔记同步到typecho的方案开发
items: 三款 Obsidian-Typecho 同步插件横向对比分析

使用Obsidian搭建个人媒体记录库
type: item
date: 2026-07-28T15:34:00+00:00
description: 使用 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 的笔记语法和 Typech…

痴迷
type: item
date: 2026-07-26T18:47:00+00:00
description: 🎬 痴迷状态想看评分⭐ 7.5上映2025-09-05时长110分钟导演库里·巴克主演迈克尔·约翰斯顿, 印达·纳瓦雷特, 库珀·汤姆林森, 梅根·劳利斯, 安迪·里克特, 黑莉·菲茨杰拉德, 达林·图恩德, 安东尼·帕沃内, 贾斯蒂斯, 安东尼·卡萨比安卡, 克洛伊·布林, 马尔科姆·凯尔纳, 特拉维斯·贝克, 凯尔·布卢门撒尔, 马修·杰克逊, 杰夫·巴克国家美国剧情简介平凡却对爱情抱有执念的青年贝尔（迈克尔·约翰斯顿 饰）在偶然得知小镇传说后，折断了一截禁忌的“心愿柳”许愿，如愿俘获暗恋对象妮基（印达·纳瓦雷特 饰）的心。可随着恋情顺遂展开，他逐渐察觉——被召唤来的并非好运，而是一种依附于欲望本身、缓慢蚕食现实的古老存在。想要的爱越圆满，代价越狰狞。 影片改编自民间禁忌传说“心愿柳”框架。观影感想比较震撼的一部片子，总体评价我认为是非常好看，挺值得一看的作为一部恐怖片，不像其他鬼怪类型的恐怖片，本片基本上以心理恐怖为主，并且我认为渲染的非常到位作为一部恐怖片，可以说是我近几年看的最有恐惧感的，看的最带劲的了有几个方面比较想记录讨论下：一是影片中我注意到的一些有意思的细节，二是什么样的爱情是健康的，三是对于剧情设定的一些发散吧下方剧透注意细节主角和女主的演技都很强看过应该都能看出来女主的演技很强，各种情绪转换表达的非常到位但其实主角的演技也不差，包括开始的时候主角对女主的喜欢，然后使用许愿柳成功之后的窃喜，不可置信，些微的挣扎这些都还不错的比较映像深刻的镜头：- 这一块先展示主角的表情变化，然后展现主角看到的东西，处理的非常不错 主角最后还是成功吞下了药物自杀成功了，算是一个不错的结局，整理逻辑都非常合理，然后有一定的反转对爱情的讨论就算抛开电影中的超现实要素不谈，只看显示中的爱情本身，会发现电影算是对现实中某些情况的极端化很多时候，占有欲过度的爱其实是不健康的其底层原因就是，占有的来源是对自己和关系的不自信，是在用占用来填补自己的缺失感，这样的感情，导向的本质其实不是对关系伙伴的爱，而是满足自己影片中也可以看出来，在许愿柳生效的时候，主角是窃喜的，这是因为他的希望女主爱他的愿望实现了。但其实他自己并没有真的爱与关心女主的情况，他关注的只是自己，哪怕他明知道女主的状况是问题的，自己得到的是通过扭曲他人的意志的来的真正的喜爱导向的应该是希望双方都能向着健康和谐幸福的方向前进的当然，这只能算是我自己的一点不成熟的思考吧放到现实中，很多时候其实我们也基本上都是在满足自己，不过也算是借着这个电影，提醒自己一下，不要为了满足自己而扭曲他人的意愿剧情设定感想这个片子里许愿柳的设定还是挺有意思可以通过许愿来改变别人的意识，从片中的表现来看似乎是有一个另外的存在代替了原来的意识同时还可以直接改变现实物理，凭空变出钱虽然有挺多不合理的地方吧，但还是挺有意思的如果放在中国网文的话，可能会出现使用许愿柳改变世界之类的，让我想起有一本就“大明与新罗马与无限神机”的书

用 Obsidian 搭建个人 OKR 系统
type: item
date: 2026-07-09T17:16:00+00:00
description: 像打游戏一样管理人生——用 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仓库去查看。四、核心灵魂：经验值评分系统好了，前面都是"基础设施"…

两个让Obsidian更顺手的辅助skill
type: item
date: 2026-07-08T17:19:00+00:00
description: 前言我记笔记的方式比较懒散：想到什么写什么，写完了再想着整理。但整理这件事本身很费脑子，尤其是两件事让我特别烦。一是我用 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、整理视频笔记这些事情，交给一个稳定的规则去做，比每次自己临时想一遍要轻松得多。如果你也有类似的烦恼，也许可以试试看。不是照搬我的做法，而是想想自己笔记流程里有哪些步骤是重复、机械、却又不得不做的，把它们固化成规则，后面会省很多事。

如果人生注定要分别，那相遇还有什么意义
type: item
date: 2026-07-08T13:18:00+00:00
description: 生命的意义不在于长度，而在于深度与温度；不在于你拥有什么，而在于你成为了怎样的人，以及你如何点亮他人的生活。我是每一个爱过我的人拼成的马赛克，我的每一拍心跳都有它的来处，所以相遇的意义就是被你改变的那部分我代替了你永远陪在我身边。

自动化将Obsidian的笔记同步到typecho的方案开发
type: item
date: 2026-07-08T12:39:00+00:00
description: 从「找到合适的发布插件」到「干脆自己改一个」，记录如何让 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-Typecho 同步插件横向对比分析
type: item
date: 2026-07-05T04:30:00+00:00
description: 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)❌❌…