笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
buildx 打多架构镜像：arm64 在 x86 上构建，一路绿灯到部署才炸
手里只有一台 x86 的构建机，客户那边却有一批 arm64 的机器（树莓派、飞腾那类），之前每次都是在这边 build 完再找台 arm 机器重新 build 一遍，麻烦。后来想用 docker buildx 一次出 linux/amd64 和 linux/arm64 两个平台的镜像，直接 push 到仓库，省得来回倒腾。折腾下来发现这里面的坑比想象多，记一下。
buildx 的原理简单说就是 BuildKit 支持一次构建多个平台，目标平台和当前平台不一样的时候，靠 QEMU 做用户态模拟硬跑。第一步得先装模拟器注册 binfmt，不然一跑就报 exec format error：
docker run --privileged --rm tonistiigi/binfmt --install arm64
docker buildx create --name multiarch --use
docker buildx ls
第一次没装 binfmt 直接 build，构建阶段 RUN apt-get update 那一步就挂了，报错就是 exec format error，当时还以为是镜像拉错。装上之后能跑，但 QEMU 模拟 x86 跑 arm 指令集是真慢，同一个项目纯 amd64 构建 3 分钟，带 arm64 一起要多跑大概 20 分钟，CI 里等得心焦。
最大的坑在依赖下载那一步。项目是 Go 写的，go.mod 里有些依赖要从 github 拉源码编译，go build 在模拟环境里跑的是 arm64 的编译器，编出来的产物没毛病。但项目里还有一个阶段要从官方源下载预编译的二进制工具，那个下载脚本判断架构用的是构建机自身的 uname，没认 buildx 传进来的环境变量，结果 arm64 镜像里塞了一个 amd64 的二进制。构建全程绿灯，镜像也 push 上去了，arm 机器上 docker pull 下来一跑直接段错误，排查了半天才发现是架构装错了。
后来学乖了，Dockerfile 里要用目标平台的信息时别自己猜，buildx 会把平台通过 ARG 传进来：
ARG TARGETARCH
RUN case "$TARGETARCH" in amd64) url=... ;; arm64) url=... ;; esac && curl -L "$url" -o /usr/local/bin/tool
另外 buildx 的 --platform 和 --load、--push 的关系也容易搞混。本地 docker buildx build --platform linux/arm64 -t 名字 . 不打 push 的话，默认产物不进本地 docker 镜像库，docker images 里看不到，除非开 containerd 镜像存储或者加 --load，而 --load 一次又只能载入当前机器的平台，多平台只能走 --push。想确认仓库里那个多平台镜像是不是真的全，用：
docker buildx imagetools inspect 仓库/镜像:版本
会列出 manifest 里到底有几个平台。构建完想在本机冒烟测一下 arm64 那个，可以显式指定平台跑：
docker run --rm --platform linux/arm64 仓库/镜像:版本 uname -m
能输出 aarch64 基本就说明平台打对了。buildx 缓存目录也是大头，docker buildx du 能看到 buildkit 缓存占了多少，旧的不想要了 docker buildx prune 清掉，这个和 docker builder prune 是一回事。还有 registry 那边也要兼容：多平台镜像 push 上去用的是 OCI 的 manifest list（老叫法 manifest index），太老的 registry v2 版本不认这种格式，push 会报 unknown manifest 或者媒体类型不支持，内网自建仓库要是版本旧，先升到能支持 OCI 的版本再谈多平台。本地验证除了 uname -m，我更习惯直接跑一段真实功能测试，比如镜像里带个命令行工具就 docker run --rm --platform linux/arm64 镜像 工具 --version，能出正确输出才算真过了，光看架构对不够，因为 QEMU 模拟下有些指令集边界问题只有跑到才知道。
再补一个很多人忽略的点：buildx 多平台构建时，如果基础镜像只发布了 amd64 没有 arm64，构建会在拉 base 那一步直接失败，报 manifest unknown 或者 no match for platform。判断一个镜像有没有你要的架构，docker buildx imagetools inspect 能看，不用真去拉。我遇到过基础镜像是多阶段的中间层，某一段用了只有 amd64 的镜像，整条链就断在那，排查时把 Dockerfile 每个 FROM 都过一遍，确认每个基础镜像都发布了目标架构。gitlab CI 里跑 buildx 记得给 runner 开 privileged 或者预装 binfmt，否则每次构建都报 exec format error，还以为是代码问题。构建完的产物如果还要给离线环境，记得把 manifest list 连同各平台镜像一起 docker save，单平台 save 过去 arm 机器上还是跑不了。
整体经验：多平台构建本身不难，难点全在"构建脚本里的架构判断没跟着 TARGETARCH 走"和"没装 binfmt 还以为是别的错"这两处，先在这两个地方排，能省大半时间。