今天解决了一个挺实际的问题。
我的公众号文章发布系统一直用着，最近发现 V4 仪表盘看不到今天新发的文章。
排查了半天，原来是文章文件在 外置 SSD 上（/Volumes/jf01/Documents/wechat/），而 V4 只扫了本地的 ~/Documents/wechat/。
说到这个，其实挺常见的。
我现在的存储策略是「本地工作 + 外置归档」：活跃的文章放本地 SSD，方便快速访问；归档的放外置硬盘，当备份用。
每天凌晨三点有个 cron 任务，自动把七天以上的文章迁移到外置硬盘。
所以问题核心就来了：
V4 仪表盘得能同时看到两个地方的文章，不然就会出现“发了文章但仪表盘看不到”的诡异情况。
第一个坑：
我先看了 v4/__init__.py，发现 DOCUMENTS_DIR 和 ARCHIVE_DIR 已经定义好了，但 PathResolver.scan_account() 只扫了 base_dir，没管归档目录。
第二个坑：
改了 path_resolver.py，让 scan_account() 同时扫 base_dir 和 archive_dir，同名目录以本地优先。
改完后测试 scan_account("剑飞")，返回了 38 篇文章，包括本地的 0513/0514 目录和归档的 v4 格式目录。
结果呢？
day-detail 还是看不到！
继续深挖才发现：
get_day_detail() 调用 scan_account 的时候，v3 格式的 date_str 被解析成了 6 位（比如 051447，而不是 0514）。
根因找到了：
detect_format() 里的 V3_PATTERN 把 MMDD 和 XX 拼在一起了：match.group(1) + match.group(2)。
修复很简单：
只取 match.group(1)，也就是那 4 位的 MMDD，get_day_detail 就能正确匹配日期了。
回到正题，这次修完让我意识到：
系统设计里必须考虑多存储位置的情况。
用户的文件可能散落在不同设备上，系统不该让用户手动去找，而是应该自动聚合起来。