“写笔记”支持四种格式——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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
Heroku的丑陋秘密：云之王如何背离Rails并欺骗客户
本文揭露了Heroku在2010年中期悄然改变路由机制，从智能负载均衡退化为随机分配，导致其最大客户之一Rap Genius的性能大幅下降，且该变化从未被文档化或公告，严重影响了付费用户的利益。
Heroku的丑陋秘密：云之王如何背离Rails并欺骗客户
背景：Rap Genius的崛起
Rap Genius是一个歌词解析网站，正在经历爆发式增长。月均独立访客接近1500万，流量增长率持续攀升，知名艺人纷纷注册账号，公司获得了1500万美元融资。对于技术团队而言，这意味着终于遇到了那些人人都说想遇到的问题——规模化的挑战。
在这种关键时刻，拥有一个强大的技术合作伙伴至关重要。Heroku，这个让运维简单得像拨动滑块一样的托管服务，看起来正是理想之选。Rap Genius作为Heroku最大的客户之一，每月支付约2万美元的费用，并且对此感到满意。正如团队所说：作为开发者，我们不想管理基础设施，我们想构建功能。如果Heroku能让我们做到这一点，他们就物有所值。
发现异常：性能数字的巨大差异
然而，十天前，一次关于编译后JavaScript服务的小问题，引发了一系列ab基准测试。测试结果令人震惊： Rap Genius团队观察到，自己测量的性能数据始终比Heroku及其分析合作伙伴New Relic报告的数据差得多。
以静态版权页为例：Heroku报告的平均响应时间为40毫秒，而Rap Genius自己的工具测量结果却是6330毫秒。这种巨大的差异需要合理的解释。
Heroku工程师给出的答案是："请求在dyno级别排队等待，然后被快速服务（因此Rails日志显示很快），但整体时间较慢是因为排队等待的时间。"
人们普遍理解的Heroku工作原理
要理解这个回答的诡异之处，首先需要了解大家对Heroku架构的普遍认知。
当你在Heroku上部署应用时，实际上是将应用部署到多个"dyno"（虚拟化的Ubuntu服务器）上，这些服务器运行在AWS之上。对于Rails应用，每个dyno一次只能处理一个请求。每个dyno每月收费36美元，如果购买New Relic附加组件则为每月79.20美元。
当一个用户请求访问你的网站时，请求首先经过Heroku的路由器（他们称之为"routing mesh"），路由器决定哪个dyno来处理这个请求。路由器的表面目的是在dyno之间智能地平衡负载，防止单个dyno不间断工作而其他dyno闲置。如果某个时刻所有dyno都忙，路由器应该将请求排队，等待第一个空闲的dyno出现。
Heroku官方文档的承诺
Heroku在其"How it Works"页面上的声明与上述理解一致。2009年的文档更是明确写道：
智能路由：路由网格追踪每个dyno的可用性并相应地平衡负载。请求仅在dyno变为可用时才会被路由到该dyno。如果某个dyno因处理长时间运行的请求而被占用，请求会被路由到另一个dyno，而不是堆积在不可用dyno的积压队列中。
2013年的版本虽然变得更为隐晦，但其他现有文档中仍然明确宣称：
heroku.com栈仅支持单线程请求。即使你的应用fork并支持同时处理多个请求，路由网格也永远不会同时向一个dyno发送多个请求。
Heroku的日志格式甚至不包含dyno内部队列等待时间的条目，因为这种队列被认为是根本不存在的。日志中包含的条目是针对路由器队列的。New Relic也是如此：当它报告"Request Queuing"时，指的是在路由器上花费的时间。对于Rap Genius，在最糟糕的情况下，这大约是每个请求10毫秒的微不足道的开销。
真相：随机负载分配
这就是为什么Heroku工程师关于"在dyno级别排队等待"的评论如此奇怪——团队一直认为这种情况不可能发生。"智能负载分配"的全部意义在于：不应该向非空闲的dyno发送请求！即使所有dyno都已满，路由器也最好保持请求直到某个dyno空闲（而不是冒险将请求堆叠在慢请求后面）。
如果你幸运地找到了那份正确的文档（一份与所有其他文档、日志和市场宣传相矛盾的文档），你会发现Heroku将其曾经作为平台基石的"智能负载分配"替换为"随机负载分配"：
路由网格对HTTP请求负载均衡使用随机选择算法，在各个web进程之间分配请求。
核心事实：未宣布的重大变更
2010年中期，Heroku重新设计了其路由网格。新请求不再被路由到第一个可用的dyno，而是随机路由，不管目标dyno是否正在处理请求。
这一决定从未被公开宣布。Heroku的大部分文档明确声明或隐含假设了相反的情况。"在dyno队列中花费的时间"从未出现在他们的日志中，也从未被他们（非常昂贵的）分析伙伴New Relic暴露出来。
最关键的是，这一变化没有影响价格——Heroku自推出以来一直收取每个dyno每月36美元的费用。
为什么随机路由是糟糕的设计
随机路由请求是低效的！这就像Whole Foods超市的收银台分配系统不再把你引导到第一个空闲的收银台，而是随机把你分配到一个已经有其他顾客排队的收银台。
想象一下：如果你是店主，有一天经理在没告诉你的情况下，把你精美的收银台路由系统换成了一对骰子，而且他每晚给你的报告从未改变——他从不告诉你顾客在各个收银台的等待时间，甚至不告诉你存在这种等待（防止这种情况难道不就是最初路由系统的全部意义吗？）——这是不对的，对吧？
旧制度的优势与损失
在Heroku所称的"智能路由"旧制度下，一个dyno就是一个dyno。当你购买一个dyno时，你获得的是可预测的并发能力提升（同时处理请求的能力）。Heroku曾明确定义并发性为"恰好等于你为应用运行的dyno数量"。
但由于路由系统不再智能，这一定义已不再成立。当请求被随机路由时，你的dyno数量与实际的并发处理能力之间不再存在线性关系。一个繁忙的应用可能会接收到大量的新请求，即使其他dyno已经空闲——这导致请求堆积在繁忙的dyno队列中，而空闲的dyno则在一旁闲置。
影响与启示
对于支付高昂费用的企业客户而言，这种未宣布的基础设施变更意味着：
- 性价比大幅下降：同等花费下，每个dyno的实际处理能力远低于其应有水平
- 性能报告失真：日志和监控工具无法提供真实端到端的性能数据
- 信任崩塌：Heroku未能透明地沟通其架构变化，而文档和现实之间的巨大鸿沟令人震惊
- Rails社区被忽视：Heroku以Rails友好著称，但这次变更对Rails应用的影响尤为严重，因为Rails的请求处理模型对排队效应特别敏感
Rap Genius的遭遇揭示了云服务提供商在架构演进中可能存在的透明度问题。当基础设施的关键设计决策被悄然更改，而没有同步更新文档、监控和客户沟通时，即使大型客户也可能在毫无察觉的情况下承受严重性能损失。
对于所有依赖云服务的团队，这个故事是一个重要的警示：深入了解你所依赖的服务架构，不要盲信官方文档，持续使用第三方工具独立验证性能指标。否则，当"云之王"转向时，你可能是最后一个知道的人。
原文链接：Heroku's Ugly Secret