笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
页面突然全转圈，nginx 日志 499 暴涨？三步限流按住刷接口的
好好的网站，某天用户突然反馈"页面一直转圈打不开"，监控报警，上服务器一看负载爆高、响应时间飙到 10 秒以上，nginx error 日志里密密麻麻全是 499，CPU 和网络 IO 都满了。top 里 nginx worker 吃满 CPU，访问记录异常多——有人在刷你的接口。这种不带攻击特征的批量请求，靠防火墙挡不过来，最有效的就是 nginx 自己限流。
先理解 499 是什么
499 是 nginx 自定义的状态码：客户端还没等到响应就自己断开连接了（比如浏览器/脚本超时放弃）。大量 499 基本意味着服务端已经处理不过来，把客户端都"饿死"了。
第一步：定义一个按 IP 的限流规则
放在 http{} 块里（通常是 nginx.conf 顶层）：
limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
含义：以 IP 为单位限流，10m 是共享内存大小，rate=10r/s 是每 IP 每秒最多 10 个请求；第二条是限制单 IP 的同时连接数。
第二步：在 server/location 里用起来
server {
limit_req zone=req_limit burst=20 nodelay;
limit_conn conn_limit 20;
# 接口比页面更敏感，单独收紧
location /api/ {
limit_req zone=req_limit burst=5;
proxy_pass http://你的后端;
}
}
burst=20 意思是允许瞬时多放 20 个进队列（正常用户的页面并发请求不会误伤），nodelay 让超出的立刻返回而不是排队。可选：给内网 IP 单独白名单、把限流后的返回做成友好页面：
error_page 429 /too_many_requests.html;
第三步：reload 生效，观察
nginx -s reload
实测案例：配完 reload 后，CPU 负载从 100% 一路掉到 30% 左右，网站逐渐恢复可用，效果立竿见影。之后再去日志里分析攻击来源 IP 段，确认是恶意源就顺手 deny。
限流才是治本，封 IP 只是治标——攻击者换个 IP 继续刷，而限流规则是永续存在的。
几个必须避开的坑
- rate 要按业务调：静态页面 10r/s 够用，纯接口/API 站要更高，不然误伤。
- burst 太小会误伤正常用户：一个页面往往并发拉几十个 CSS/JS，burst 设 0 或太小，正常用户直接白屏。限流别加到静态资源 location 上。
- 套了 CDN 后，
$binary_remote_addr取到的是 CDN 节点 IP，全站用户挤在同一批 IP 里，限流会误杀一片。要按真实用户 IP 限：套 Cloudflare 用$http_cf_connecting_ip，其它 CDN 用$http_x_forwarded_for（取第一个可信值），并在 nginx 里配置可信代理段。 - 429 返回太生硬的话，自己定义返回 JSON，别让用户看到一堆英文错误。
配规则前，先把日志里的攻击画像拉出来
别凭感觉定阈值，把 access.log 翻一遍，来源 IP 和被打的路径一起看：
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
CC 和真人访问在日志里一眼可分：攻击 UA 空着或带 curl/Python，没 Referer 没 Cookie，专挑最贵的动态路径打，静态资源一概不碰。看到这特征，阈值往低定不冤。
超限默认回 503，不是 429；499 也不全是挨打
limit_req 超限时 nginx 默认返回 503，不是 429。配了 error_page 429 /too_many_requests.html; 却不生效的多是栽在这：限流在工作，只是没回 429。想统一就显式声明：
limit_req_status 429;
再看 499 的归因。攻击者刷接口会刷出一片 499，但上游太慢、客户端等不及断开时，同样一片 499。区分：攻击型请求量暴涨、集中在少数路径、request_time 很短；慢后端型全站均匀、request_time 贴近 proxy_read_timeout 上限。默认日志不记响应时间，把它加进 log_format：
http {
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" rt=$request_time urt=$upstream_response_time';
access_log /var/log/nginx/access.log main;
}
已有自定义 log_format 的，把 rt/urt 并进那一行。reload 后捞 499 样本看 rt：
grep ' 499 ' /var/log/nginx/access.log | tail -n 20
把后端慢误判成被刷，限流一收紧先误伤正常用户。