踩坑篇：打造iCloud + Obsidian + Hexo + Git 多端同步与自动化的博客写作系统

在现代数字时代，搭建一个高效、跨平台的博客写作系统是许多创作者的追求。我的目标是利用 Obsidian 作为写作工具，Hexo 作为博客框架，通过 iCloud 实现多端同步，并借助 Git 完成自动化部署。然而，这个看似完美的组合在实践中却充满了挑战。我踩过无数坑，浪费了大量时间，才最终摸索出一套稳定的解决方案。这篇文章将详细记录我的踩坑经历、解决方案和实用建议，帮助你少走弯路，顺利搭建属于自己的博客系统。本文约 3000 字，涵盖从问题分析到完整实现的全过程。

为什么选择这个组合？

在动手之前，我想先说明为什么要选择 iCloud + Obsidian + Hexo + Git 这个组合：

Obsidian：一款强大的 Markdown 笔记工具，支持插件扩展，适合写作和知识管理。
iCloud：苹果生态的云存储服务，能在手机、平板和电脑间无缝同步文件。
Hexo：轻量、快速的静态博客框架，生成 HTML 文件后可部署到任何服务器。
Git：版本控制神器，配合远程仓库（如 GitHub）实现博客的自动化部署。

我的需求是：随时随地写作（多端同步），并将博客自动化部署到服务器。理论上，这个组合可以完美满足需求，但实践中的坑让我深刻认识到，工具的强大并不能掩盖配置不当带来的麻烦。

踩坑经历：从混乱到崩溃

以下是我在搭建过程中的主要踩坑经历，每个问题都让我头痛不已，但也为最终方案提供了宝贵经验。

1. iCloud 与 Obsidian 的同步问题

最初，我希望利用 iCloud 实现 Obsidian 的多端同步。想法很简单：把 Markdown 文件放在 iCloud 上，手机和电脑通过 Obsidian 实时编辑。然而，问题很快显现：

文件路径不匹配：Obsidian 在 iCloud 中的文件路径（如 iCloud Drive/blog/source）与 Hexo 要求的 source 目录结构不一致。Hexo 默认从项目根目录下的 source 文件夹读取文章，而 iCloud 的嵌套路径导致 Hexo 无法识别。
同步延迟：iCloud 的同步并非实时，尤其在网络不稳定时，手机上的修改可能需要几分钟甚至更久才能反映到电脑，严重影响写作流畅性。
版本冲突：如果手机和电脑同时编辑同一文件，iCloud 的版本管理能力较弱，有时会覆盖最新修改，有时甚至生成副本（如 文件 (副本).md），让我手动合并内容。

教训：iCloud 适合轻量级笔记同步，但与 Hexo 的集成需要额外调整，且在高频操作下稳定性不足。

2. Git 同步带来的冲突噩梦

为了解决 iCloud 的问题，我引入了 Git，通过 Obsidian 的 Git 插件管理博客源文件，并实现多端同步。然而，这反而让情况变得更糟：

高频推送冲突：Obsidian Git 插件默认每分钟自动提交和推送（commit 和 push）。与此同时，服务器上也有自动提交脚本，两端频繁操作导致 Git 分支分叉，推送经常被远程仓库拒绝。
手动解决冲突：多设备同时编辑同一 Markdown 文件时，Git 合并冲突频发。每次冲突都需要手动打开文件，找到差异部分（<<<<<<< HEAD 和 >>>>>>>），耗时又烦人。
脚本逻辑缺陷：服务器端的自动化脚本只负责提交和推送，却没有在操作前拉取远程更新（git pull）。结果，本地和远程仓库状态不一致，推送失败成了家常便饭。

教训：Git 是强大的版本控制工具，但在多端实时同步和高频提交场景下，冲突管理复杂，体验极差。

3. 自动化脚本的反复调试

为了实现博客的自动化部署，我在服务器上编写了监控文件变化并自动提交、推送的脚本。然而，脚本的不完善让我陷入了无尽的调试循环：

缺少拉取步骤：脚本只执行 git add、git commit 和 git push，没有在提交前执行 git pull，导致远程仓库的更新无法同步到本地，推送失败。
错误处理不足：脚本没有检查命令的执行结果，失败时没有任何提示。问题累积后，我需要逐行排查日志，费时费力。
资源占用过高：服务器频繁运行 hexo generate 和 hexo deploy，每次生成静态文件都占用大量 CPU 和内存，影响其他服务的正常运行。

教训：自动化脚本如果逻辑不完善，反而会成为问题源头，增加维护成本。

4. iCloud 与 Git 的双重同步混乱

最让我崩溃的，是试图同时使用 iCloud 和 Git 来同步和管理文件，结果两者的机制相互干扰：

文件状态不一致：iCloud 检测到文件变化后同步到本地，触发 Git 脚本提交。但 Git 的提交又会修改文件时间戳，导致 iCloud 误认为文件被再次更新，陷入同步死循环。
忽略文件问题：Obsidian 生成的临时文件（如 .obsidian 目录）被 Git 正确忽略，但 iCloud 会无差别同步这些文件，导致远程仓库中出现不必要的冗余和冲突。

教训：两种同步机制混用容易导致混乱，必须明确分工或选择其一。

解决方案：从混乱到稳定

经过反复尝试，我最终找到了一套可行的方案：iCloud 负责高频同步源文件，Git 负责低频部署静态文件。以下是具体实现步骤和优化后的工作流。

1. 优化多端同步

为了解决同步问题，我明确了 iCloud 和 Git 的分工：

iCloud 同步源文件：将博客的 source 目录（包含所有 Markdown 文件）和 Obsidian 的配置目录（.obsidian）放入 iCloud。手机和电脑通过 iCloud 实时同步，Obsidian 直接编辑 iCloud 中的文件。
Git 管理静态文件：在本地运行 hexo generate 生成 public 目录（静态 HTML 文件），然后通过 Git 低频推送（例如每小时一次）到远程仓库。服务器定时拉取 public 并部署。

实现步骤：

在电脑上将 Hexo 项目目录移动到 iCloud（如 iCloud Drive/blog）。
在手机上安装 Obsidian，打开 iCloud 中的 blog/source 目录，编辑 Markdown 文件。
在电脑上运行 hexo generate，生成 public 目录。
使用 Git 将 public 推送至远程仓库（如 GitHub）。

优势：iCloud 负责高频、实时的源文件同步，Git 只处理低频的静态文件更新，大幅减少冲突和维护成本。

2. 改进自动化脚本

为了实现自动化，我分别在本地和服务器上编写了脚本，确保流程顺畅。

本地监控脚本（Windows PowerShell 示例）

在电脑上监控 iCloud 目录的变化，自动生成静态文件：

# 设置博客目录路径
$blogPath = "E:\iCloud Drive\blog"

# 创建文件系统监控器
$watcher = New-Object System.IO.FileSystemWatcher
$watcher.Path = $blogPath
$watcher.IncludeSubdirectories = $true
$watcher.EnableRaisingEvents = $true

# 定义文件变化时的操作
$onChange = Register-ObjectEvent $watcher "Changed" -Action {
    Set-Location $blogPath
    Write-Host "检测到文件变化，正在生成静态文件..."
    & hexo generate  # 生成 public 目录
}

# 持续运行监控
Write-Host "开始监控 $blogPath ..."
while ($true) { Start-Sleep -Seconds 5 }

服务器拉取脚本（Linux Bash 示例）

在服务器上设置定时任务，定期从 Git 仓库拉取静态文件并部署：

#!/bin/bash
# 进入网站目录
cd /var/www/blog/public

# 拉取最新静态文件
git pull origin main

# 检查是否成功
if [ $? -eq 0 ]; then
    echo "部署成功：$(date)"
else
    echo "部署失败：$(date)"
    exit 1
fi

将此脚本添加到定时任务（crontab -e）：

1 2	# 每小时拉取一次 0 * * * * /path/to/deploy.sh >> /var/log/blog_deploy.log 2>&1

优势：本地脚本实时生成静态文件，服务器脚本定时部署，逻辑清晰且资源占用低。

3. 完整工作流

优化后的工作流如下：

写作：在手机或电脑的 Obsidian 中编辑 iCloud 上的 Markdown 文件，实时同步。
生成：电脑检测到文件变化，自动运行 hexo generate，生成 public 目录。
推送：手动或定时通过 Git 将 public 推送到远程仓库。
部署：服务器定时从 Git 仓库拉取 public，更新网站内容。

实用避坑建议

以下是我总结的一些实用建议，避免你在搭建过程中重蹈覆辙：

1. 降低 Git 推送频率

如果使用 Obsidian Git 插件，将自动推送间隔设置为 5-10 分钟，或关闭自动推送，改用手动同步（Ctrl + P 输入 Git: Push）。
高频推送只会增加冲突风险，尤其在多设备操作时。

2. 先拉取再提交

在任何脚本或手动操作中，确保 git pull 在 git commit 之前运行，保持本地与远程仓库一致。

示例命令：

git pull origin main
git add .
git commit -m "Update blog"
git push origin main

3. 明确分工

源文件（Markdown 和 .obsidian）用 iCloud 同步，静态文件（public）用 Git 管理，避免两者功能重叠。
在 .gitignore 中忽略 iCloud 无关文件：
1
2
3
.obsidian/
node_modules/
public/

4. 定期检查

长时间编辑后，手动执行 git pull 和 git push，确保同步无误。
检查服务器日志，确认部署是否成功。

5. 优化资源使用

在服务器上限制 hexo generate 的频率，避免频繁生成静态文件占用过多资源。
使用轻量级主题（如 Hexo 的 landscape），减少生成时间。

总结与反思

通过 iCloud + Obsidian + Hexo + Git 的组合，我最终实现了多端同步与自动化部署的目标。但这个过程并非一帆风顺：iCloud 的同步延迟、Git 的冲突频发、脚本的逻辑缺陷都曾让我焦头烂额。最终，我通过 云存储高频同步源文件 + Git 低频部署静态文件 的方式解决了这些问题，既保证了写作的实时性，又降低了冲突和维护成本。

最终效果

写作效率：无论在手机还是电脑上，Markdown 文件实时同步，随时随地记录灵感。
部署自动化：静态文件生成和网站更新无需手动干预，省时省力。
稳定性：冲突大幅减少，系统运行平稳。

下一步计划

优化脚本：加入更多错误处理和日志记录。
探索其他云服务：尝试 Dropbox 或 OneDrive，看是否比 iCloud 更适合。
集成 CI/CD：用 GitHub Actions 替换服务器脚本，进一步简化部署。

希望这份约 3000 字的避坑指南能为你提供参考。如果你有类似需求，或在实现过程中遇到具体问题（比如脚本配置、Hexo 环境搭建等），欢迎留言交流，我会尽力分享更多经验！搭建博客系统是一个充满挑战但也极具成就感的过程，愿你也能找到属于自己的完美方案。