笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
换 DNS 忘删 DS，全站SERVFAIL
线上出过一次诡异故障：域名从 Cloudflare DNS 迁回另一家 DNS 之后，站点大面积打不开，报错不是超时而是"解析失败"。本地 dig 域名直接返回 SERVFAIL，可同办公室另一台机器、手机切流量却完全正常。折腾到半夜才定位到：DNSSEC 开了，但换 DNS 的时候忘了去注册商删掉旧的 DS 记录，DS 变成了孤儿，校验一直失败。
先把背景补上。在 Cloudflare 托管时开了 DNSSEC，Cloudflare 会生成一对 DNSKEY，并把其中的 DS 记录给你，让你填到注册商那里。DS 记录的本质是"把父区（注册商的 .com 区域）里该域名的公钥指纹，和新 DNS 的密钥绑定起来"。解析器验证的时候，会拿着父区的 DS 去比对新 DNS 返回的 DNSKEY，对得上才算可信。
问题出在换 DNS 的过程：我把 NS 从 Cloudflare 改到了新解析商，新解析商有自己的 DNSKEY（密钥完全不同，keytag 也不一样），但注册商那边的 DS 记录还留着 Cloudflare 时代那一串。于是验证链就断了：父区说"域名的密钥指纹是这个（旧的）"，新权威说"我的密钥是那个（新的）"，对不上，任何开了 DNSSEC 校验的解析器都会认为这个域名不可信，直接 SERVFAIL。
为什么"一半人正常一半人不正常"也解释得通。不是所有递归解析器都做 DNSSEC 校验。Google 的 8.8.8.8、Cloudflare 的 1.1.1.1 这类默认开校验，拿到 SERVFAIL 就返回给用户，表现为打不开。而一些解析器（国内不少运营商递归、部分企业内网 DNS）没开或没严格开校验，照样把解析结果返回，表现为正常。所以故障现场最常见的迷惑点就是：同一个域名，我这儿 SERVFAIL，同事那儿秒开。
定位命令按这个顺序：
dig 域名 A
dig 域名 A @1.1.1.1
dig 域名 A @223.5.5.5
第一个和第二个都 SERVFAIL、第三个正常，就高度怀疑是 DNSSEC 校验挂了。接着看 DS 和 DNSKEY：
dig DS 域名 +short
dig DNSKEY 域名 +short
DS 后面那串里有一个 key tag（比如 20679），DNSKEY 的 key tag 是另一个（比如 38571）。对不上，就是孤儿 DS。想直接看校验结果，dig 加 +dnssec 看响应里有没有 ad（authenticated data）标志，SERVFAIL 那路是不会有 ad 的。
修复就是去注册商把旧的 DS 记录删掉。删完不是立刻恢复：DS 记录在父区也有 TTL，.com 这类顶级域的 DS 缓存最长能到两天，实测一般几十分钟到几小时就散。删掉后，验证链变成"父区没有 DS → 域名不启用 DNSSEC → 不做校验直接放行"，解析就正常了。
吃一堑长一智，把 DNSSEC 的几个操作原则记死：
- 换 DNS 服务商之前，先去注册商删 DS 记录（或把 DNSSEC 整个关掉），再改 NS。顺序反了就会出现这次的孤儿 DS。如果是同一天操作，改 NS 和删 DS 之间会有几小时到一天的校验失败窗口，尽量夜里操作减少影响。
- 反过来，从"没有 DNSSEC"切到"启用 DNSSEC"，正确顺序是：先在 DNS 服务商那边生成/开启 DNSSEC，拿到它给的 DS，去注册商添加 DS，等父区 DS 生效（dig DS 能看到新值）之后，才真正算启用。DS 没到父区之前就宣称"开了 DNSSEC"，那只是开了半截。
- 别同时改 NS 和动 DS。要么先让新 DNS 跑稳、DS 同步好，再切 NS；要么先删 DS 让验证降级，再切 NS，随后重新配 DNSSEC。两条路选一条，别一步到位。
- 排 SERVFAIL 时先问自己：这台域名开过 DNSSEC 吗？换过 DNS 吗？两个都点头，八成是 DS 没跟上。比自己抓瞎看一晚上配置强。
补一句，这次事故的教训不只是技术层面：改任何带"验证链"的东西（DNSSEC、CAA、证书信任链）都要考虑"中间态"，两头没对齐的窗口期就是故障期。现在的做法是 DNS 变更永远留回退方案，DNSSEC 相关操作放在变更窗口做，改完盯半小时 dig 结果再收工。
补充一个更隐蔽的版本：如果只是把 NS 切走、DS 没删，而新解析商本身也支持 DNSSEC，那正确做法不是删 DS，而是把 DS 更新成新解析商的 keytag。我这次图省事直接删了 DS，等于整条链降级成不校验，安全上打了个折扣。对安全性敏感的场景，应该去注册商把 DS 改成新值，然后 dig DS 确认父区已经返回新 keytag、dig DNSKEY 能和它对上，再观察解析器有没有恢复 ad 标志。DS 在父区有独立 TTL，改完要等它过期，通常比预想久，别改完两分钟就下结论。