简介：这份离线插件大全面向无法连接 Obsidian 社区、或希望在内网与离线环境下扩展笔记功能的用户，尤其适合需要主题美化、编辑增强与效率插件的进阶使用者。资源共收录 967 个文件，以 686 个 zip 插件包为主体，另含 136 个 css 主题样式、127 个 png 与 10 个 jpg 预览图、6 个 md 说明文档及少量 gif 等辅助文件，压缩包整体约 238.37MB，覆盖插件与主题两大类别。内容预览中可见 Willemstad、Blue Topaz、Catppuccin、Terminal、Typewriter 等多款热门主题样式，说明包内同时兼顾界面美化与功能扩展需求。已有 5844 人学习下载，读者可从中按需挑选插件解压至 plugins 目录，快速搭建属于自己的离线插件库，省去逐个联网检索与下载的时间，适合希望一次性补齐常用插件、对照主题效果进行个性化配置的用户参考使用。
1. 断网环境下的 Obsidian 插件仓库：一份离线包能解决哪些真实麻烦
很多人第一次意识到 Obsidian 需要离线插件，是在一台不能连外网的机器上。装好 Obsidian 本体，打开设置里的第三方插件面板，转圈半天刷不出列表，手动点“浏览”也打不开社区市场。这时候你手里如果只有安装包，没有一份整理好的离线插件仓库，基本就卡死了。这份 obsidian 离线插件大全，本质上是一个把常用社区插件按功能分类、连 main.js、manifest.json、styles.css 一起打包的资源集合，配合 Obsidian 的本地插件目录机制，让整个安装过程不依赖任何在线请求。它适合三类人：内网办公、需要长期锁定插件版本、以及想批量给多台机器部署同一套插件环境的人。下面我按“先搞懂加载机制，再动手装，最后讲怎么排错和进阶”的顺序拆一遍，中间会给出可直接抄的目录结构和脚本。
2. Obsidian 插件加载机制与离线包目录结构
2.1 为什么社区市场打不开，插件却还能跑
Obsidian 的插件体系分两层。第一层是插件运行时，它只认.obsidian/plugins/<插件ID>/这个目录，只要目录里有manifest.json和main.js，Obsidian 启动时就会扫描并加载，整个过程不校验来源、不联网。第二层才是社区市场，它负责搜索、下载、更新，走的是在线接口。离线包绕开的就是第二层，直接把第一层的产物塞进目录。所以判断一份离线包能不能用，标准很简单：解压后每个插件文件夹里是不是齐了manifest.json、main.js，带样式的还要有styles.css。缺main.js的包，Obsidian 会识别到插件名但启用时报错，这是最常见的翻车点。
2.2 一份合格离线包的目录长什么样
我一般会把离线包整理成下面这种结构，外层按功能分类，内层直接是插件 ID 目录，方便整包拷贝也方便单个挑：
obsidian-offline-plugins/ ├── 01-编辑增强/ │ ├── obsidian-outliner/ │ │ ├── manifest.json │ │ ├── main.js │ │ └── styles.css │ └── cm-editor-syntax-highlight/ │ ├── manifest.json │ └── main.js ├── 02-双链与关系/ │ ├── dataview/ │ │ ├── manifest.json │ │ ├── main.js │ │ └── styles.css │ └── obsidian-excalidraw-plugin/ │ ├── manifest.json │ ├── main.js │ └── styles.css ├── 03-导入导出/ │ ├── obsidian-importer/ │ │ ├── manifest.json │ │ └── main.js │ └── obsidian-pandoc/ │ ├── manifest.json │ └── main.js └── 04-同步与备份/ ├── remotely-save/ │ ├── manifest.json │ └── main.js └── obsidian-git/ ├── manifest.json └── main.js分类不是必须的，但强烈建议保留，因为插件一多，光靠 ID 你根本记不住哪个是干嘛的。manifest.json里的id字段必须和文件夹名一致，minAppVersion决定它能不能在你当前 Obsidian 版本上跑，这两个字段是排查兼容性问题的第一入口。
2.3 版本匹配：离线包最容易忽略的一环
在线安装时市场会自动挑兼容版本，离线包不会。manifest.json里的minAppVersion如果高于你本机 Obsidian 版本，插件会直接不加载，而且设置面板里可能连报错都不明显。常见做法是先把本机版本号记下来（设置 → 关于），再逐个核对离线包里每个manifest.json的minAppVersion。批量核对可以用一段脚本，比一个个点开快得多：
#!/usr/bin/env bash # 检查离线插件包中每个 manifest.json 的 minAppVersion # 用法: ./check_min_version.sh /path/to/obsidian-offline-plugins 1.5.0 PLUGIN_DIR="$1" CURRENT_VERSION="$2" find "$PLUGIN_DIR" -name "manifest.json" | while read -r mf; do id=$(grep -o '"id"[^,]*' "$mf" | head -1 | cut -d'"' -f4) min=$(grep -o '"minAppVersion"[^,]*' "$mf" | head -1 | cut -d'"' -f4) # 简单字符串比较，正式场景建议用 sort -V if [[ "$min" > "$CURRENT_VERSION" ]]; then echo "[不兼容] $id 需要 $min，当前 $CURRENT_VERSION" else echo "[OK] $id 需要 $min" fi done这段脚本遍历所有manifest.json，抽出id和minAppVersion，和传入的当前版本做比较。参数说明：第一个参数是离线包根目录，第二个是你本机 Obsidian 版本号。注意这里用的是字符串比较，对1.10.0和1.9.0这种会误判，正式用建议换成sort -V或版本号分段比较。跑一遍就能把不兼容的插件筛出来，避免装完一堆启用失败还不知道为什么。
3. 把离线插件装进库：三种落地方式与参数细节
3.1 手动拷贝：最稳但最容易漏文件
手动方式适合只装几个插件。步骤是：先关闭 Obsidian（不关的话插件目录可能被占用，拷贝后不生效），找到你的库根目录，进入.obsidian/plugins/，把离线包里对应插件文件夹整个拷进去，重新打开 Obsidian，到设置 → 第三方插件里启用。这里有几个参数细节：.obsidian是隐藏目录，macOS 用Cmd+Shift+.显示，Windows 在资源管理器里勾“显示隐藏项目”。如果你的库开了“受限模式”，启用前要先关掉，否则插件列表是灰的。拷贝时确认目标目录下没有同名旧版本，有的话先删掉再拷，直接覆盖有时会残留旧main.js，导致行为诡异。
3.2 脚本批量部署：多库多机场景的省事做法
要给多个库或几台机器装同一套插件，手动拷贝太慢。我一般写一个部署脚本，把离线包同步到指定库的插件目录：
#!/usr/bin/env bash # 将离线插件包批量部署到指定 Obsidian 库 # 用法: ./deploy_plugins.sh /path/to/obsidian-offline-plugins "/path/to/MyVault" SRC="$1" VAULT="$2" DEST="$VAULT/.obsidian/plugins" if [[ ! -d "$DEST" ]]; then echo "目标插件目录不存在，请确认库路径: $DEST" exit 1 fi # 遍历离线包里的插件目录（含 manifest.json 的目录） find "$SRC" -name "manifest.json" -print0 | while IFS= read -r -d '' mf; do plugin_dir=$(dirname "$mf") plugin_id=$(basename "$plugin_dir") target="$DEST/$plugin_id" mkdir -p "$target" # 只拷贝插件运行必需的三类文件 cp -f "$plugin_dir/manifest.json" "$target/" 2>/dev/null cp -f "$plugin_dir/main.js" "$target/" 2>/dev/null cp -f "$plugin_dir/styles.css" "$target/" 2>/dev/null echo "已部署: $plugin_id" done echo "完成，重启 Obsidian 后在第三方插件中启用。"逻辑是按manifest.json定位插件目录，取目录名作为插件 ID，在目标库的.obsidian/plugins/下建同名目录，只拷manifest.json、main.js、styles.css三类运行必需文件。参数说明：SRC是离线包根目录，VAULT是库根目录，脚本会自动拼出.obsidian/plugins。这样拷的好处是不会把离线包里的说明文档、截图一起塞进去，保持插件目录干净。部署完记得重启 Obsidian，热重载对新增插件目录不总是生效。
3.3 用 BRAT 做本地源：适合频繁更新的场景
如果你需要经常在离线包里换插件版本，每次手动拷贝很烦。BRAT 这个插件支持从本地路径或 Git 仓库添加插件，离线环境下可以把它指向本地目录。做法是先在能联网的机器上装好 BRAT，把它的插件目录一起打进离线包，部署到目标库后启用，然后在 BRAT 设置里添加本地路径。注意 BRAT 本身也依赖网络做版本检查，纯离线场景下它更适合“本地目录添加”这一条路径，自动更新那部分用不了。这个方式适合插件版本迭代频繁、又不想每次全量拷贝的人，代价是多一层 BRAT 的配置成本。
4. 离线插件常见问题排查：从启用失败到双链失效
4.1 插件显示已安装但启用报错
现象：第三方插件列表里能看到插件名，点启用后弹错误或开关自动弹回。原因通常是main.js缺失或损坏，也可能是manifest.json里id和文件夹名不一致。解决：打开插件目录，确认三个文件齐全，用编辑器打开manifest.json核对id字段是否等于文件夹名。如果main.js是 0 字节，说明离线包本身打包不完整，换一份重新拷。
4.2 插件启用成功但功能不生效
现象：开关是开的，但命令面板里搜不到对应命令，或者双链、Dataview 查询没反应。原因多半是版本不匹配或依赖插件没装。比如 Dataview 的查询要生效，得先确保它自己启用且库里有符合语法的代码块；Excalidraw 依赖它自己的资源目录。解决：先看设置 → 关于里的 Obsidian 版本，对照minAppVersion；再确认该插件的依赖项是否也在离线包里并已启用。常见做法是装完一批插件后重启一次 Obsidian，让所有插件完成初始化。
4.3 双链和附件在 Typora 里读不出
现象：Obsidian 里双链正常，把笔记导到 Typora 或别的编辑器后，[[链接]]变成纯文本，附件路径也失效。原因：双链是 Obsidian 的私有语法，Typora 不认；附件路径默认是相对库根的，换编辑器后基准目录变了。解决：导出前用 Pandoc 类插件转成标准 Markdown，把[[链接]]转成[文本](路径)；附件统一放库内固定目录，导出时连同附件一起搬。这不是离线插件本身的 bug，是跨编辑器格式差异，提前知道能省很多返工。
4.4 离线包里的插件互相冲突
现象：单独装都正常，一起装就出现快捷键失灵、编辑器卡顿、命令重复。原因：多个插件抢同一个快捷键，或都去改编辑器行为。解决：到设置 → 快捷键里搜冲突项，把不常用的改掉；编辑器类插件一次只启用一个，比如大纲和增强编辑类不要叠着开。我一般会按“编辑增强只留一个、双链类可共存、同步类只留一个”的原则做减法。
4.5 库迁移后插件全部失效
现象：把库文件夹整体拷到新机器，打开后插件列表空了。原因：.obsidian是隐藏目录，拷贝时被系统跳过，或者新机器上 Obsidian 版本更低。解决：确认.obsidian/plugins/跟着一起拷了；核对新机器 Obsidian 版本不低于插件minAppVersion。迁移前用前面那段版本检查脚本跑一遍，能提前发现大部分问题。
5. 进阶：把离线插件包做成可复用的环境基线
5.1 用清单文件锁定插件集合
插件一多，靠记忆维护不现实。我习惯在离线包根目录放一个plugins.lock，记录每个插件的 ID、版本、来源和用途，部署脚本读它来决定装哪些：
# id | version | category | note dataview | 0.5.64 | 双链与关系 | 查询与表格 obsidian-excalidraw-plugin | 2.2.5 | 双链与关系 | 手绘图 obsidian-git | 2.24.0 | 同步与备份 | 版本管理 remotely-save | 0.4.12 | 同步与备份 | 对象存储同步 obsidian-outliner | 4.8.0 | 编辑增强 | 大纲操作这份清单的价值在于：换机器时不用回忆装了啥，直接按清单部署；出问题时能快速定位是哪个插件版本引入的。版本号从各插件manifest.json的version字段抄，别手写，容易错。
5.2 验证离线包完整性
部署前跑一遍完整性检查，比装完再排错省事。核心是确认每个插件目录三件套齐全、manifest.json能解析、id和目录名一致：
#!/usr/bin/env bash # 校验离线插件包完整性 # 用法: ./verify_pack.sh /path/to/obsidian-offline-plugins SRC="$1" fail=0 find "$SRC" -name "manifest.json" -print0 | while IFS= read -r -d '' mf; do dir=$(dirname "$mf") id_in_manifest=$(grep -o '"id"[^,]*' "$mf" | head -1 | cut -d'"' -f4) dir_name=$(basename "$dir") [[ "$id_in_manifest" != "$dir_name" ]] && { echo "[ID不一致] $dir"; fail=1; } [[ ! -f "$dir/main.js" ]] && { echo "[缺main.js] $dir"; fail=1; } # styles.css 可选，仅提示 [[ ! -f "$dir/styles.css" ]] && echo "[无样式] $dir" done [[ "$fail" -eq 0 ]] && echo "校验通过" || echo "存在问题，请修复后再部署"逻辑是逐个插件目录比对manifest.json里的id和目录名，检查main.js是否存在，styles.css缺失只提示不报错。参数只有一个：离线包根目录。跑完输出问题清单，修完再部署，能挡掉大部分“装了不生效”的情况。
5.3 一个我踩过的坑
早期我图省事，直接把在线安装好的.obsidian/plugins/整个拷出来当离线包用，结果换到低版本 Obsidian 的机器上，一半插件不加载。后来才养成习惯：离线包必须带manifest.json里的minAppVersion信息，部署前先跑版本检查。从那以后我每次整理离线包，都强制走一遍“版本检查 → 完整性校验 → 部署 → 重启验证”四步，再没出现过整批插件失效的情况。希望帮到你。
本文还有配套的精品资源，点击获取
