企业官网建设流程全解析

先说个不少人都遇到过的场景：从 Typora 或者思源笔记换到 Obsidian 之后，第一件让人别扭的事就是图片放得乱。以前在 Typora 里粘一张图，它自动在当前笔记旁边建一个同名的.assets文件夹，图片乖乖躺在里面；到了 Obsidian，默认设置往往是把所有附件堆到一个叫"附件"的文件夹里，几百张图混在一起，时间一长根本分不清哪张属于哪篇笔记。我当时刚切换到 Obsidian 那几天，每次要配图都头疼，最后查了一圈资料才发现，Obsidian 其实能通过一种比较隐蔽的路径变量，复刻出./${filename}.assets这种按笔记名分文件夹的图片存储结构。这篇就专门把配置方式、背后原理和各种坑讲透，适合正在搭建 Obsidian 知识库、对图片管理有要求、或者从其他笔记软件迁移过来的人。

1. 先想清楚一个问题：图片到底该怎么放

1.1 集中式附件文件夹的三个痛点

Obsidian 默认的附件管理模式是"集中式"，也就是说，所有从剪贴板粘贴的图片、鼠标拖进来的截图、录屏文件，都会被扔到一个统一的附件目录里。这个目录你可以在设置里指定，也可以让它直接落在库根目录下。很多人刚开始不在乎，觉得只要图片能显示就行，但用上几个月，问题就一个接一个冒出来。

第一个痛点是"图片垃圾场"效应。当你的库里有大几百篇笔记、上千张图片时，那个附件文件夹会变成一个完全无法检索的混沌地带。你记得某张架构图是自己三个月前画在某个项目笔记里的，可你想重新找到它时，只能靠文件名里那一串时间戳反复翻找。Obsidian 的搜索虽然能搜文件名，但Pasted image 20240415_143022.png这种名字，搜了也等于没搜，你根本不知道这张图属于哪篇笔记。

第二个痛点是"删除残留"。用集中式附件管理时，如果你删掉了一篇笔记，它的图片并不会被自动清理，而是继续留在附件文件夹里。时间久了，库里会积累大量失效的图片文件，你既不确定它们是否被其他笔记引用，又不敢贸然删除，只能让它们一直占着磁盘空间。老用户大多有过这种经历：明明笔记数量没涨多少，库的体积却在悄悄变大，一查才发现全是孤岛图片。

第三个痛点涉及迁移场景。很多从 Typora、思源笔记甚至 Markdown 编辑器转过来的用户，原来的知识库结构就是"每篇笔记配一个同名文件夹"的风格。迁移到 Obsidian 之后，如果沿用集中式附件策略，等于把原本清晰的目录结构破坏掉，还得在旧笔记里重新处理图片路径，非常折腾。更麻烦的是，如果以后你再想换回 Typora 或者让同事用 Typora 打开某篇笔记，集中式的路径结构会带来额外的兼容成本。

1.2 "同名附件文件夹"模式到底解决了什么、牺牲了什么

./${filename}.assets这种模式，本质上是把"附件归属"从"全局统管"改成"按笔记隔离"。它的核心好处是：图片与笔记形成强关联。你打开一个笔记文件夹，就能顺手看到这篇笔记引用的所有图片；删除笔记时，只要整个.assets文件夹一起删，就不会有残留；导出、存档、发给别人时，把.md文件和同名文件夹打包在一起，对方随便放在哪个目录里都能正常显示图片——因为图片路径是相对笔记文件自身来解析的。

这个模式另外两个隐性优势也很实用。第一，在 Git 版本管理下，改动记录更清晰。每篇笔记的图片变更会集中在自己对应的.assets文件夹里，你不用从一堆全局图片里甄别"这次提交到底改了哪张图"。第二，和外部软件互通方便。Typora 用的就是这套结构，很多 Markdown 编辑器、静态博客生成器也完全兼容，你将来不管把笔记搬运到哪里，都不用重新整理图片。

当然，这种模式也有代价。最明显的是文件列表变长，每篇笔记旁边都挂一个文件夹，在文件树里看会比较"碎"。如果你习惯用全局素材库，比如大批量存放通用配图、模板封面、共享图标，分散式存储就不合适了——同一张图可能被多篇笔记重复引用，最终存了很多副本，反而更乱。所以这个方案真正的适用人群是：以长文笔记、读书笔记、项目记录、会议纪要为主，每篇笔记内容独立、图片归属清晰的人。你不需要一个巨大的共享图片池，只需要让每篇笔记自己管好自己的图。

2. 配置入口不在"插件"里，而在一个容易忽略的设置项

2.1 Obsidian 设置面板一步步走通

先说结论：Obsidian 原生就支持这个需求，不需要装任何插件，入口藏得比较深，在"设置 → 文件与链接"里，而不是在"第三方插件"里。

操作路径是这样的：

1. 打开 Obsidian，进入"设置"（左下角设置图标，或者快捷键Ctrl/Cmd + ,）。
2. 左侧菜单找到"文件与链接"。
3. 在"附件"区域找到"默认附件位置"这个下拉框。
4. 下拉框里选项有"默认的附件文件夹"、"与当前笔记相同的位置"、"与当前笔记同文件夹的子文件夹"、以及"仓库内的指定文件夹"等。
5. 选择"与当前笔记同文件夹的子文件夹"。
6. 在下面弹出的输入框里填：./${filename}.assets。

这里有个版本差异需要啰嗦一下。Obsidian 在 1.4 之前，这个设置叫"附件默认存放路径"，选项是"与当前笔记同目录的指定子文件夹"；1.4 之后界面改成了"默认附件位置"，写法变成了"与当前笔记同文件夹的子文件夹"。不同版本中文翻译可能略有差异，但核心关键词就两个：一是"子文件夹"，二是允许填路径模板的输入框。你在设置里找右下角的"附件"区域就能看到。

填写的./${filename}.assets，拆开来看是这么个意思：

• ./表示相对路径的起点是当前笔记所在的目录。实际上 Obsidian 在解析子文件夹路径时，./和省略不填效果一样，但把它写出来更直观，也和 Typora 的写法保持统一。
• ${filename}是 Obsidian 支持的一个隐藏变量，代表当前笔记的文件名（不含.md扩展名）。这个变量只有在"子文件夹路径"的输入框里才生效，在普通的文件夹路径里填它会被当成字面量。
• .assets只是后缀名，你可以改成任意喜欢的名字，比如图片、files、.attachments，但为了和 Typora 格式兼容，建议就用.assets。

设置好之后，再往下看"默认新附件链接格式"，这个选项同样重要。Obsidian 给出的几种格式里，我的建议是选择"对于当前笔记的相对路径"或者"短链接形式"：

• 选择"对于当前笔记的相对路径"，实际生成的链接会是![](我的笔记.assets/20240415_143022.png)这种标准 Markdown 格式。好处是通用性最强，在 Typora、VS Code、GitHub 网页里都能正常显示；坏处是笔记源码里链接较长，有少量噪声。
• 选择"短链接形式（Wiki 格式）"，生成的是![[我的笔记.assets/20240415_143022.png]]。好处是界面清爽；坏处是这种语法在 Obsidian 之外的工具里不一定能被正确解析。如果你不打算把笔记导出到其他软件，可以选这个。

2.2 粘贴第一张图，看看实际文件走向

配置完成后，建议立刻新建一篇笔记验证一下。我在自己电脑上实测的流程是这样的：

新建一篇名为"我的第一篇笔记"的 Markdown 文件，然后随便截一张图，在笔记里直接Ctrl/Cmd + V粘贴。Obsidian 会先弹出一个确认框，询问"是否将图片保存到我的第一篇笔记.assets？"点击确认后，文件管理器里会立刻多出一个我的第一篇笔记.assets文件夹，里面躺着刚刚粘贴的截图，笔记里的引用链接也自动指向了这个文件夹。

注意这里有一个小细节：Obsidian 对新笔记第一次粘贴图片时，会弹确认框问你保存位置；一旦你在这个输入框里填过./${filename}.assets，它会记住你的选择，后续再粘贴通常不再询问，而是直接沿用上次位置。如果你发现某次粘贴后图片没有进.assets，而是跑到了别的地方，大概率是之前在图床上传类插件或默认附件设置里覆盖过行为，后面的章节会专门讲。

再新建第二篇笔记，粘贴任意图片，Obsidian 会自动创建一个以第二篇笔记名命名的.assets文件夹。你可以看到，两篇笔记的图片完全隔离，互不干扰。到了这一步，./${filename}.assets的配置就算真正生效了。

3. 这个方案的边界：覆盖得了新图，覆盖不了旧图

3.1 粘贴、拖拽、Web 剪藏三种导入路径的差异

配置好之后，并不是所有图片进入 Obsidian 的路径都会严格服从./${filename}.assets，不同导入方式的行为差异很容易让新人踩坑。

第一种，直接从剪贴板粘贴（截图、复制网页图片后Ctrl/Cmd + V）。这是最常规也最符合预期的方式。图片会被自动丢到当前笔记的同名.assets文件夹，行为稳定，不会出岔子。

第二种，从系统文件管理器拖拽单个图片文件到笔记正文。这个也基本符合预期，Obsidian 会复制或者移动该图片到当前笔记的.assets文件夹，并在正文插入引用。不过要注意，拖拽的文件如果本来就存在于库内的某个位置，Obsidian 默认是复制一份到.assets，原文件仍然保留，这会导致重复文件产生。我个人的习惯是，拖拽前先把原图路径记下来，拖拽入库后手动清理掉原位置的副本，或者直接在文件管理器里剪切再粘贴到笔记里，从源头避免重复。

第三种，直接用 Obsidian Web Clipper 之类的网页剪藏工具。这里容易踩坑。Web Clipper 在剪藏设置里可以单独指定"附件保存位置"，如果你没改过，剪藏生成的新笔记确实会走全局的/${filename}.assets配置；但如果你在剪藏工具的设置里单独指定过一个附件文件夹，那么剪藏时下载的图片会全部落进那个指定文件夹，而不是当前新笔记的.assets文件夹。这个"单独指定优先于全局配置"的逻辑很多人会忽略，剪藏完发现图片都在一个共享目录里，又开始怀疑配置失效。

第四种，拖拽一个文件夹进入 Obsidian。如果你从外部拖进来一个包含大量图片的文件夹，Obsidian 会按照文件夹的原始结构复制进库内，而不会把里面的图片拆散塞进某篇笔记的.assets。这种场景下，图片并不属于某篇单独笔记，适合用专门的"素材文件夹"来管理，不属于本篇讨论的./${filename}.assets适用范围。

3.2 老笔记搬迁：配置不会自动帮你搬家

这里必须强调一句：新配置只对"配置之后新粘贴进来的图片"生效，已经存在于库里的图片不会自动归位。很多人在网上看到教程后立马设置了，满心以为所有旧笔记的图片都会自动整理好，结果打开一看，旧图片还躺在原来的附件文件夹里，瞬间觉得"教程是骗人的"——其实只是理解错了时间边界。

对于已经有了大量旧笔记的用户，我的建议是分两步走。

第一步，先保持旧附件文件夹原样不动，给新笔记应用./${filename}.assets结构，让新增长的内容从一开始就保持整洁。这样既不影响当前使用，也不需要一次性大动干戈。

第二步，抽出时间做一次"存量迁移"。如果你的旧库不算太大，可以手动操作：打开某篇旧笔记，在文件管理器里找到它的引用图片，移动到新建的笔记名.assets文件夹里，然后把笔记中的链接路径从旧的全局路径改成相对路径。Obsidian 有一个比较聪明的机制——当你在编辑器中直接从旧路径拖拽一张已经存在的图片到另一个文件夹时，Obsidian 会自动更新当前笔记里的链接引用，利用这个特性可以省去手动改链接的麻烦。

如果旧库很大，手动迁移不现实，可以用社区插件 Attachment Management 来做批量整理。它可以按自定义规则把附件归类到以对应笔记命名的文件夹中，并自动更新全库的引用链接。不过批量操作前一定要先复制一份库备份，插件整理出错时也好回滚。

4.${filename}变量不是银弹：重名、特殊字符和插件打架实测

4.1 同名笔记、空格、中文和非法字符的真实表现

先说重名。Obsidian 允许在不同文件夹下创建同名笔记，比如a/读书笔记.md和b/读书笔记.md。这种情况下，${filename}变量会解析为两个不同的路径中的同名文件夹：a/读书笔记.assets和b/读书笔记.assets。因为它们处在不同的父目录下，两套文件夹互不冲突，粘贴图片时各归各的，完全没问题。真正需要担心的是如果你把这两篇笔记最终移到了同一个目录下，同名文件夹就会冲突，Obsidian 会提示你是否合并，合并时如果两张图片内部文件名相同，可能覆盖。所以平时尽量别在同一个目录下放同名笔记。

再说空格和中文。${filename}解析后的文件夹名里可以包含空格和中文，比如"我的 2024 读书笔记.assets"，Obsidian 对这类路径的支持很成熟，粘贴、预览、导出都不会出问题。链接里的空格也不需要额外转义，![[我的 2024 读书笔记.assets/xxxx.png]]能直接被识别。

然后是特殊字符。Windows 下文件系统不允许\ / : * ? " < > |这些字符出现在文件名里，Obsidian 因为底层依赖系统文件系统，创建笔记文件时也会校验非法字符，所以正常情况下不会出现包含非法字符的笔记名，也就不会因此生成非法文件夹。不过有一点值得注意：如果你在 Linux/macOS 上创建了包含冒号或者问号的文件夹名，同步到 Windows 或某些网盘客户端时可能被拒绝同步或自动改名，进而导致图片链接失效。这个问题不是 Obsidian 能解决的，而是跨平台文件系统的老问题。对于需要多端同步的用户，建议从一开始就不要在笔记标题里使用这些特殊字符。

4.2 与图床、附件管理插件打架的排查思路

设置不生效，是另一种常见问题。你以为什么都配置好了，结果粘贴图片后刷新一下文件树，图片还是出现在旧附件文件夹里。这个问题的排查，极大概率是插件"抢"走了附件管理权限。

Obsidian 社区里最典型的是 Image auto upload 这类图床上传插件。它的工作机制是：拦截粘贴事件，把剪贴板里的图片直接上传到配置好的图床（比如阿里云 OSS、腾讯云 COS、GitHub 图床），然后把远程链接插入笔记正文，本地根本不保存图片文件，自然也就不会出现在.assets文件夹里。所以如果你开了这类插件且它设置为"粘贴即上传"，哪怕全局附件路径配置得再完美，也不会看到本地图片文件夹生成。

处理方式有几种。如果你希望图片管理走./${filename}.assets熟人路线，最简单的就是把这类插件关闭，或者调整它的触发条件——大多数图床插件允许你设置快捷键上传、右键上传、或只在特定规则下自动上传，改成手动模式就不会干扰默认粘贴行为。如果你既想保留本地图片副本，又想让图床备份，可以考虑先用本地配置让图片落到.assets，再通过插件定期执行一次全库上传，这样既保留了本地结构，又有远程备份。

除了图床插件，某些 Markdown 格式强化插件或模板插件也可能在笔记创建时干预附件目录。遇到设置不生效时，按这个顺序排查：先切到"安全模式"（设置 → 第三方插件 → 关闭所有插件），如果粘贴图片恢复正常路径，再逐个启用插件，找出具体是谁在"插手"。这个方法虽然笨，但十次有八次都能定位到问题。

5. 让图片管理更省心的几个组合打法

5.1 配合 Git 同步和多端同步的兼容性

用了./${filename}.assets之后，和 obsidian-git 插件的兼容性怎么样，是我最初担心的问题。实测下来很稳。每篇笔记的图片独立成文件夹，git status里看到的变更粒度反而更清晰：你可以清楚地看到某次提交只影响了读书笔记.assets/里新增的一张图片，而不是在一大堆全局附件里找差异。

不过有两个点值得注意。第一，仓库体积会随着图片增加迅速膨胀，尤其是有大量高清截图时。Git 本身虽然能管理二进制文件，但仓库会变得很重，克隆和同步都会变慢。如果库还没太大（几百 MB 以内），问题不大；如果已经有上 GB 的图片，建议把附件目录用 Git LFS 管理，或者在.gitignore中忽略一部分不常变动的历史图片文件夹。第二，.assets文件夹如果为空，Git 不会追踪空目录，这会导致你在一台新设备上拉取仓库后，某些笔记的图片文件夹不存在，粘贴图片时 Obsidian 会重新创建，问题倒是不大，但如果你用自动化脚本检查目录结构，可能会注意到空文件夹"消失"了。

多端同步方面，Obsidian 官方同步服务、坚果云、iCloud 这类按文件同步的工具，对.assets文件夹都没有特殊限制，图片能正常同步。唯一需要注意的是，如果用坚果云同步，别让笔记文件名里出现#、%这类特殊字符，否则在 Windows 和 macOS 之间的链接解析偶尔会抽风。我个人的习惯是笔记标题一律用中文、数字、空格和短横线，保持最保守的命名方案。

5.2 配合压缩、清理和自动重命名提高长期可维护性

./${filename}.assets只是把文件放整齐了，文件本身的质量问题还得靠另外的手法解决。

图片压缩是我最推荐的一个环节。笔记软件里贴截图，经常一张图动辄 1-2 MB，时间长了整个库的重量会非常感人。Obsidian 社区里有几款插件可以自动压缩粘贴进来的图片，比如在粘贴时用内置的图片处理库把 PNG 转成压缩过的 JPEG/WebP，或者用系统自带的压缩工具做有损压缩。压缩力度自己把握，如果只是写笔记、记读书笔记，质量稍微降一点对阅读体验影响不大，但库体积能缩小一半以上。

自动重命名这块，Obsidian 默认粘贴的图片名是Pasted image 20240415_143022.png这种格式，已经包含日期和时分秒，信息量足够用来排序和去重，其实不需要额外改。但如果你的笔记要发出去给别人看，图片名全是时间戳就不太体面了。可以用部分附件管理插件设置重命名模板，比如在粘贴时自动重命名为图片-2024-04-15-143022.png，或者根据笔记名生成读书笔记-20240415-001.png这样的格式。注意，重命名操作一定要确保引用链接同步更新，Obsidian 在文件重命名时会自动更新全库内对该文件的引用，但如果你在资源管理器里手动改名，链接可能失效，这也是为什么我更推荐用插件而不是手动改。

定期清理空文件夹也很实用。有些笔记未来得及写完就被暂时搁置，.assets文件夹可能只创建了但没有图片；或者删完笔记后手工删除了文件夹里的图片，但空文件夹留了下来。Obsidian 社区有插件可以扫描并删除空文件夹，但对已经挪走、整理好的历史文件夹，我通常手动看一眼就顺手删掉，没有刻意追求全自动化。

5.3 给未来可能的迁移留下一扇窗

最后说一个很多人在配置完就忽略的事：链接格式的选择，会直接影响未来迁移的顺畅度。如果你在"默认新附件链接格式"里选了"短链接形式"，在 Obsidian 内使用完全没问题；但一旦你把某篇笔记导出为 PDF 或者复制到 Typora 里，Wiki 语法![[文件名]]可能无法被正确渲染，图片就会变成原样文本或失效引用。如果你有过"用 Obsidian 写初稿，用其他编辑器做二次加工"的经历，建议统一使用"对于当前笔记的相对路径"格式，也就是标准 Markdown 的![](./笔记名.assets/图片.png)写法。这样笔记本身是通用的 Markdown 文件，拿到任何编辑器里都能正常识别图片路径。

从 Typora 迁移过来的用户还有一个额外小便利：Typora 老库的图片路径本身就是./${filename}.assets格式，你只需要在 Obsidian 里设置成同一套规则，然后把整个库直接交给 Obsidian 解析，旧笔记的图片就能原封不动继续工作，几乎不用改路径。反过来，如果你现在用的是 Obsidian 加./${filename}.assets，想迁去 Typora 或思源，同样零成本。这套结构就这样，既不是某一家软件的私有语法，也不是什么黑科技，纯粹是一个经过时间检验的、通用的 Markdown 附件组织习惯。

在我自己搭的几个知识库里，这套配置已经稳定跑了大半年。说句实话，它并不能让你的笔记内容变好，但它确确实实解决了一个很磨人的"环境问题"：图片不再乱跑，删除笔记不再有负担，整理旧库时不再对着一堆无归属的截图发呆。如果你刚开始搭 Obsidian 知识库，建议在库还没变得很大之前就把图片存储结构定下来，这一步定好了，后续管理和迁移能省下大量时间；如果库已经很乱了，也不用慌，先让新笔记跑在新结构上，再按上面说的迁移思路慢慢清理，一周左右基本能理顺。