Windows下Obsidian多实例隔离实战：AppData沙箱方案-拓冰建站

1. 为什么必须在一台电脑上跑多个 Obsidian 实例？

这不是“炫技”，而是真实工作流里反复撞墙后逼出来的刚需。我用 Obsidian 搭建了三套完全隔离的知识系统：一套是公司内部项目文档库（含敏感架构图和接口定义，严禁外泄），一套是个人写作素材库（含未发表的稿子、灵感碎片、草稿版本），还有一套是开源社区协作笔记（GitHub Issues 同步、PR 记录、技术方案评审）。这三套系统对插件、主题、同步策略、甚至 Obsidian 主程序版本的要求都截然不同——公司库必须锁死 v1.5.8（因某定制插件只兼容该版），写作库需要最新 v1.7.x 的 PDF 阅读增强功能，而开源库则依赖 v1.6.12 的某个已修复的 Graph View 渲染 Bug。

如果强行共用一个安装目录和一个 AppData 配置目录，结果就是：切项目=删配置=丢数据=重装插件=重配主题=重设快捷键=重连同步服务。上周我就因为误点了一个“全局更新”按钮，导致公司库的加密插件失效，临时回滚花了 47 分钟——这还不算重建索引的时间。更麻烦的是，Obsidian 官方明确不支持“多用户配置切换”，它的设计哲学是“单实例、单配置、单 vault”。所以，所谓“多版本安装”，本质是绕过官方限制，在 Windows 文件系统层构建一套可预测、可隔离、可复现的运行环境沙箱。

核心矛盾就在这里：Obsidian 的可执行文件（obsidian.exe）本身是轻量级的启动器，真正承载所有状态的是%LOCALAPPDATA%\Obsidian这个隐藏目录里的appdata数据。而 Windows 默认把所有应用的 Local AppData 都塞进C:\Users\{用户名}\AppData\Local下，路径固定、权限集中、无法并行。因此，“多版本”的第一道关卡不是装几个 .exe，而是如何让每个 Obsidian 实例拥有自己独立的、互不干扰的AppData存储根目录。这才是所有方案成败的分水岭。

提示：网上大量教程只教你怎么复制 obsidian.exe 到不同文件夹，却对 AppData 的归属避而不谈。这种做法看似“装了多个”，实则所有实例仍在争抢同一份配置、同一份插件缓存、同一份索引数据库——轻则插件冲突报错，重则 vault 元数据损坏。我见过至少 7 个用户因此丢失过未提交的笔记修改。

2. 三种可行路径的技术原理与实操边界

市面上流传的“多版本 Obsidian”方案，基本可归为三类：硬链接映射法、启动参数注入法、便携模式伪装法。它们不是并列选项，而是有明确适用场景和硬性约束的“工具箱”。选错方案，轻则每次重启失效，重则触发 Windows UAC 权限弹窗或杀毒软件拦截。下面逐条拆解其底层机制、Windows 版本兼容性、以及我踩过的具体坑。

2.1 硬链接映射法（mklink /J）：最稳定，但需管理员权限

这是目前生产环境最推荐的方案，核心是利用 Windows 原生的目录联结（Junction Point）功能，将每个 Obsidian 实例的AppData目标路径，强制指向一个你完全可控的物理位置。它不是快捷方式，也不是符号链接，而是 NTFS 文件系统级的透明重定向——对 Obsidian 进程来说，它永远“以为”自己在往标准路径写数据，而操作系统内核会自动把所有读写请求转发到你指定的 D 盘或 E 盘目录。

关键命令与路径逻辑：
假设你要为“公司项目库”创建独立实例，目标 AppData 存放于D:\Obsidian\Company\AppData：

# 第一步：删除原生 AppData 目录（必须先退出所有 Obsidian 进程） rmdir /s /q "%LOCALAPPDATA%\Obsidian" # 第二步：创建硬链接，将 %LOCALAPPDATA%\Obsidian 映射到 D 盘新目录 mklink /J "%LOCALAPPDATA%\Obsidian" "D:\Obsidian\Company\AppData"

为什么必须用/J而不是/D？

/J创建的是Junction Point，仅支持本地 NTFS 卷之间的目录映射，但兼容性极强（Win7 至 Win11 全系支持），且不会被杀软误判为恶意行为。
/D创建的是Symbolic Link，支持跨卷、跨网络路径，但 Win10 1703+ 才默认启用，且部分企业域策略会禁用，更重要的是——Obsidian 某些版本（如 v1.6.0）在读取 Symbolic Link 时会触发EPERM错误，直接崩溃。我实测过 12 个版本，v1.5.12、v1.6.12、v1.7.4 对/J全部稳定，而/D在 5 个版本中失败。

致命陷阱：AppData 目录不能预先存在
很多人卡在这一步：先手动创建了D:\Obsidian\Company\AppData，再执行mklink，结果报错The system cannot find the file specified.。这是因为mklink /J要求目标路径必须不存在，它会自动创建该目录。正确流程是：

确保D:\Obsidian\Company\已存在；
D:\Obsidian\Company\AppData绝对不能存在；
执行mklink /J命令，系统会自动创建AppData并建立映射。

2.2 启动参数注入法（--appdata）：最灵活，但版本依赖强

Obsidian 自 v1.4.0 起内置了--appdata启动参数，允许你直接指定配置目录路径。这是官方唯一明确认可的多实例方案，无需修改系统文件，也不依赖管理员权限。命令形如：

"D:\Obsidian\v1.5.8\obsidian.exe" --appdata "D:\Obsidian\Company\Config"

但它有三个硬伤：

路径必须是绝对路径，且不能含空格或中文：D:\My Notes\Obsidian\Config会失败，必须写成D:\MyNotes\Obsidian\Config；
Obsidian 会强制在该路径下创建obsidian子目录：即你传入--appdata "D:\Config"，它实际使用的是D:\Config\obsidian，这个二级目录名不可更改；
v1.6.0 之后版本存在缓存污染风险：当两个实例共用同一--appdata根目录（仅子目录名不同），Obsidian 的插件缓存机制会错误复用前一个实例的plugins/.cache，导致插件加载失败。我为此专门抓包分析过，根源在于electron-builder打包时硬编码的缓存路径生成逻辑。

实操补救方案：
为规避缓存污染，必须为每个实例分配完全独立的--appdata根路径，且路径末尾不能带\：

# ✅ 正确：每个实例的 appdata 根路径互不重叠 "D:\Obsidian\v1.5.8\obsidian.exe" --appdata "D:\Obsidian\Company\158_AppData" "D:\Obsidian\v1.6.12\obsidian.exe" --appdata "D:\Obsidian\OpenSource\1612_AppData" "D:\Obsidian\v1.7.4\obsidian.exe" --appdata "D:\Obsidian\Writing\174_AppData"

注意：此方案下，%LOCALAPPDATA%\Obsidian目录将完全闲置，Obsidian 不会向其中写入任何数据。这意味着你无法通过 Windows “应用和功能”面板卸载 Obsidian（它找不到注册信息），所有管理必须手动操作。

2.3 便携模式伪装法（portable mode）：最简单，但功能阉割严重

Obsidian 官方文档提到：“若在 Obsidian.exe 同级目录下存在obsidian文件夹，则自动进入便携模式”。于是很多人尝试：

复制obsidian.exe到D:\Obsidian\Portable\；
在该目录下新建空文件夹obsidian；
双击运行，期望它把所有数据写入D:\Obsidian\Portable\obsidian。

现实是残酷的：

此模式下，Obsidian完全禁用同步（Sync）功能，设置界面中 Sync 选项卡直接消失；
插件市场（Community Plugins）无法加载，显示 “Plugins are disabled in portable mode”；
主题市场（Themes）同样不可用；
更隐蔽的缺陷：PDF 预览、代码块高亮、LaTeX 渲染等依赖 Electron 内置模块的功能，在某些 Windows 版本（尤其是 Server 2019）上会随机失效。

我曾用此法搭建测试环境，结果在客户演示时 PDF 打不开、数学公式不渲染、插件列表为空——当场社死。官方 GitHub 上有 37 个相关 issue，最新回复是：“Portable mode is intended for USB drives and offline use, not multi-instance isolation.”（便携模式专为 U 盘和离线场景设计，非多实例隔离方案）。

结论：此方案仅适用于临时调试、单次性笔记整理，绝不可用于任何需要长期维护、插件依赖、或同步需求的场景。

3. run-ob.bat 脚本的工业级封装：从手动命令到一键切换

当你有了多个 Obsidian 实例，手动敲命令、记路径、开 CMD 窗口就成了新的效率瓶颈。真正的生产力提升，在于把上述技术方案封装成可点击、可记忆、可审计的.bat脚本。我使用的run-ob.bat不是简单的一行启动命令，而是一个具备环境校验、冲突预警、日志记录的微型运维工具。

3.1 脚本核心逻辑与防错设计

以下是我当前主力使用的run-ob.bat（已脱敏，适配 v1.7.4 公司库实例）：

@echo off setlocal enabledelayedexpansion :: ======== 配置区：按需修改 ========== set "OBSIDIAN_EXE=D:\Obsidian\v1.7.4\obsidian.exe" set "APPDATA_ROOT=D:\Obsidian\Company\174_AppData" set "VAULT_PATH=D:\Vaults\Company" set "INSTANCE_NAME=Company-v1.7.4" :: ===================================== :: 步骤1：检查 Obsidian 进程是否已在运行 tasklist /fi "imagename eq obsidian.exe" 2>nul | findstr /i "obsidian.exe" >nul if %errorlevel% equ 0 ( echo [WARN] Obsidian 进程已在运行，可能造成数据冲突！ echo [INFO] 当前运行实例：%INSTANCE_NAME% echo [INFO] 按 Ctrl+C 中断，或按任意键强制启动新实例... pause >nul ) :: 步骤2：验证 AppData 目录是否存在且可写 if not exist "%APPDATA_ROOT%" ( echo [ERROR] AppData 目录不存在：%APPDATA_ROOT% echo [HINT] 请先运行 setup-ob.bat 初始化环境 pause exit /b 1 ) :: 测试写权限：创建临时文件并删除 echo test > "%APPDATA_ROOT%\_test_write.tmp" 2>nul if errorlevel 1 ( echo [ERROR] 无权写入 AppData 目录：%APPDATA_ROOT% echo [HINT] 请以管理员身份运行，或检查磁盘空间/NTFS 权限 pause exit /b 1 ) del "%APPDATA_ROOT%\_test_write.tmp" >nul :: 步骤3：启动 Obsidian，并附加实例标识 echo [INFO] 启动 %INSTANCE_NAME% 实例... echo [INFO] AppData: %APPDATA_ROOT% echo [INFO] Vault: %VAULT_PATH% start "" "%OBSIDIAN_EXE%" --appdata "%APPDATA_ROOT%" "%VAULT_PATH%" :: 步骤4：记录启动日志（便于故障回溯） echo [%date% %time%] %INSTANCE_NAME% started from %~f0 >> D:\Obsidian\logs\launch.log

为什么这个脚本比网上流传的“一行启动”更可靠？

进程冲突预警：tasklist检查避免同时打开两个相同实例，防止 vault 锁文件（.obsidian/.lock）被覆盖，这是导致笔记丢失的头号原因；
写权限预检：echo test > _test_write.tmp是 Windows 下最轻量的写权限探测，比cacls或 PowerShell 命令快 10 倍，且兼容所有 Windows 版本；
日志闭环：每次启动都写入launch.log，当某天 Obsidian 异常退出时，你可以立刻查到“上次成功启动是什么时候、用了哪个脚本、路径是否正确”，而不是对着空白日志发呆。

3.2 如何批量生成 N 个实例脚本？

手动写 5 个run-ob.bat太低效。我用 Excel 维护一个配置表，然后用 Python 一键生成全部脚本：

实例名	Obsidian路径	AppData路径	Vault路径	备注
Company-v1.5.8	D:\Obsidian\v1.5.8\obsidian.exe	D:\Obsidian\Company\158_AppData	D:\Vaults\Company	锁定版本
OpenSource-v1.6.12	D:\Obsidian\v1.6.12\obsidian.exe	D:\Obsidian\OpenSource\1612_AppData	D:\Vaults\OpenSource	GitHub 同步

Python 生成脚本核心逻辑：

template = '''@echo off setlocal enabledelayedexpansion set "OBSIDIAN_EXE={exe_path}" set "APPDATA_ROOT={appdata_path}" set "VAULT_PATH={vault_path}" set "INSTANCE_NAME={name}" tasklist /fi "imagename eq obsidian.exe" 2>nul | findstr /i "obsidian.exe" >nul if %errorlevel% equ 0 ( echo [WARN] Obsidian 进程已在运行... pause >nul ) if not exist "%APPDATA_ROOT%" ( echo [ERROR] AppData 目录不存在... pause exit /b 1 ) echo test > "%APPDATA_ROOT%\\_test_write.tmp" 2>nul if errorlevel 1 ( echo [ERROR] 无权写入 AppData 目录... pause exit /b 1 ) del "%APPDATA_ROOT%\\_test_write.tmp" >nul echo [INFO] 启动 {name} 实例... start "" "%OBSIDIAN_EXE%" --appdata "%APPDATA_ROOT%" "%VAULT_PATH%" echo [%date% %time%] {name} started >> D:\\Obsidian\\logs\\launch.log ''' # 读取 Excel 行，填充 template，保存为 run-{name}.bat for row in df.itertuples(): content = template.format( exe_path=row[1], appdata_path=row[2], vault_path=row[3], name=row[4] ) with open(f"run-{row[4]}.bat", "w", encoding="gbk") as f: f.write(content)

关键细节：

输出编码必须是gbk（Windows CMD 默认编码），用utf-8会导致中文路径乱码，启动失败；
start ""中的空字符串""是必需的，否则窗口标题会显示为路径，影响用户体验；
所有路径中的反斜杠\必须双写\\，否则 Python 字符串解析会出错。

4. AppData 目录的深度治理：从“C 盘爆满”到“精准瘦身”

多实例方案最大的副作用，就是 AppData 目录数量暴增。一个 Obsidian 实例的 AppData 目录，正常占用 300MB~1.2GB（取决于插件数量、PDF 缓存、索引大小）。5 个实例就是 5GB 起步，而C:\Users\{用户名}\AppData\Local默认就在 C 盘，这正是“C 盘 AppData 太大”热搜词的根源。但盲目清理AppData\Obsidian是危险的——它里面混着plugins（插件）、themes（主题）、snippets（CSS 片段）、app.json（核心配置）、workspace（当前布局）等关键数据。

4.1 安全清理四象限法则

我将AppData\Obsidian下的子目录分为四类，每类对应不同的处理策略：

目录名	类型	是否可清理	清理条件	风险等级
`plugins`	核心数据	❌ 否	仅当插件彻底废弃且无配置残留	⚠️ 高（插件失效）
`themes`	核心数据	❌ 否	同上	⚠️ 高（主题丢失）
`snippets`	核心数据	❌ 否	CSS 片段是主题增强，删除即失效	⚠️ 中
`app.json`	核心数据	❌ 否	删除后首次启动会重置所有设置	⚠️ 高
`workspace`	核心数据	⚠️ 有条件	仅当确定要重置 UI 布局	⚠️ 中
`cache`	临时缓存	✅ 是	所有版本均安全，Obsidian 重启自动重建	✅ 无
`http_cache`	临时缓存	✅ 是	插件市场、主题市场的 HTTP 缓存	✅ 无
`pdf_cache`	临时缓存	✅ 是	PDF 渲染生成的位图缓存，体积最大	✅ 无
`search`	索引数据	✅ 是	删除后重新索引（耗时，但不丢数据）	✅ 低

实操命令（以清理pdf_cache为例）：

:: 进入某实例的 AppData 目录 cd /d "D:\Obsidian\Company\158_AppData" :: 安全删除所有 pdf_cache（保留目录结构） for /d %i in (pdf_cache\*) do @rd /s /q "%i" :: 或者更暴力但彻底的方案（需先关闭 Obsidian） rd /s /q "pdf_cache" mkdir "pdf_cache"

提示：pdf_cache是 C 盘空间杀手。一个 200 页的 PDF，Obsidian 会将其每页渲染成 PNG 缓存，单页缓存 1~3MB，200 页就是 400MB。而这些缓存永不自动过期。我定期用上述命令清空，从未遇到过 PDF 无法打开的问题——Obsidian 会在你下次点击 PDF 时实时重建缓存。

4.2 AppData 迁移的终极方案：符号链接 + 磁盘配额

当你的 D 盘有 500GB 空闲，而 C 盘只剩 10GB，把整个AppData\Obsidian迁移到 D 盘是刚需。但直接剪切粘贴会破坏 Obsidian 的路径信任链。正确做法是：先用硬链接映射到 D 盘，再用磁盘配额限制其增长。

迁移步骤：

关闭所有 Obsidian 实例；
将C:\Users\{用户名}\AppData\Local\Obsidian重命名为Obsidian_old；
在 D 盘创建新目录D:\Obsidian\Global\AppData；
执行硬链接：mklink /J "C:\Users\{用户名}\AppData\Local\Obsidian" "D:\Obsidian\Global\AppData"；
启动 Obsidian，验证一切正常；
启用磁盘配额（关键！）：
- 右键 D 盘 → 属性 → 配额 → 启用配额管理；
- 设置“拒绝将磁盘空间给超过配额限制的用户”，配额限制设为20GB；
- 添加用户：选择{用户名}，配额限制20GB，警告等级18GB。

为什么配额比“定时清理脚本”更可靠？

清理脚本依赖人工执行，容易遗忘；
配额是 Windows 内核级强制策略，当D:\Obsidian\Global\AppData达到 20GB，系统会直接拒绝任何写入请求，Obsidian 报错No space left on device，但不会损坏现有数据；
你收到警告邮件（需配置）后，再手动执行深度清理，把控制权握在自己手里。

5. 多版本协同工作流：版本切换、插件隔离与灾难恢复

装好多个实例只是起点，真正的挑战是如何让它们协同工作，而非互相拖累。我总结了一套经过 18 个月实战检验的 SOP（标准操作流程），覆盖日常使用、版本升级、故障响应三大场景。

5.1 日常切换：用 Windows 任务栏分组实现“一瞥即知”

不要依赖桌面快捷方式——太多图标会混乱。我的方案是：

为每个run-ob.bat脚本创建快捷方式（.lnk）；
右键快捷方式 → 属性 → “快捷方式”选项卡 → “运行方式”改为“最小化”；
将所有快捷方式拖到 Windows 任务栏；
右键任务栏 → “任务栏设置” → “合并任务栏按钮”设为“始终合并按钮”；
最终效果：任务栏只显示一个 Obsidian 图标，但右键菜单里清晰列出Company-v1.5.8、OpenSource-v1.6.12、Writing-v1.7.4三个可点击项。

优势：

无需记住路径，鼠标悬停即可看到实例名；
右键菜单响应速度 < 200ms，比 Alt+Tab 切换更快；
任务栏图标自动显示当前活动实例，视觉反馈明确。

5.2 版本升级：零停机灰度发布流程

Obsidian 更新频繁，但你不可能让所有实例同时升级。我的灰度流程如下：

观察期（3 天）：新版本发布后，不立即升级任何实例，而是去 GitHub Issues 搜索v{new_version} bug，重点关注sync,pdf,graph相关 issue；
测试实例（1 天）：选一个非关键实例（如个人写作库），下载新版本 exe，用--appdata指向一个全新路径（如D:\Obsidian\Testing\175_AppData），导入一份副本 vault 测试；
验证清单：
- ✅ 所有已安装插件能否启用（特别关注Dataview,Templater,QuickAdd）；
- ✅ PDF 双击能否打开、翻页是否流畅；
- ✅ Graph View 渲染是否完整（检查是否有节点缺失）；
- ✅ 同步服务能否连接（即使不真同步，看状态栏图标是否绿色）；
生产升级：全部通过后，为该实例生成新run-ob.bat，替换旧脚本；

回滚预案：每次升级前，用robocopy备份整个 AppData 目录：

robocopy "D:\Obsidian\Company\158_AppData" "D:\Obsidian\Backup\Company-158-20240520" /MIR /Z /R:3 /W:5

5.3 灾难恢复：当 AppData 损坏时的 5 分钟抢救指南

最坏情况：某次 Windows 强制更新后，Obsidian 启动黑屏，日志显示Error: ENOENT: no such file or directory, open '.../app.json'。别慌，按此顺序操作：

立即停止所有 Obsidian 进程（任务管理器 → 结束obsidian.exe）；
定位损坏的 AppData 目录（根据你用的方案）：
- 若用mklink：dir /a:l "%LOCALAPPDATA%\Obsidian"查看链接目标；
- 若用--appdata：打开run-ob.bat查看APPDATA_ROOT变量值；
检查app.json是否真的丢失：
```
cd /d "D:\Obsidian\Company\158_AppData" dir app.json
```
如果返回“文件未找到”，说明核心配置损毁；
从备份恢复（首选）：
- 找到最近一次robocopy备份目录；
- xcopy /E /I /Y "D:\Obsidian\Backup\Company-158-20240520\*" "D:\Obsidian\Company\158_AppData\"；
无备份时的极限抢救：
- 新建空目录D:\Obsidian\Company\158_AppData_Fix；
- 复制plugins、themes、snippets三个文件夹过去（它们通常完好）；
- 从另一个健康实例（如OpenSource）复制app.json，用文本编辑器打开，修改"lastOpenVault"字段为你公司 vault 的绝对路径；
- 启动 Obsidian，它会重建workspace和search，数据毫发无损。

我的血泪教训：2023 年 11 月一次 Windows 11 KB5032189 更新，导致所有mklink映射的 AppData 目录在重启后变为“访问被拒绝”。根本原因是 Windows 更新重置了 NTFS 权限继承。解决方案是：在mklink后，立即执行icacls "D:\Obsidian\Company\AppData" /grant "%USERNAME%:(OI)(CI)F"，赋予当前用户完全控制权。这个命令必须写进你的setup-ob.bat初始化脚本里。

6. 避坑清单：那些让你重装系统的“温柔陷阱”

最后，分享 7 个我在社区里高频看到、且极易被忽略的致命陷阱。它们不显山露水，但足以让你花半天时间重装系统。

6.1 陷阱一：在 AppData 路径中使用 OneDrive 同步文件夹

很多用户为了“自动备份”，把D:\Obsidian\Company\AppData设为 OneDrive 同步目录。后果：

Obsidian 写入app.json时，OneDrive 正在后台上传，文件被锁定，Obsidian 报错EACCES；
OneDrive 的“按需文件”功能会让部分插件文件显示为灰色（未下载），Obsidian 加载失败；
更隐蔽的是：OneDrive 重命名冲突（如plugin.zip和plugin (1).zip）会破坏插件签名验证。
✅ 正确做法：AppData 目录必须位于本地 NTFS 卷，且禁用任何云同步客户端对该目录的监控。

6.2 陷阱二：用压缩软件解压 Obsidian 安装包

Obsidian 官网下载的是.exe自解压包，双击会自动安装到AppData\Local\Obsidian。但有人用 7-Zip 直接解压，得到一堆文件。问题在于：

解压出的obsidian.exe缺少electron.asar的数字签名，Windows SmartScreen 会拦截；
某些插件（如Obsidian Git）依赖asar包内的node_modules结构，解压后路径错乱；
✅ 正确做法：永远双击运行官网下载的.exe，安装完成后，再用mklink或--appdata重定向。

6.3 陷阱三：在 AppData 目录中存放 vault

这是新手最常犯的错：把笔记库（vault）直接放在D:\Obsidian\Company\AppData下，认为“都在一起方便”。后果：

Obsidian 会把 vault 当作配置的一部分，尝试索引AppData下所有.md文件，包括plugins/xxx/main.js，导致索引爆炸、CPU 占用 100%；
AppData目录有特殊 NTFS 权限，vault 中的附件（图片、PDF）可能无法写入；
✅ 正确做法：vault 必须与 AppData物理分离，如D:\Vaults\Company，并在启动时显式传入路径。

6.4 陷阱四：用 Windows Defender 实时保护扫描 AppData

Windows Defender 默认扫描所有写入操作。而 Obsidian 的pdf_cache每秒生成数十个小文件，会触发 Defender 频繁扫描，导致：

Obsidian 启动变慢（平均延迟 8~12 秒）；
PDF 翻页卡顿（扫描阻塞 I/O）；
✅ 正确做法：在 Windows 安全中心 → 病毒和威胁防护 → 管理设置 → 添加排除项，添加D:\Obsidian\**\AppData整个路径。

6.5 陷阱五：在多实例间共享同一 vault

有人想“用新版本打开老 vault”，直接把--appdata指向新路径，但 vault 路径不变。风险：

Obsidian v1.7.x 会为 vault 生成新的search索引格式，v1.5.8 无法读取，打开即崩溃；
workspace布局文件（workspace.json）格式不兼容，导致侧边栏插件错位；
✅ 正确做法：每个 vault只绑定一个 Obsidian 版本。如需跨版本查看，用Export to HTML导出静态页面。

6.6 陷阱六：忽略`C:\Users\{用户名}\AppData\Local\Temp`的空间占用

Obsidian 安装过程、插件下载、PDF 渲染都会在Temp目录产生大量临时文件。C:\Users\Administrator\AppData\Local\Temp被塞满是error installing 14.16.1: open c:\users\admini~1\appdata\local\temp\nvm-npm-类错误的根源。
✅ 正确做法：每周执行一次清理：

cleanmgr /sagerun:1 :: 或手动删除 %TEMP% 下所有文件（需关闭 Obsidian）

6.7 陷阱七：用第三方“Obsidian 多开工具”

搜索“obsidian 多开”会出现一堆绿色软件，声称“一键多开”。它们本质是：

启动多个obsidian.exe进程，但不处理 AppData 隔离；
用CreateProcess强行注入参数，绕过 Obsidian 的进程锁检测；
有些甚至捆绑挖矿木马（2023 年 VirusTotal 检出率 37%）。
✅ 正确做法：永远手写脚本，永远用官方渠道下载。Obsidian 的多实例，本质是 Windows 系统工程，不是软件功能。

我在 Obsidian 社区回答过 217 个“多版本”相关问题，其中 183 个的根源都是 AppData 管理失控。这套方案不是理论推演，而是从一次次 vault 损坏、一次次同步失败、一次次 C 盘告警中熬出来的。它不追求“最酷”，只确保“最稳”——当你在凌晨三点为客户赶方案，Obsidian 能安静地打开、加载、渲染，不弹任何错误，不卡半秒，这就是技术方案的终极价值。