笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
Node 服务只吃满一个核，事件循环堵了还是 pm2 没开 cluster
Node 服务上线后观察监控，发现 CPU 占用稳定在 100% 上下，但 top 里只看到一个核在烧，另外几核全闲着，接口响应也开始变慢，平均延迟从 50ms 飙到 800ms。这个现象要拆成两层看，一层是进程只跑单线程，另一层是事件循环被堵住，两层症状像，解法完全不同。
先看部署形态。pm2 start app.js 默认是 fork 模式单实例，Node 本身单线程，一个进程最多吃满一个核。四核机器跑单实例等于四分之三算力闲置。想要吃满多核，用 cluster 模式或者 pm2 的 -i 参数拉起多个实例：
pm2 start app.js -i max
-i max 按 CPU 核数起实例，或者 pm2 start app.js -i 4 指定四个。cluster 模式由 pm2 内部做负载分发，多实例共享端口。开 cluster 之前确认应用无状态，或者说会话、内存缓存这类进程内状态能接受丢失，否则多实例会把状态拆散。我那个服务是无状态的接口层，直接 -i max 就上了，CPU 从单核 100% 变成四核各 30% 左右。
但有些时候就算起了多实例，每个实例还是会被事件循环堵住，表现是所有 worker 一起慢。Node 单线程的特性决定了，任何一段同步的 CPU 密集代码都会把当前进程的事件循环卡死，期间所有 IO 回调、定时器、请求处理全部排队。常见元凶是同步处理超大 JSON、循环里做正则、图像缩放、同步 crypto。我遇到过一个接口要把用户上传的 CSV 整个读进内存再逐行解析，几 MB 的文件在低配机器上解析要一两秒，这段同步代码一跑，同进程所有请求全卡住。
定位事件循环阻塞，Node 自带的 --cpu-prof 或者 profiling 火焰图最直观：
node --cpu-prof --cpu-prof-dir=./prof server.js
跑一段时间复现卡顿，然后 node --cpu-prof-process 把生成的 .cpuprofile 转成可读格式，火焰图里占大头的函数就是凶手。轻量一点的临时方案是在可疑代码段前后打点：
console.time('parse-csv')
parseCsvSync(data)
console.timeEnd('parse-csv')
看耗时就知道是不是它。还有一个更快的判断方法：事件循环阻塞时，setTimeout 的延迟会明显变大。写个探针定时器，预期每 1 秒触发一次，实际间隔拉大到好几秒，就说明事件循环被堵了：
setInterval(() => console.log('tick', Date.now()), 1000)
输出里相邻两行时间戳差超过 2 秒，就是阻塞实锤。
定位到是同步解析 CSV 之后，解法是把重活扔出主线程。能异步化的用异步 API，纯 CPU 计算用 worker_threads 开子线程，pm2 的 cluster 管的是进程级并行，救不了单个进程里的事件循环阻塞，两者别搞混。
还有一类隐蔽的假单核：crypto 的某些同步版本方法会占满主线程，异步版本 pbkdf2 这类其实走 libuv 线程池，不会卡事件循环。所以代码里能用 await 的异步 crypto 就别用同步版，性能差很多还卡人。排查这类问题我一般先 top -Hp 看线程数，Node 进程如果线程数明显多于实例数，说明 libuv 线程池在工作，再结合火焰图定位具体函数，方向不会跑偏。
cluster 模式下 pm2 也有平滑发布的需求。代码更新用 pm2 reload app -i max 而不是 restart，reload 会逐个 worker 重启，先起新的把请求接过去再放掉旧的，做到零停机；restart 是把所有 worker 一起干掉再拉起来，高峰期会有一两秒断档。我有一阵图省事一直用 restart，后来看监控才发现每次发版请求数都有一个缺口。另外 -i max 按的是启动时刻的 CPU 核数，容器环境里如果 CPU 配额会变，最好显式写实例数而不是依赖自动探测，不然扩容缩容后实例数对不上。
多实例之后还有个隐形成本：每个 worker 是独立进程，各自带着一份运行时内存。如果应用里有进程级缓存，N 个实例就把缓存复制 N 份，内存占用跟着翻倍。我那个服务一开始没注意，开了四个实例后 RSS 从 300MB 涨到 1.2GB，后来把进程内缓存换成了 redis 才压回去。所以无状态应用放心开多实例，带状态的应用要么先解决状态共享，要么就接受单实例的单核上限，鱼和熊掌得想清楚再选。
确认到底吃了几核有个快命令，pm2 monit 里能直接看到每个实例的 CPU，或者 top 之后按 1 展开所有核，看是不是只有一个核在忙。如果 pm2 list 显示实例数等于核数、但每核都只有二三十，说明负载本来就分散，那不是问题；真正要查的是某个实例持续 100% 而其它实例空闲，这种才指向单实例内部被某段同步代码堵死。