集成化插件开发设想

[流氓兔]

• 一直有以下烦恼：
  • 想修改Obsidian某些地方的UI与样式，但使用CSS片段非常麻烦，而且可能还很消耗性能（:has，:not一类），或者无从定位（例如右键菜单，第三方插件管理）
  • 需要为现有的Obsidian功能添加扩展支持
  • 不想为一些小功能找单独的插件，也不想为这些插件汉化
  • 设置面板的插件管理混乱
  • 右键菜单冗余，难以定制管理
• 于是借助AI开发一个集成化插件，其特点是集成&无主题，把自己的痛点分区打包成一个插件

  • 已安装的第三方插件有大量轻量完备的插件，它们基本已经不再更新，所以为什么我不把他们集成在一起方便管理呢？

  • 以及自己的需求痛点小而分散，实在没必要单独分别开发插件
    *

    

[流氓兔]

目前已经实现如下，但需求只会越来越多：

考虑到插件功能不可能满足所有人，所以比起分享插件本身还是分享AI开发实践为好，目前插件开发使用以下个人构建的SKILL.MD

---
name: obsidian-plugin-development
description: "专业的 Obsidian 插件开发指南，重点关注安全实现、与 Obsidian v1.4.16 的兼容性、官方稳定 API、性能、移动端适配以及插件评审。适用于创建、修改、调试、审查或规划 Obsidian 插件、manifest、设置页签、命令、视图、文件操作、DOM 交互、网络请求，或基于 Vue 3 的 Obsidian 插件 UI。"
metadata:
  author: "LMT°"
---

# Obsidian 插件开发

## 概述

请以专业的 Obsidian 插件开发者身份开展工作。将插件在 Obsidian v1.4.16 上的正常运行视为最高兼容性优先级，并优先使用 <https://docs.obsidian.md> 中有官方文档说明的 API。

## 核心工作流

1. 明确目标 Obsidian 版本范围，并在插件元数据或发布说明中清晰声明，例如 `1.0+`，除非用户给出了更严格的范围。
2. 优先使用官方稳定的 Obsidian API。除非没有稳定替代方案，否则避免使用未文档化的内部方法；如果必须使用，应在使用前明确说明风险。
3. 选择最简单可行的实现方案：优先使用原生 JavaScript，只有在 JavaScript 不足以满足需求，或官方 API 的类型定义确实能显著降低风险时，再使用 TypeScript。
4. 对于 UI 较重的插件，当确实需要框架时优先使用 Vue 3。简单的命令、设置项和模态框应尽量保持无框架实现。
5. 在最终交付代码前，验证安全性、兼容性和性能。

## 安全规则

- **绝不**建议修改 Obsidian 核心文件或数据库结构。
- **绝不**生成可能破坏用户数据的代码（如无备份的文件操作）。
- 所有文件操作必须包含错误处理和回滚机制。
- 涉及网络请求时，默认建议添加超时和重试逻辑。
- 在执行具有破坏性或影响范围较大的库内变更前，必须向用户提供清晰明确的提示。

## 兼容性规则

- 优先确保在Obsidian v1.4.16版本可以正常使用。
- 明确声明插件支持的 Obsidian 版本范围（如 `0.15+` 或 `1.0+`）
- 优先使用官方稳定 API，避免未文档化的内部方法。
- 处理移动端适配时，必须考虑触摸交互和性能限制。
- 在使用特定能力前，先检查平台能力，以确保插件在桌面端和移动端都具有良好的稳健性。

## 性能规则

- 避免在主线程执行耗时操作（>50ms）
- 大量 DOM 操作必须使用文档片段（DocumentFragment）
- 对于超过 100 项的长列表，使用虚拟滚动或增量渲染。
- 对输入、滚动、窗口大小变化以及库变更监听等高频事件，使用防抖或节流。
- 避免在启动阶段或频繁事件中重复执行全库扫描；应缓存结果并进行精确失效控制。

## 技术偏好

- 当需求允许时，优先使用无需构建步骤的 JavaScript。
- 当插件本身已使用 TypeScript、用户明确要求 TypeScript，或官方 API 类型定义能显著降低风险时，使用 TypeScript。
- 如果需要 JavaScript 框架，优先选择 Vue 3。
- 在搭建新项目脚手架时，保持插件结构与官方示例插件兼容：<https://github.com/obsidianmd/obsidian-sample-plugin>。

## 审查清单

- 插件是否避免修改 Obsidian 核心文件和私有存储？
- 文件操作是否具备错误处理和恢复机制？
- 支持的 Obsidian 版本是否已清晰声明？
- 实现中是否尽可能避免使用未文档化的 API？
- 对耗时操作、长列表、DOM 更新和高频事件是否进行了高效处理？
- 在适用情况下，是否考虑了移动端触控与性能限制？
- 网络请求是否具备超时保护以及安全的重试行为？

## 参考链接

- 官方开发者文档：<https://docs.obsidian.md/>
- 官方 API 类型定义：<https://github.com/obsidianmd/obsidian-api>
- 官方示例插件：<https://github.com/obsidianmd/obsidian-sample-plugin>
- 如有 API 问题或请求新 API，请访问论坛：<https://forum.obsidian.md/c/developers-api/14>
- Obsidian 中文论坛：<https://forum-zh.obsidian.md/>
- Obsidian 英文论坛：<https://forum.obsidian.md/>
- 级联菜单/多级菜单的注册参考：<https://forum-zh.obsidian.md/t/topic/29349>、<https://forum-zh.obsidian.md/t/topic/30838>

[流氓兔]

我的开发环境如下：

• 不使用官方示例仓库，TS代码又多又乱，我也看不懂
• 第三方库插件的组成：main.js、manifest.json、data.json、styles.css，其中后三者平时开发不怎么动，因此我单独为main.js创建一个构建前的源目录（如下图的src，因为Obsidian插件加载不支持“运行时拆模块后再相对 require 本地模块”的方案，而不拆模块维护起来非常麻烦），每次调试就重新构建打包一个main.js在项目根目录，配合hot-reload实现实时效果验证
  • 

[lspzc]

好东西，收下了，吱一声

[流氓兔]

关系图谱对a标签的支持完成了，局部关系图谱终于有用了

[流氓兔]

• 目前插件仓库在此，没有打算上社区市场，也不会更新版本号，使用方式嘛，如果只是想使用不开发，下载main.js、manifest.json、styles.css三个文件即可，如果想要开发，整个仓库克隆到本地然后在src里进行开发，然后npm run build构建，构建产物会覆盖已有的main.js、styles.css，配合hot-reload插件更加

GitHub - khbbkhbk/obsidian-nene-plugin

• 插件的子功能默认关闭，可自行开启。

[流氓兔]

使用AI开发，我的建议是：

• 做好备份，做好安全审查
• 不做备份，仅做无破坏性功能的追加，并做安全审查

开发前建议先整理下自己的插件，我的笔记不依赖各种front-matter、第三方主题样式，并且也不使用dataviewjs、templater等插件，不使用某些特定插件的特殊语法（只有我为自定义CSS设计的特殊语法），没有太大的插件顾虑，无需考虑插件冲突