笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
服务内存只涨不降，最后被 OOM 杀：先定位谁在涨，Python 用 tracemalloc、Node 用 heapdump
一个常驻服务跑几天内存占用只涨不降，最后被 OOM killer 杀掉重启。加内存是治标，先确认是不是真的泄漏，再定位是谁在涨。
第一步：确认是泄漏还是"涨到上限就稳"。 有些服务是缓存/池子会主动吃到配置上限然后稳定，那不是泄漏。看内存曲线：涨到某个值稳定下来通常是正常缓存；持续线性上涨不回头才是泄漏嫌疑。用监控或周期采样：
# 每 30 秒记一次 RSS，画个曲线
while true; do ps -o rss= -p 服务PID; sleep 30; done
第二步：不同语言用对应工具定位。
Python：tracemalloc 直接告诉你是哪行代码在分配。 在怀疑泄漏的入口包一层：
import tracemalloc
tracemalloc.start()
# 跑一段业务后，打印当前分配最猛的前几名
top = tracemalloc.take_snapshot().statistics('lineno')
for stat in top[:10]:
print(stat)
statistics('lineno') 直接给出每个文件行号累计分配的内存，泄漏源基本一眼可见（比如某个全局列表无限 append、缓存 dict 只增不减）。比 objgraph 更直观。生产上注意采样开销，可抽样开。
Node：heapdump 抓堆快照分析。 Node 服务内存上涨，用 heapdump 模块或 --heapsnapshot-near-heap-limit 在堆快满时自动 dump：
node --heapsnapshot-near-heap-limit=3 app.js
或运行时触发，dump 出的 .heapsnapshot 用 Chrome DevTools → Memory 打开，看哪些对象/闭包占用大、是不是有该被 GC 的没被释放（常见：全局变量持有大对象、定时器闭包、事件监听器没移除）。
Java：jmap 抓 heap dump + MAT 分析。 略过细节，思路一致——抓快照看对象占用 Top，找"本该死却没死"的集合。
第三步：结合代码找常见泄漏模式。 定位到分配源之后，对照几类经典泄漏：
- Python：全局 list/dict 无限增长、类变量被当实例变量、循环里往全局容器塞引用没清理、
lru_cache无界、连接池没 close。 - Node：事件监听器重复 add 没 remove（尤其热更新）、setInterval 引用的对象永远可达、闭包持有大对象、缓存 Map 无清理策略。
- 通用：日志/指标收集器越攒越多、异步任务队列积压、外部资源（文件/连接）打开没关。
第四步：能定位就改，不能立刻改先止血。
- 确认泄漏前先给服务设上限兜底：systemd 加
MemoryMax=，超了让它在自己 cgroup 里被 OOM 而不是拖垮整机，配合 Restart 自动拉起（见另一条 systemd 内存限制记录）。 - 加了兜底不是不查泄漏，OOM 重启只是把"泄露"变成"周期性重启"，业务上的缓存丢失/抖动还在。
几个判断细节：
- RSS 涨但不一定是泄漏，可能是有大对象长期引用（本应释放没释放），叫"内存膨胀"也算泄漏的一种，工具看到的是同一类。
- 采样要在泄漏发生的业务路径上跑，不然抓不到。比如泄漏只在处理某种请求时发生，就压测那种请求再抓。
- tracemalloc 影响性能，生产小流量或压测环境用，别长期全量开。
总结：内存只涨不降先确认是持续上涨还是涨到上限稳了 → Python 用 tracemalloc 的 statistics('lineno') 直接看行号分配、Node 用 --heapsnapshot-near-heap-limit/手动 heapdump 看对象、Java 用 jmap+MAT → 对照全局容器无限增长/监听器不释放/连接不关闭几类模式 → 先给 systemd 设 MemoryMax+Restart 兜底再慢慢修。别只会加内存和重启。