简介面向 Obsidian 用户的离线插件与主题合集专门解决社区插件市场无法连接、无法在线浏览或下载扩展的痛点尤其适合内网、弱网及偏好本地管理的用户。资源包含 967 个文件以 686 个 zip 格式的插件压缩包为主体另有 136 个 css 主题样式、127 个 png 预览图以及少量 jpg、md 等辅助文件整体压缩包约 238MB。内容既有功能扩展类插件也有界面美化用的 CSS 主题每款插件以独立压缩包形式提供可按需选用并直接放入本地插件目录加载使用规避网络依赖。目前已有 5840 人学习下载资源整理自社区常见优质插件附带的主题样式与说明文件能帮助新手快速了解各插件的功能和外观差异省去四处寻找和逐个测试的时间无论是想更换界面风格还是补充编辑效率都能从中快速找到对应插件减少重复配置时间。对于插件开发者而言也是一份内容直观的离线素材参考。需要留意的是不同 Obsidian 版本对插件的兼容性有所不同使用前建议对照自身版本择优选用。1. 离线插件包到底能解决什么一台没网的 Obsidian 也能武装完整Obsidian 的社区插件是它真正拉开差距的地方但插件市场在国内网络环境下加载极不稳定哪怕你能正常访问官网下载客户端进到「社区插件」页面也可能一直转圈更别提批量安装十几个插件时一个接一个超时失败。我见过不少同事在内网机器上装 Obsidian折腾一下午只装上一个主题最后干脆放弃。离线插件包解决的就是这个问题提前把插件文件下载好打包进 Vault 的 .obsidian 目录不管环境有没有网插件都能正常加载。它适合三类人企业内网用户、经常换电脑或重装系统的 Obsidian 重度用户、以及想给不会折腾的同事做一套开箱即用配置的人。这篇笔记从插件目录结构讲起教你判断一个离线包是否完整、怎么批量部署、哪些插件离线后依然用不了最后把我踩过的坑都列出来。2. 认识插件的安装形态懂 manifest.json 才是真正看懂离线包2.1 一个插件目录里三件套各自干什么从插件市场或者 GitHub Releases 下载一个 Obsidian 插件包后你会看到一个以插件 ID 命名的文件夹里面通常长这样obsidian-git/ ├── main.js ├── manifest.json └── styles.cssmain.js 是插件编译后的主程序Obsidian 加载插件时运行的就是它。manifest.json 是插件的元信息包含 id、name、version、minAppVersion 和 authorObsidian 靠这个文件判断插件身份、版本号以及和当前客户端是否兼容。styles.css 是可选的样式文件有的插件完全不需要界面样式就没有这个文件只有 main.js 和 manifest.json 也算完整包。判断一个离线插件包是否完整第一反应不是去数文件数量而是先打开 manifest.json 看结构。缺少 manifest.json 的目录不会被加载缺少 main.js 的话插件在列表里会出现但启不动。很多从 GitHub 直接下载源码 ZIP 的新手会犯一个错误把整个源码目录丢进 plugins 目录里面根本没有编译好的 main.js因为源码需要先构建。官方 Releases 页面的 Assets 里如果是 zip解压后就是可用的完整包如果是纯源码包需要本地执行 npm install 和 npm run build 才产出 main.js。2.2 插件 ID、目录名和路径三者必须严丝合缝Obsidian 读取插件时遵循一套严格的路径规则每一个插件必须放在Vault/.obsidian/plugins/插件ID/下目录名必须是 manifest.json 里声明的 id 字段例如 obsidian-git 的目录名不能改成 obsidian_git也不能把插件 A 的 main.js 放进插件 B 的目录里。强行混放的表现是插件列表能看到名字勾选启用后没有反应打开开发者工具会发现加载 main.js 抛异常。这背后的原因是 Obsidian 的插件加载器按目录遍历读 manifest.json 拿到 id 后把整个目录当作插件的沙盒根路径。main.js 内部用相对路径引用 resources 等资源文件时是相对于插件目录本身计算的。目录名不匹配不会启动报错但依赖路径的插件比如主题片段补全、代码块语言映射会在运行时找不到文件。离线部署时最容易翻车的不是文件本身而是路径写错。2.3 插件配置和界面状态存在哪data.json 与 workspace 的作用插件启用后的配置不写进 main.js而是运行时在同目录下生成 data.json。比如 obsidian-git 的自动提交间隔、Copilot 的 API 地址、Calendar 的周起始日都存进这个文件。data.json 是插件自己定义的卸载插件后删除整个目录配置随之消失。有的人为了「干净卸载」只删 manifest.json 不删 data.json插件虽然不加载了但残留的 data.json 还在目录里下次安装同 ID 插件时旧配置直接生效可能带来奇怪行为。Workspace 状态则不同它记录的是布局、打开的文件、侧边栏宽度存在.obsidian/workspace.json里和具体插件无直接关联。但有些插件会把自定义视图注册到 workspace例如 Excalidraw 的绘图标签页。这时 workspace.json 会引用插件 ID 的视图类型如果插件没装Obsidian 启动会忽略这些视图日志提示「Unable to find view」。离线批量部署时,如果你复制了整个 .obsidian 目录到新机器但少了某个插件旧 workspace 里的引用就成了悬空状态表现为打开某些工作区布局时部分区域空白重新打开软件也无法恢复。3. 把整包插件送进 Vault批量离线部署的三个可行路径3.1 先做清单哪些插件值得离线带哪些不值得动手下载之前先对插件做分类。我一般按「离线可用性」分三档完全本地型、依赖外部服务型、依赖内网环境型。完全本地型包括 Calendar、Templater、Dataview、Excalidraw、Buttons、QuickAdd 这类纯文件处理和模版工具它们不发网络请求适合离线打包。依赖外部服务型包括 Obsidian Git、Remotely Save、Copilot 这类插件本身能启动但核心功能依赖远端 Git 服务器、S3 或 LLM 接口。内网环境有对应服务就能用完全断网则只能算「装上了但没发挥价值」。建议离线包以第一档为主第二档按需选第三档别带。盲目把几十个插件全塞进离线包不仅导入时拖累启动速度还会因为各自运行时报错造成主界面卡顿。一份干净的离线插件包15 个左右插件已经是舒适上限。3.2 从市场拉回安装包的三种常规方式在有网环境准备离线包常见做法是去 GitHub 找对应仓库的 Releases 页面下载包含 main.js 的 release asset。但很多知名插件并不在 Releases 附 zip而是只给源码压缩包这时你需要在仓库里寻找由自动化流程生成的 dist 目录 artifact或者用 Actions 页面手动触发 build workflow。对不了解 GitHub 的普通用户来说最简单可靠的获取途径是使用社区镜像站。社区镜像站会把插件市场里的插件按原样打包成 zip文件名通常就是插件 ID 加版本号解压后内部目录结构可以直接使用。在镜像站下载时注意核对版本号是否和 manifest.json 内的版本一致。有个细节同一插件在不同镜像站打包的格式可能不同有的 zip 解压后直接是插件目录有的会多套一层总目录。规范做法是解压后先 cd 进目录确认直接看到 main.js 和 manifest.json再决定复制哪一级。3.3 动手放按插件 ID 整目录复制到 .obsidian/plugins拿到插件目录后把它复制进Vault/.obsidian/plugins/下。推荐在资源管理器里操作而不是依赖命令行但命令行更好排除路径错误cd /d D:\MyVault\.obsidian\plugins mkdir obsidian-git copy /y E:\plugins\obsidian-git\main.js obsidian-git\ copy /y E:\plugins\obsidian-git\manifest.json obsidian-git\ copy /y E:\plugins\obsidian-git\styles.css obsidian-git\三个文件分别对应插件主程序、元信息和样式。注意 copy 时不要改变文件名大小写虽然 Windows 不区分大小写但 Obsidian 在 macOS 和 Linux 上区分如果你的 Vault 要在多系统间同步小写文件名是安全约定。复制完成后打开 Obsidian - 设置 - 第三方插件 - 关闭安全模式列表里就会出现这个插件。3.4 整库迁移把 .obsidian 目录直接打包带走批量安装多台机器时逐个复制插件太低效更实用的做法是保留一份「种子 Vault」把这台机器上已配置好的整个.obsidian目录压缩成 zip然后到新机器解压覆盖。.obsidian目录里除了 plugins还有 appearance.json主题和字体设置、hotkeys.json快捷键、core-plugins.json核心插件开关、app.json编辑器选项整体覆盖后所有本地偏好一次迁移完成。覆盖时注意不要用解压工具删除已有.obsidian目录再粘贴而应该逐项合并否则新机器上已有的工作区状态会被种子库覆盖。如果你有同步盘这种覆盖还会产生大量同步冲突记录。我通常只覆盖 plugins、appearance.json、hotkeys.json 三个部分workspace.json 和 workspace-mobile.json 保留每台机器自己的状态避免布局错乱。import json, os, zipfile ob_path D:/MyVault/.obsidian targets [plugins, appearance.json, hotkeys.json, app.json, core-plugins.json] with zipfile.ZipFile(obsidian-portable.zip, w) as zf: for name in targets: full os.path.join(ob_path, name) if os.path.isdir(full): for root, dirs, files in os.walk(full): for f in files: zf.write(os.path.join(root, f)) elif os.path.isfile(full): zf.write(full)这段脚本用 Python 打包种子库的几个关键片段排除 workspace 的一堆历史备份。zipfile 写入时保留相对路径解压到新机器时直接覆盖对应目录即可。注意代码里 targets 列表控制粒度如果你希望新机器完全复刻旧机布局可以把 workspace.json 加进去反之不建议。4. 离线包玩家的配置难题以 Git 与 Copilot 设置为例4.1 插件装好不等于能用看它有没有外部依赖离线插件装进目录、在列表里能勾选启用这只是第一步。很多插件的「能用」窗口其实很长从启动到真正干活中间还隔着外部依赖。Obsidian Git 是典型代表它把版本管理封装成图形化操作但背后依赖 Git 可执行文件、远程仓库地址、认证凭据这三样东西。离线环境下这三样缺任何一样插件界面依然打开正常点击 commit 却静默失败或弹报错。判断一个插件是否需要外部依赖最快的办法是读 manifest.json 的 minAppVersion 不解决问题去看插件主页描述里的 setup 部分。Git 插件的需求写得很明确必须系统里有 git且要在插件设置里填 user.name 和 user.email。Copilot 之类的 AI 插件同理它需要 API endpoint、key model 名称离线环境下如果你有自己的内网模型网关配置方式和在线完全一样假如完全没网那这个插件对你没有实际价值。4.2 没网的 Git 仓库怎么初始化内网机器上 Obsidian Git 的初始化步骤比在线环境多一些。前提是远程 Git 仓库已经存在且你能访问——比如内网的 GitLab。先保证命令行下 git 能正常工作再让插件接管git config --global user.name engineer git config --global user.email engineerinternal.local cd /d D:\MyVault git init git add . git commit -m init from offline package git remote add origin http://gitlab.internal/obsidian/my-vault.git git push -u origin mainObsidian Git 组件首次使用时会在插件设置里要求填 author name 与 email它不自动继承全局 git 配置需要手动在插件设置页填一遍。随后启用「自动备份」选项插件每隔一段时间执行 add-commit-push。内网环境下如果走 HTTP 协议免密需要在本机用 git credential 保存凭据否则每次 push 都会被拒绝。比较省心的方式是配置 SSH 免密生成密钥后把公钥注册进内网 GitLab插件设置里 Remote URL 填ssh://gitgitlab.internal:2222/obsidian/my-vault.git。有一点别忽略Obsidian Git 默认备份间隔是 10 分钟内网推送大文件时往往触发超时。在插件设置里把 Commit type 改为单个提交、关闭 push 前自动 commit可以在弱网环境下降低失败率。4.3 Copilot 类插件离线包里它只是空壳以 Copilot 插件为代表的 LLM 类工具即便完整放进离线包、插件能启动、配置项能填写实际调用动作全部发往远端 API。断网机器上这类插件的所有按钮都是「能点但没用」表现为请求超时、无响应或 0 补全结果。如果你用的是 local Ollama 或 LM Studio插件请求发送到http://localhost:11434或http://localhost:1234只要这些服务在装插件前已经跑起来插件设置 Base URL 指对端口即可。但本地模型权重文件往往数 GB离线环境下分发成本高于插件本身。我的经验是Copilot 这类插件作为离线包的可选配不写进必装清单放到「环境满足再启用」分类里。真正离线场景优先把 Templater、QuickAdd、Dataview 配合着做成一套自动处理流程比抱一个不能联网的 AI 插件实用得多。5. 避坑离线装插件最常见的五个翻车现场5.1 解压后的文件名全是乱码现象从镜像站下载的 zip 解压后插件目录名变成µ¼¥è¯ä»¶或obsidian-git-master-2-复制进 plugins 后 Obsidian 不认。原因很多打包服务用 UTF-8 编码文件名而 Windows 自带解压工具按 GBK 解码造成中文目录名乱码英文插件名则不受影响。解决用 7-Zip 解压并在选项中强制使用 UTF-8 文件名或者下载时优先选纯英文文件名格式的镜像。这个坑特别阴表面看文件都解压出来了但目录名根本不是插件 IDObsidian 找不到对应 manifest。5.2 插件部署后重启就不见了现象插件刚复制进 plugins 目录时设置页能看到重启 Obsidian 后设置页列表里消失。原因重启时 Obsidian 重新扫描插件目录扫描过程中发现某个插件的 manifest.json 里 minAppVersion 高于当前客户端版本直接跳过不加载。比如 Obsidian 1.5.12 客户端装 1.7.0 版本的插件列表就不显示。解决这种场景不是路径错误而是版本不兼容。看客户端版本号帮助 - 关于对照 manifest.json 的 minAppVersion差的版本就下载更早的 release。常见入库插件 Obsidian Git 老版本也能用不用追新。5.3 插件装上了但所有按钮都是灰色的现象插件出现在设置列表也能勾选但侧边栏图标点击无响应命令面板里搜不到对应命令。原因插件依赖的核心插件没启用。Obsidian 核心插件里「模板」「大纲」「关系图谱」等被第三方插件引用时如果没打开第三方插件初始化失败。最典型的是 Templater 依赖核心模板插件的数据结构Calendar 依赖核心日记插件。解决先打开设置 - 核心插件把涉及基础功能的都启用然后重启 Obsidian。这个坑很隐蔽因为第三方插件本身没报错只是静默停摆。5.4 升级失败后后悔药不够现象手动替换 main.js 升级插件后新版本一直报错想退回旧版但没有备份。原因很多离线包使用者只替换 main.js不清理 data.json。插件升级后读取旧配置格式不兼容启动即抛异常。解决替换 main.js 前先把整个插件目录复制一份到临时目录出问题直接把备份目录原样拷回去。另一个办法确定新版配置格式不稳定时只把 main.js 替换回旧版data.json 删除让它重新生成旧版插件会按默认配置重建一份。从那以后我每次替换 main.js 都强制走一遍备份流程两秒钟的动作省掉一上午排障。5.5 官方库同步把离线包覆盖掉现象内网机器的 Vault 同时开着 Obsidian Sync 或自建同步盘离线安装的插件在另一台有网机器上被官方市场更新覆盖回到内网后插件列表错乱。原因同步工具会把插件目录当作普通文件同步有网机器上点击「检查更新」后插件版本变化通过同步下发到内网机器。解决在.obsidian/plugins目录建一个.sync-exclude名单或者同步设置里排除整个 plugins 目录只在有网机器上手动维护插件版本。Obsidian 自带 Sync 也支持选择不同步特定文件夹内网机器的插件版本稳定性比追新更重要。6. 锁住版本后还不够给自己做一套带台账的离线插件库离线插件包用顺手之后要解决的问题不再是「怎么装」而是「怎么让一批插件在十台机器上保持行为一致」。我给的方案是把插件包和一份 JSON 台账绑定存放台账记录每个插件的 ID、版本、来源地址、本地配置路径和依赖说明。这相当于给每个仓库建了可追溯的来源地。整理一套自己的离线插件库时,我习惯在种子 Vault 外单独建一个目录结构与 Vault 内完全一致offline-plugins/ ├── manifest/ # 记录每个插件的 manifest.json 副本 │ └── obsidian-git.json ├── plugins/ # 解压后的插件目录 │ └── obsidian-git/ └── checker.py # 校验本地插件和 manifest 副本是否匹配checker.py 的核心逻辑是逐个读 plugins 下目录里的 manifest.json对比 manifest 副本里的版本字段不一致就打印 warningimport json, os plugin_root plugins manifest_root manifest for name in os.listdir(plugin_root): mp os.path.join(plugin_root, name, manifest.json) mc os.path.join(manifest_root, f{name}.json) if not os.path.exists(mp) or not os.path.exists(mc): print(f[MISSING] {name}) continue with open(mp, encodingutf-8) as f1, open(mc, encodingutf-8) as f2: v1, v2 json.load(f1).get(version), json.load(f2).get(version) if v1 ! v2: print(f[VERSION-MISMATCH] {name}: {v2} - {v1})这段脚本的价值在于当你从镜像站下载新板插件想替换离线包时统一能查出哪些插件停在了旧版本、哪些是刚升级的。终端输出结果补齐到台账里每次分发后同事反馈「插件和上周不一样」时你可以 30 秒定位是哪台机器没跟上。台账用 Markdown 写也行但 JSON 格式能直接被脚本读适合后续扩展成自动打包脚本。最后补一个分发的习惯把离线插件库压缩成 zip 之后别只丢文件在里面放一份 README写清楚每个插件的大致用途和离线限制。同事拿回去解压复制时不必挨个试错。我现在的种子 Vault 里每一台新机器都是从这份存档 clone 出去的插件版本全部锁死换电脑重装系统都不心慌希望帮到你。本文还有配套的精品资源点击获取