“写笔记”支持四种格式——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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
按钮的职责：别让动画阻塞用户操作
按钮的核心职责是立即响应操作，动画不应阻塞用户的连续输入，否则会破坏交互的可预测性和效率。
从一张照片旋转说起
最近我在制作一个大型交互式文章时，一直担心展示大量经典桌面示例会让内容显得过时，只属于过去那个时代。但事实上，这些示例所揭示的挑战是普遍存在的，今天依然如此。这里有一个我刚刚发现的例子：在 iPhone 和 Nothing Phone（一款 Android 手机）上旋转图片的操作对比。
这是一个相当标准的控件——点击一次逆时针旋转90度，再点击一次继续旋转，以此类推——并且伴随着一个平滑的过渡动画，帮助你保持对图片方向的感知。现在，我刻意夸张地演示一个问题：快速连续点击旋转按钮八次。八次旋转理论上应该是一个“空操作”（no op）——图片完整旋转两圈，最终回到起始方向。
iPhone 确实做到了这一点：它记住了并缓冲了所有点击，因此第二次、第三次……旋转会在第一次动画完成后立即执行。而 Nothing Phone（Android 系统）上的按钮则不同：它通过触觉反馈和声音确认了每一次点击，但如果前一次旋转动画仍在进行中，它会忽略后续的点击。
为什么这很重要？
我经常思考“情境性残疾”（situational disability）这个框架。它指出，残疾不仅仅是少数人的事，而是几乎每个人都会在某些情境下暂时性地变得“有效残疾”。这就是为什么无障碍设计远比我们许多人想象的要重要。
类似地，我认为“随意使用”和“非随意使用”之间的界限也很模糊。手机拍照通常是随意使用——相机通常能很好地检测照片方向，但当你俯拍地面上的文档时，它就会出错。举个例子，如果你需要拍摄一堆横向的文档，你可能最终要一张张地旋转几十张照片。如果能以任意速度点击三次按钮，无需思考、无需关注、不会被动画阻塞界面，那操作会变得多么可预测和愉快。
这就是我所谓的“情境性高级用户”（situational power user-ness）。在足够长的时间跨度内——或者，在这种情况下，足够大的用户群体中——即使是像手机照片编辑这样随意的界面（或者 GarageBand），也会遇到一些用户别无选择，只能更认真地对待它，并期望从中获得更多。
解决方案不止一种
顺便说一句，缓冲点击并不是唯一的答案。你也可以在中断点击后立即停止或加速当前动画。但核心原则是：永远不要强迫用户等待动画完成。
技术细节与背景补充
1. 动画阻塞的本质问题
在 UI 编程中，动画通常由主线程驱动。当动画正在执行时，如果系统设计为“动画期间忽略输入”，那么用户的后续操作就会被丢弃。这在视觉上表现为：用户点了按钮，按钮有反馈（声音/震动），但操作被吞掉了。这种设计对于一次性操作（如提交表单）可能合理，但对于重复性操作（如旋转、翻页、缩放）则非常糟糕。
2. 缓冲 vs. 忽略：两种设计哲学
- 缓冲（Buffering）：如 iPhone 的做法，将用户的所有点击记录在队列中，按顺序执行。优点是操作不丢失，用户可以快速连击；缺点是如果动画时间较长，队列可能堆积，导致操作延迟响应，用户感觉“滞后”。
- 忽略（Ignoring）：如 Nothing Phone 的做法，动画期间丢弃额外输入。优点是界面响应简单，不会出现队列堆积；缺点是用户需要等待动画结束才能进行下一次操作，在需要快速重复操作的场景下效率极低。
- 中断与加速（Interrupt & Accelerate）：更高级的做法是，当用户再次点击时，立即结束当前动画，直接跳转到最终状态，或者加速动画播放。这是许多游戏和流畅 UI 的常见做法，兼顾了即时反馈和操作连续性。
3. 为什么动画会“帮倒忙”？
动画的存在本是为了帮助用户理解状态变化（例如旋转时图片的过渡方向）。但当用户已经明确知道下一步要做什么时（比如“再转90度”），动画反而成了障碍。用户不得不等待动画完成，这打破了“操作-反馈”的即时循环，增加了认知负担和操作时间。
4. 情境性高级用户
这个概念是对“情境性残疾”的镜像。大多数用户大多数时候是“随意用户”，但总有一些场景（如批量处理文档、在嘈杂环境中操作、单手操作、视力受限等）会让随意用户变成“高级用户”——他们需要更高的效率和更少的阻碍。设计时不能只考虑“普通情况”，而应该考虑整个用户谱系。
5. 实际影响
这个问题看似微小，但在高频操作中影响巨大。例如：
- 图片编辑中批量旋转多张照片
- 电子书阅读器翻页
- 音乐应用中切换曲目
- 游戏中快速连击技能按钮
- 表单中快速选择选项（如星级评分）
一个按钮的响应行为决定了用户是否能够流畅地完成任务，还是会在每次操作后被迫停顿。
总结
按钮只有一个工作：立即响应。无论设计多么精美的动画，都不应该成为用户操作路径上的障碍。好的交互设计应该考虑所有用户——包括那些偶尔需要快速连续操作的用户——并确保动画是辅助，而不是阻力。
原文链接：https://unsung.aresluna.org/if-youre-a-button-you-have-one-job/