“写笔记”支持四种格式——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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
Serverless 真的更便宜吗？一次实测：慢 15%，贵 8 倍
文章通过作者在 CardGames.io 上的实际迁移测试，对比了 Serverless（Lambda + API Gateway）与传统 Elastic Beanstalk 托管方案在性能和成本上的差异，得出结论：对于高频短请求场景，Serverless 不仅性能慢 15%，成本更是高达 8 倍，并非所有工作负载都适合 Serverless。
背景：作者为何要尝试 Serverless
作者是 CardGames.io（一个在线纸牌游戏网站）的开发者。他的 API 是基于 C# 编写，托管在 AWS Elastic Beanstalk 上，使用 Linux 服务器运行 .NET Core（通过 Docker 容器）。架构如下：
- S3 存放静态资源（HTML、CSS、JS、图片）
- Elastic Beanstalk 上的 C# API
- CloudFront CDN 前置用于加速静态内容和 API 请求
作者的痛点非常明确：部署太慢。由于 .NET Core 在 AWS Beanstalk 上只能通过 Docker 方式运行，部署一次需要好几分钟（切换环境、切换 CNAME）。相比之下，他另外一些跑 node.js 的 Beanstalk 应用只需几秒即可完成部署。因此他想尝试 Serverless 是否能带来更快、更省心的部署体验。
迁移过程：出乎意料地顺利
作者按照 Serverless 框架官方教程迁移了自己的 ASP.NET Web API，整个过程比他预想的简单得多：
- 添加一个简单的配置文件（serverless.yml）
- 添加一个依赖包
- 添加一个小的启动类
部署时间约 20 秒——这比 Beanstalk 动辄几分钟的部署体验好太多了。原因在于 Lambda 对 .NET Core 有原生支持（虽然当时只支持 2.2 版本），而 Beanstalk 必须自己搞 Docker。
说实话，这最初体验确实很诱人：不用再操心自动扩缩容组、最大实例数等基础设施细节。
性能测试：15% 的劣势
作者做了个对比实验：
- 他将 Lambda 函数部署在 us-west-2 区域（与 Beanstalk 服务器同一区域）
- 通过 CloudFront 将部分游戏流量路由到 Serverless 架构，另一部分走老的 Beanstalk
- 两个 URL 调用完全相同的业务逻辑代码（保存一个事件到数据库）
他各发起 100 次请求，结果发现：Serverless 端整体慢了 15% 左右。 这个差距是持续且稳定的，不是单次抖动。
对此他分析出两个原因：
- API Gateway 带来的额外 HTTP 转发层开销——虽然它提供了很多功能（限流、API Key 等），但作者并未使用这些特性，却仍然付出了延迟代价。
- 可能的冷启动影响（虽然是性能差距是持续性的，不仅仅是首次调用）。
作者承认这个幅度虽然令人失望，但 15% 的差异还不至于成为放弃的理由。真正的转折点在账单上。
账单惊魂：价格贵了 8 倍
作者原本的想法很天真："按使用付费听起来肯定比 24/7 开着的 EC2 便宜吧？"
但他让 Serverless 环境跑了几天后查账单，发现事情完全不对——Lambda + API Gateway 的费用已经超过 100 美元。
他起初尝试通过给 Lambda 分配更少内存来省钱，但当仔细看账单后发现，大头不在 Lambda，而是 API Gateway。
他的 API 每天接受约 1000 万次请求。按照 API Gateway 的定价，他自己算了一笔账：
- API Gateway 费用：约 35 美元/天（按当时 ~3.50 美元/百万请求计）
- Lambda 费用：约 10 美元/天（即使调低内存配额可进一步省）
- 合计约 45 美元/天，即约 1350 美元/月
对比他 Elastic Beanstalk 环境的实际成本：
+-----------------------------+------------------------------+
| 方案 | 月度成本 |
+-----------------------------+------------------------------+
| Elastic Beanstalk (m1.small + 负载均衡 + EBS) | ~164 美元 |
| API Gateway + Lambda | ~1350 美元 |
+-----------------------------+------------------------------+
贵了约 8 倍。作者原话是："我喜欢新技术，也喜欢快速部署，但我不准备为此每月额外付 1200 美元。"
为什么这么贵？深入拆解 Lambda 计费逻辑
很多人对 Lambda 的计费有误解。Lambda 的定价基于两个维度：请求次数 + 计算时长（以 100ms 为计费单位）。
作者给出了他某个请求的具体数据：
- 实际 CPU 计算时间：3.5ms
- 却被计费：100ms（最小计费单位）
这意味着他每个请求 96% 的计算时间是闲置的。对于这种轻量级请求（一次数据库写入），Lambda 的最小计费粒度反而成为一种浪费。
他用表格呈现了这个痛点：
- 大量短请求 + 每次只做极少的计算 = Lambda 的成本效率极低
- 如果请求处理时间很长（比如 500ms 以上），Lambda 的优势才能体现出来，因为计费是按实际使用时间线性增长，而非按固定的每日实例成本。
贵的不只是 Lambda，API Gateway 才是大头
很多人想用 Lambda 时忽略了 API Gateway 也是收费的，而且如果你不用它的高级特性（API Key、限流、自定义域名绑定等），这笔钱实际上是纯浪费。
作者提到他后来得知，其实 AWS 已有 Lambda 函数 URL 功能，不过当时的版本或他自己的场景下，API Gateway 仍是让 Lambda 可通过 HTTP 被访问的主要途径。他也承认自己当初没有仔细看 AWS 的定价页面——"如果先看定价页做点数学题，就不会走弯路了"。
更新：作者学到的三件事
文章发布后引起热议（HN 和 reddit r/programming 双榜首），作者收到大量反馈并总结了自己的改进空间：
应该用 Application Load Balancer（ALB）而不是 API Gateway 放在 Lambda 前面。ALB 可以直接将 HTTP 请求转发到 Lambda 函数，省去 API Gateway 3.5 美元/百万请求的成本，且仍然可以获得类 ALB 的负载均衡能力。
EC2 实例类型太老了：他还在用 m1.small（古老实例类型），至少应该升级到 t2.small 或更新的实例代，能获得更好的性价比。
Beanstalk 的部署速度有救：改为使用 .NET Core runtime 的 Docker 镜像而非 SDK 镜像，部署时间可缩短到 30~40 秒，虽然仍比 Lambda 慢，但不再是大痛点。
结论与思考：Serverless 并不适合所有场景
作者最终结论非常务实，并不反技术：
Serverless 不是银弹。它适合某些负载模式，但对"高频 + 短请求 + 轻计算"的 API，传统持续运行的实例反而更划算。
他给出的适用性判断标准：
- 如果你的 API 请求耗时较长（比如几百毫秒以上，涉及较多 CPU/内存计算），Lambda 按 100ms 计费的方式可能很划算——因为你只付你真正用的计算资源。
- 如果你需要 API Gateway 的高级特性（限流、API Key、第三方鉴权等），那 3.5 美元/百万次的费用也许物有所值。
- 如果你只是做简单的 CRUD + 一次 DB 查询，传统 Web 服务器（不论 EC2 还是 EC2 + Beanstalk）会便宜得多。
这实际上指向了一个更本质的问题：Serverless 的商业模型是基于函数计算时间来收费的，而对很多互联网 API 来说，请求的瓶颈往往不是 CPU，而是数据库 I/O 和网络延迟。这种情况下 Lambda 大部分收费时间都是在空转等待。
给中文读者的补充背景知识
2019 年的 Serverless 主流形态
2019 年正是 Serverless 概念大热的时期。AWS Lambda 作为先驱已吸引了大量开发者。
- Lambda 支持语言有限（Node.js、Python、Java、Go、.NET Core 2.x 等），部署配置比 Docker 容器简单得多
- 当时 Lambda 计费：每 100ms 计算时长 + 每次请求费（当时约 0.20 美元/百万请求）
- API Gateway 在当时的 HTTP 转发链路中几乎是必经之路（后来的 Lambda Function URL 是后来才推出的）
为什么 Serverless 会慢 15%？
- API Gateway 本质上是一个反向代理，多一跳就有额外延迟哪怕在同一个区域也会有作用。在跨区域场景下其影响更大。
- Lambda 的冷启动问题是另一重要诱因——如果你的请求流量不是持续有一定并发度，有很多零散的请求会触发冷启动，冷启动时间通常在几百 ms 到几秒不等（取决于运行时、内存大小，代码包体积）。作者没有单独剥离开冷启动在对比中的影响，但确实也是 Serverless 延迟的一大来源。
核心干货
Serverless 的成本是"非连续阶梯"的——按 100ms 计费意味着大量小于 100ms 的请求会浪费钱。如果你的请求平均执行时间远低于计费单位，请务必做真实流量压力测试而非仅看 AWS 官网定价。
性能比较要包含网络链路——CloudFront + API Gateway + Lambda 比 CloudFront + Beanstalk 多了代理层，延迟差异往往是真实存在的。
做成本对比前，必须先对自己的工作负载模式做统计——请求频率、请求处理时长、并发模式、是否用得上增值特性。
原文链接：http://einaregilsson.com/serverless-15-percent-slower-and-eight-times-more-expensive/