笔记
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 system df 一看 Build Cache 二十几 G，prune 到底该怎么清
连着改了几天镜像，突然发现 /var/lib/docker 那个分区快满了。df 一看用了 92%，可 docker ps 里没几个运行中的容器，镜像看着也不多，空间不知道被谁吃了。跑 docker system df 才看清楚大头在哪：
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 47 12 9.5GB 7.1GB (74%)
Containers 3 2 32MB 0B
Local Volumes 8 5 2.1GB 730MB (34%)
Build Cache 0 0 21.8GB 21.8GB
Build Cache 二十多个 G，比镜像还多，全是可以回收的。这块是 BuildKit 的功劳也是它的锅：从 Docker 23 起默认就是 BuildKit 构建，每一层 RUN、每一段 COPY 的中间产物和缓存都堆在 /var/lib/docker 下面，加上构建时产生的一堆临时层，build 次数一多体积就失控。另外还有每次 build 留下的 dangling 镜像——每次重新构建，旧镜像的 tag 会挪到新镜像上，旧的那个变成 <none>:<none> 悬空镜像，docker images 里看不到名字，但空间还占着。
清理命令按回收力度从小到大排。只想清悬空镜像：
docker image prune
这个只删 dangling 的，最安全。想连没被任何容器用的镜像一起删，加 -a：docker image prune -a，但注意它会把所有没在跑的历史镜像删了，想回滚旧版本就没得回。Build Cache 单独清：
docker builder prune
docker builder prune -a
docker builder prune -f --filter until=168h 可以只清一周前的缓存，最近的留着，下次构建还能命中。--filter "label=..." 也支持，适合给 CI 里关键构建打 label 保护起来，prune 的时候只清没打 label 的。想一把全清（镜像、停止的容器、没用的网络、缓存、悬空卷）用：
docker system prune -a
加 --volumes 会连没被容器引用的命名卷一起删。这个一定要看清楚再执行，命名卷里存的可是数据库文件，我见过同事手滑 docker system prune -a --volumes，把没在运行的那个 MySQL 容器的数据卷删了，还好有备份，不然哭都来不及。所以我的习惯是：日常只 docker image prune 清悬空，Build Cache 用 --filter until 留最近一周，定期（比如每月）才做一次彻底的 system prune -a，且动手前 docker system df 和 docker volume ls -f dangling=true 先看一遍。
还有个隐蔽的地方容易忽略：docker system df 里看不到但确实占地方的，是容器退出后残留的匿名卷。当初用 docker run -v /data 这种没给卷起名字的方式启动过容器，容器删了匿名卷还留着，得 docker volume ls -f dangling=true 看，确认没有容器在用再 docker volume rm 批量删。清理完记得再看一眼 docker system df 确认回收了多少，心里有数。如果连镜像都看腻了想彻底一点，可以从 daemon 配置层面给 BuildKit 设上限。Docker 27 之后 /etc/docker/daemon.json 里可以配 builder 的 GC 策略：
{
"builder": {
"gc": {
"enabled": true,
"defaultKeepStorage": "10GB"
}
}
}
意思是构建缓存超过 10G 就自动回收最老的，不用手动 prune。这个字段版本差异不小，老版本不认这个键，改了 daemon 起不来，配置前先确认 Docker 版本，别照抄。CI 那种天天构建的机器，我更建议把缓存导出到镜像仓库而不是全堆在本机，buildx 构建时加 --cache-to type=registry,ref=仓库/镜像:buildcache 和 --cache-from，让每次构建把缓存层推到仓库，本地只留一小份，既加快构建又不占磁盘。代价是仓库会多一堆 buildcache 层，得定期清。
还有 Build Cache 里经常混着一些删不掉的东西：构建中被中断留下的临时层、并发构建的孤儿缓存，prune 有时候一次清不干净，得多跑两次或者等构建完全停了再清。构建机跑着定时任务的时候别 prune，BuildKit 正在写缓存，你这边删它那边写，容易留下半截。清理前先 docker ps 确认没有正在进行的 build，最好在 CI 的空窗期做。
Build Cache 删掉之后下一次 build 会冷启动、明显变慢，这是正常的，别以为构建机坏了。