局限性
MarkEditor 的局限性
任何一个App 都有自己适用的场景和局限性，ME 也不例外，主要是下面的问题。
长文章的性能问题
由于 MarkEditor 本身会实时对文本的结构进行分析，以实现文本的高亮、TOC结构的获取与调整，所以当文本过长的时候，这个基础引擎会不可避免地导致性能的下降。
按照我们的概要性测试，基本上 1 万字以内不会产生性能问题。
在 10 万字左右的时候，不打开同步预览的时候，在连续超快速的输入时，会有不是很明显的时滞感，但基本上没有什么性能上的波动。
在 10 万字左右并且开启了同步预览的时候，能够感觉到卡顿，但基本上也勉强可用。
某些弹窗界面首次显示的时滞感
MarkEditor 因为功能比较多，并且通过设计规整，在多数时候，使用者并不会感知到自己不常用的功能存在。
而每个功能、设置界面，都是需要 UI 渲染的，考虑到很多界面，在整个 MarkEditor 启动的周期内可能都不会被呈现，所以，默认并不直接构建，以节省 App 启动的时间。而只有在它们被第一次显示的时候，才会实时构建。这个 构建 过程，会消耗 1 秒不到的时间，有时会给人一种时滞感。
不过，这是正常的，并不会导致或者因为 MarkEditor 卡住了。
打开 App 的时间比较长？
MarkEditor 会尽可能记住其最后一次打开时候的状态，比如有多少个标签栏同时打开的，那么，下次 MarkEditor 打开的时候，又会重新开启这些标签栏。
如果 MarkEditor 启动的时间超过 3 秒以上，一般来说，都是多标签栏每栏内都需要处理载入的逻辑而导致的。
可以关闭不使用的 Tab 栏，那么下次重新打开 MarkEditor 的时候，速度会有比较明显的加快（呃，其实如果不是十来个 Tab，加速还是不明显的，估计也就几秒吧）。
Markdown 的局限性
Markdown 作为基础，可以带来非常高效的写作体验。但是它并非万能的，根据我们的经验，建议书写的过程中可以参考以下建议:
- 保持清晰的结构: 比如一个 table 语法中，每个字段都是长文本，那么建议考虑用 list 的方式，或者
# xx## xxx这种层级标题的方式。 - (多行文字间)避免多重语法嵌套: 比如在一个 list 内嵌套代码并不是推荐的方式。
- 保留适当的空格: 特别是
# 标题这种语法，最好是#后面加上一个空格。 - 按需保留适当的空行: 比如在层级标题之间，保留合适的空行，虽然于解析结果而言没有任何意义，但是自己预览原文时的体验会好很多。
另外，Markdown 本身不会让使用者变得更酷，除非自己本来就很酷。:)
隐私相关
本地文件路径的暴露
在导出为HTML 格式(相关) 页面的时候，如果文档内包含插图，则在原始的 HTML 源码中，会曝露插图位于当前操作系统内的图片的文件路径。
这个设计的目的，是因为使用者在当前电脑内呈现 HTML 页面的时候，可以无差别地呈现对应的插图。
网络请求
MarkEditor 会在以下情况产生网络请求：
- License 的激活、升级、校验
- 版本更新的检查
- MarkEditor 云端 （包括 ME 自身提供）同步数据的时候
云端同步的请求，仅仅包含文件信息本身，不包含系统级的信息。
License & 版本检查的请求，除了 License 与 当前版本 这些基本信息外，还会包含操作系统、操作系统版本、设备类型等几个基本的信息外，不会包含其它系统级、账户级的信息。
MarkEditor 除了在 自动版本检查 （可关闭）时会主动地产生请求，其它时候，都是使用者的行为而产生具体的网络请求。
如果你发现有其它（主动的）网络请求发生，请确保 MarkEditor 是从我们的官网上下载的，因为，这意味着当前 App 已经被修改了，是不安全的。