8 篇博文 含有标签「Markdown」

Typora 依然是很多人写 Markdown 时最顺手的编辑器之一，但真正影响长期体验的往往不是“能不能装上”，而是授权方式、文件组织和图片管理是不是足够稳。

这篇文章保留的是旧链接入口，但内容已经按合规原则整理为 Typora 的官方下载、授权选择和写作配置建议，而不再保留修改程序文件之类的做法。

前几年大家聊知识管理、写作工具时，常常会自然地往云端协作、在线同步、全平台无缝这些方向靠。它们当然很有吸引力，我自己也长期在用。可到了 2023 年，我反而把一部分最常写的技术笔记和草稿，又重新放回了本地 Markdown 为主的工作流。

Markdown 目录自动生成刚用起来时，体验通常都很好。
大纲一键出来，长文章可读性立刻上去，写作者自己也更容易把结构收住。但 2017 年我在持续写技术文档和博客时，慢慢发现目录真正麻烦的地方，不在生成那一刻，而在后面你继续润色标题的时候。

Markdown 真正进入团队使用后，通常不会只经过一种渲染方式。编辑器里要实时预览，命令行里要批量导出，线上站点还要再做一次正式渲染。只要这三条链路的规则不一致，内容就会慢慢长出很多“本地看着没问题，上线以后才发现不对”的小坑。

静态站点的搜索一开始看起来很简单：把页面内容抓出来，做个索引，前端输入关键字再匹配就行。真做起来以后，经常会发现搜索结果里全是“上一篇、下一篇、文章目录、相关文章”这些导航文字，真正想找的正文反而被稀释了。

很多人第一次做 Markdown 目录自动生成，注意力都会放在“怎么把标题列出来”上。真到了文档越来越多、开始需要分享链接和长期维护的时候，问题往往不是目录能不能生成，而是同一篇文章在编辑器预览、导出的 HTML、线上静态页里，标题锚点是不是完全一致。

很多人一说文章迁移，会先想到正文是不是完整、标题和日期有没有带过去。
这些当然重要，但 2016 年我在整理和迁移一批 Markdown 内容时，最让我头疼的反而不是纯文本，而是那些看起来像细节、丢了却很影响阅读体验的东西。