“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
用《白鲸》测试应用性能：一个简单但有效的极限压力测试方法
用《白鲸》全文作为测试文件，检验待办事项应用能否流畅处理用户生成内容，是衡量应用性能的实用基准。
引言：一个看似简单的问题
2022年4月12日，Hog Bay Software 的开发者发布了一篇题为“Moby Dick Workout”的博客文章。文章从一个看似微不足道的问题切入：你的待办事项列表应用应该能处理多少条目？ 这并非世界最紧迫的问题，但却是开发者偶尔会思考的细节。
作者的核心观点是：生产力应用（如待办事项、大纲笔记、Markdown 编辑器等）应该能够扩展到用户生成的内容。他并不期望每个应用都能加载数 GB 的日志文件，但至少应该能流畅处理用户自己编写的内容。为此，他提出了一个独特的测试基准——使用《白鲸》（Moby Dick）全文作为测试文件。
为什么选择《白鲸》？
《白鲸》是赫尔曼·梅尔维尔于1851年出版的长篇小说，全文约 210,000 个单词（英文原版）。作者选择它的理由有三：
- 长度适中但足够大：比任何用户自己写的内容都要长，用词也更复杂（包含大量航海术语和古英语），但相对于现代计算机的性能来说又很小。
- 真实场景：用户可能不会写出《白鲸》这么长的文档，但应用应该能够处理比日常使用更极限的情况。
- 普适性：作为公共领域文本，任何人都可以合法获取，适合作为跨应用的统一测试。
具体的测试步骤
作者给出了一套标准化的测试流程，用于评估任何文档编辑类应用（大纲工具、Markdown 编辑器、待办事项列表等）的性能：
- 打开文件：在应用中打开《白鲸》全文。操作是否快速？是否有明显的加载延迟？
- 滚动到末尾：快速滚动到文档末尾。是否流畅？有没有卡顿或闪烁？
- 调整窗口大小：在文档的不同位置（末尾、中间）调整应用窗口大小。观察是否出现重绘延迟或布局错乱。
- 全选、剪切、粘贴、撤销、重做：执行“全选→剪切→粘贴→撤销→重做”这一系列操作。应用是否仍然稳定？会不会崩溃或出现数据丢失？
- 编辑中间内容：在文档中部修改一些文字。是否有输入延迟？滚动是否会跳转？
- 重复步骤 2-5：反复执行上述操作，直到你感到无聊为止。然后打开 macOS 的“活动监视器”（Activity Monitor），检查应用的内存占用是否在可接受范围内。
技术背景：为什么这个测试有意义
现代计算机的性能非常强大。《白鲸》全文的纯文本大小约为 1.2 MB（Markdown 格式可能稍大），对于拥有 GB 级内存和 GHz 级 CPU 的电脑来说，这简直是“小菜一碟”。但正是这种“小”与“应用表现不佳”之间的反差，揭示了许多编辑器在架构设计上的根本问题。
常见的问题根源包括：
- 虚拟化列表（Virtual List）实现不当：许多编辑器为了处理超大文档，会使用虚拟化技术只渲染可见部分。但如果实现有 bug，在快速滚动或窗口调整时会出现空白、闪烁或跳转。
- 全文搜索/替换的复杂度：全选、剪切、粘贴等操作会触发全文的重新索引或 DOM 更新，导致瞬间高负载。
- 撤销栈（Undo Stack）管理：大量的编辑操作会生成庞大的撤销历史，如果未做优化，内存会暴涨。
- 富文本渲染引擎：支持 Markdown 实时预览或富文本格式的应用，需要对每个字符进行解析和样式计算，性能瓶颈往往出现在这里。
测试文件与适用场景
作者提供了三种格式的测试文件，分别适用于不同类型的应用：
- MobyDick.bike：专为作者自己的大纲应用 Bike Outliner 设计的文件格式。Bike 是一款轻量级的大纲工具，作者用它来验证自己的应用是否通过了测试。
- MobyDick.opml：OPML 格式文件，适用于任何大纲应用（如 OmniOutliner、Dynalist、Workflowy 等）。OPML 是结构化大纲数据的标准格式。
- MobyDick.markdown：Markdown 格式文件，适用于 Markdown 编辑器（如 Typora、Obsidian、iA Writer 等）。
重要提醒：测试的局限性
作者特别强调：这只是一个测试。一个对你来说“好”的应用可能无法通过这个测试，而一个对你来说“不好”的应用却可能轻松通过。
为什么？因为：
- 用户场景不同：如果你只写几百字的短笔记，一个无法处理《白鲸》的应用对你来说依然是好应用。
- 应用定位不同：某些应用专注于极简体验，故意放弃对大型文档的支持以换取更快的启动速度。
- 测试不等于实际体验：这个测试只覆盖了部分操作，并不代表应用在真实使用中的稳定性。
结论：一个实用的“健康检查”
这个“白鲸工作流”本质上是一个快速健康检查。它不需要复杂的性能分析工具，只需要一个免费的文件和几分钟的操作。对于开发者而言，这是一个低成本的回归测试手段；对于普通用户而言，这是一个判断应用是否“靠谱”的直观方法。
作者最后含蓄地指出：如果一款应用连《白鲸》都处理不好，那它背后可能隐藏着更深层次的设计问题。毕竟，计算机的速度极快，《白鲸》相对于这种速度来说“微不足道”。如果应用在这种微不足道的负载下就崩溃或卡顿，那么当用户真正需要处理复杂内容时，情况只会更糟。
原文链接：https://www.hogbaysoftware.com/posts/moby-dick-workout/