笔记
0工具
0此页用于记录用户反馈问题后的每一次改进
关于
“写笔记”支持四种格式——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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
上传大文件报 413，nginx 和 Node 的 body 限制都要调
给后台加了个文件上传功能，小文件传得好好的，超过一定大小前端直接报错，浏览器控制台和 Network 里都是 413 Request Entity Too Large。第一反应是后端接口限制，去 Node 里调了半天 body 解析的 limit，结果还是 413，后来才想到请求压根没到后端，被前置的 nginx 拦了。
nginx 默认的 client_max_body_size 是 1m，超过 1MB 的请求体直接回 413，不给你到后端的机会。这个配置默认值太小，做上传基本都要调大。在 nginx 里加：
server {
client_max_body_size 50m;
}
放 server 块里对整个站点生效，或者只在 upload 相关的 location 里放，影响面更小：
location /upload {
client_max_body_size 100m;
}
改完 nginx -t 检查语法再 reload。注意 client_max_body_size 是请求体上限，包括普通 POST 表单和 multipart 文件上传，文件几 MB 但加上 base64 编码体积还会膨胀三分之一，估算上限时留点余量。我传的文件最大也就二三十 MB，配 50m 够用，如果要做百 MB 级上传就得往 200m 以上配，还要看服务器内存扛不扛得住。
但 nginx 调完还有第二层，Node 那边如果用了 express 的 body-parser 或者内置的 express.json()，默认也有体积限制，默认 100kb。nginx 放行了，Node 这层也会拒，返回的不一定是 413，express 的 body-parser 超限会抛 PayloadTooLargeError，没做错误处理的话前端看到的是 500 或者一段 HTML 错误页，很容易被带偏。要显式调大：
app.use(express.json({ limit: '50mb' }));
app.use(express.urlencoded({ extended: true, limit: '50mb' }));
multipart 文件上传如果是用 multer 这类库，它不走 body-parser 的 limit，但 multer 自己也有 limits 配置（fileSize 等），超了会报 MulterError: File too large。三层限制：nginx、body-parser、multer，任何一层卡住都传不上去，得对齐。
排查这类 413 有个关键判断：看响应是 nginx 的错误页还是应用自己的错误。nginx 拦的 413 响应体是 nginx 默认的 HTML，标题是 nginx，一眼能认出来；如果是应用层返回的，一般带着应用的 JSON 结构或者错误堆栈。curl 直接传一个超过限制的文件验证最干脆：
curl -s -o /dev/null -w "%{http_code}\n" -F "file=@bigfile.zip" 127.0.0.1/upload
返回 413 先看响应体是谁的，nginx 的就调 nginx 配置，应用的就去 Node 层找。
还有多层反代的场景，前端请求要先经过一层 nginx 再到后端，中间还可能套了 CDN 或者别的网关，每一层都可能有自己的请求体限制，任何一层不放行都传不上去。我踩过 CF 前面挡着，源站 nginx 调大了也没用，是 CDN 边缘那边把大请求掐了，这类得去 CDN 的配置里调上传限制，本地怎么调都白搭。
顺带提醒，413 和 400 别混。413 是请求体超过限制，400 是请求体格式不对，比如 multipart 边界没带对。如果 curl 传文件返回 400 而不是 413，多半是前端 FormData 拼得有问题或者少传了字段，跟体积限制没关系，往代码方向查。还有大文件上传传到一半断了、nginx error log 里报 client intended to send too large body 的，也是 client_max_body_size 在拦，日志这句话可以直接 grep 出来确认。排查顺序我总结就是：先 curl 复现拿响应体，分清是谁拦的，nginx、Node body-parser、multer、CDN 一层层对过去，总有一层是元凶。
慢速上传还有个隐蔽的超时问题。nginx 的 client_body_timeout 默认 60 秒，如果网速慢、文件又大，body 传一半卡住超时，nginx 会把连接断掉，前端看到的是连接重置而不是 413，跟限制完全是两码事。做超大文件上传时，要么调大 client_body_timeout，要么考虑关掉 proxy_request_buffering，让请求体不经过 nginx 的临时缓冲直接流转给后端，不然 nginx 先把几十 MB 的 body 写进临时文件，磁盘小的机器会被写爆。我当时配完限制还专门拿 1MB、10MB、50MB 三档文件各传一次，把阈值边界摸清楚才收工，免得上线后用户在不同大小上踩不同的坑。