默认安装的 MarkdownEditing 不适合写日记，因其面向技术文档，缺乏日期归档、链接跳转、内联标签等日记核心功能，且不识别 YYYY-MM-DD 文件名作为时间戳，也不支持按月/周折叠目录视图。
为什么默认安装的 MarkdownEditing 不适合写日记
因为 MarkdownEditing 主要面向技术文档写作，语法高亮侧重代码块和标题层级，对日期归档、链接跳转、内联标签等日记场景支持弱。它不自动识别 YYYY-MM-DD 文件名作为时间戳，也不提供按月/周折叠目录视图——这些是日记管理的核心需求。
必须装的三个插件及其真实作用
只装 MarkdownEditing 和 Markdown Preview 是不够的。日记需要结构化组织，而非单文件预览：
-
ProjectManager：把每天一个.md文件按年/月建文件夹后，用它保存「2026-07」这类子项目，避免每次手动File → Open Folder -
AutoFileName：在写[[2026-07-14]]这类双向链接时，输入左括号后自动提示已存在日记文件名，防止拼错或大小写不一致 -
PlainTasks：把待办事项（如「#todo 买咖啡豆」）高亮并支持done状态标记，比纯 Markdown 列表更可靠——它会真正修改行首标记，而不是靠人眼识别- [x]
文件命名和路径约定直接影响搜索效率
Sublime Text 自身不索引内容，全靠你命名规范来支撑快速定位：
Convert Markdown To HTML And PDF - Markdown和HTML、PDF互转
下载
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
- 日记文件必须用
YYYY-MM-DD-title.md格式，例如2026-07-15-morning-walk.md；不能用morning_walk_20260715.md，否则Ctrl+P搜索2026-07会漏掉 - 所有日记统一放在
~/Documents/journal/下，不要分散在多个子目录；ProjectManager只能记住顶层路径，嵌套过深会导致切换项目变慢 - 避免在文件名中使用中文或空格，
AutoFileName对非 ASCII 字符补全支持不稳定，容易卡住或返回空结果
快捷键冲突是预览失败最常见的原因
很多人装完 Markdown Preview 后按 Ctrl+Shift+P → 输入 mp 没反应，其实是快捷键被其他插件劫持了：
- 检查
Preferences → Package Settings → Markdown Preview → Key Bindings – User，确认里面只有类似{"keys": ["ctrl+alt+m"], "command": "markdown_preview", "args": {"target": "browser"}}的条目 - 禁用
LiveReload插件——它默认占用Ctrl+Alt+R，但和Markdown Preview的浏览器刷新逻辑冲突，会导致预览页卡在 loading 状态 - 如果用了
OmniMarkupPreviewer，它和Markdown Preview不能共存；前者实时刷新依赖本地 HTTP server，后者走文件协议，混用会触发 CORS 错误
日记管理的关键不在插件数量，而在命名是否可被 Sublime 原生命令识别、路径是否扁平、链接是否可自动补全。一旦这三点没对齐，再多插件也救不回查找成本。
