笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
Docker 容器退出码 137 / 139：一个是被 OOM 杀，一个是段错误，别混着查
docker 容器动不动就退出，docker ps -a 看到 Exited (137) 和 Exited (139)，网上答案把 137 说成"内存被杀"，139 说成"段错误"，但实际操作里两个的排查方向完全不同，混着查会浪费很多时间。
退出码 137 = 128 + 9（SIGKILL）。最常见是被 OOM killer 杀的，但不一定是容器自己内存超了，要看两种情况：
- 容器超过了 cgroup 内存限制 → 被杀。看是不是 compose/run 里设了 mem_limit，或者镜像本身很吃内存（Java、编译型任务、node 大数据量处理都容易触发）。
- 宿主机整体内存不够，内核 OOM killer 挑了这个容器当牺牲品。这种情况容器自己没超限，是宿主内存压力大。
判断是被谁杀的，先看系统日志：
dmesg | grep -i "out of memory"
journalctl -k | grep -i oom
如果出现 oom-kill 且带容器进程 pid，就是 OOM。想看得更细，用 docker stats 观察它退出前的内存曲线，或者给容器加内存监控。缓解手段：加 mem_limit 让它别拖垮宿主、开 swap、或者给这类任务单独一台机器。
退出码 139 = 128 + 11（SIGSEGV，段错误）。这不是内存不够，是程序自己访问了非法内存，通常是代码 bug、不兼容的二进制、或者和特定 CPU 指令集相关。139 排查方向完全不同：
- 先看容器日志有没有崩溃堆栈：
docker logs 容器名，很多语言会打印 core dump 位置。 - 镜像架构不匹配——在 arm 上跑了 x86 镜像（或反过来），
docker inspect 镜像名 | grep Architecture看下。 - 加了奇怪的 seccomp / capabilities 限制，某些系统调用被拦导致段错误，试着去掉
--security-opt seccomp=unconfined对比。 - JVM 类应用 139 常见于 glibc 版本不兼容或
-XX:+UseShenandoahGC等参数在特定内核上崩。
还有一个容易误判的：退出码 137 也可能是你手动 docker stop 的结果。docker stop 默认等 10 秒（compose 里 stop_grace_period 可调），超时后发 SIGKILL，退出码也是 137。如果容器是"每次重启或部署时退出"，先想想是不是 stop 超时强杀，而不是 OOM。
排查通用套路：
docker ps -a # 看退出码和退出时间
docker logs 容器名 --tail 100 # 看应用日志
dmesg | grep -iE "oom|killed" # 看内核侧
free -h # 宿主内存
结论：137 先问"谁杀的我"（OOM killer / 宿主内存 / stop 超时），139 先问"代码哪里崩了"（段错误），两个方向别搞反。