笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
证书老签不下来？CAA 记录自己在挡
给一个客户的域名签 Let's Encrypt 证书，certbot 一跑就报错，报错里带 CAA 字样：
Error creating new order :: CAA record for example.com prevents issuance
一开始以为是 Let's Encrypt 那边临时抽风，重试了好几遍都一样。后来去 dig 才发现，客户之前为了"只允许某一家 CA 给他们签"，在 DNS 里加了 CAA 记录，白名单里没有 Let's Encrypt，于是我把这事彻底搞清楚了。
CAA（Certification Authority Authorization）是 DNS 里的一种记录，作用是声明"这个域名允许哪些 CA 来签发证书"。收件方是 CA 自己：每次签发前 CA 会去查这个域名的 CAA 记录，发现里面不允许自己，就直接拒绝发证。记录语法长这样：
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
0 是 flag（现在基本都用 0），issue 是标签，表示"允许给这个域名签终端证书的 CA 是 letsencrypt.org"。想看自己域名现在有哪些 CAA：
dig CAA example.com +short
没输出说明没有任何 CAA 记录，那就等于不限 CA，谁都能签。如果有输出，一长串 issue 里得包含 letsencrypt.org 才行。上面那个报错就是在没有 letsencrypt.org 的情况下触发的。
几个 CAA 的行为细节值得记：
- CAA 是沿 DNS 树继承的。在 example.com 放了一条 CAA，它下面的 blog.example.com、api.example.com 全都继承这条约束，除非子域自己再放一条 CAA 覆盖。所以如果父域只允许 digicert，子域想用 Let's Encrypt 也会被拦，报错会出现在子域名上，容易让人以为是子域单独的问题。
- 通配符证书走的是 issuewild 标签。签 *.example.com 时 CA 会额外看 issuewild，如果只放了 issue 没放 issuewild，有些 CA 对通配符会拒绝。要给通配符留口子就写：
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
- 放 CAA 不会影响已经签下来的证书，它只管"将来签发的"。所以把 CAA 改对之后，不用等旧证书过期，重新跑一次签发就行。
- 修完记录不是马上能签，CAA 查询也走 DNS，有 TTL。改了 CAA 后等个几分钟到 TTL 过期再跑 certbot，不然查到的还是旧记录，报错不变，容易误判成没改对。可以用 dig 确认新值已经能查到再重试。
修复就是往现有 CAA 记录集合里补一条 letsencrypt.org，而不是删掉客户的限制。原来那条允许 digicert 的保留，加一条允许 LE 的，两条可以共存：
example.com. 3600 IN CAA 0 issue "digicert.com"
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
多个 CAA 记录的关系是"或"，只要有一条允许某 CA，该 CA 就能签。域名托管在 Cloudflare 的话，CAA 记录可以在面板里直接加，也可以在 API 里加，注意别在 UI 的"证书"相关设置里开 CF 自己的 Universal SSL 之外另加冲突项。
排查方向反过来也成立：如果某天某张证书突然签不下来，先去 dig CAA 域名 +short 看看是不是最近加了 CAA 或改了托管。很多"昨天还能签今天不行"的案例，多数是安全策略里加 CAA 时把正在用的 CA 漏了。这个客户后来回忆，是半年前做安全加固时照着网上"如何限制 CA"的帖子加的，加完就忘了，直到这次要签新证书才炸出来。CAA 是个好机制，但加的时候要把现状列全，别让安全加固变成证书事故。
还有一层层级关系容易搞反：CAA 在 DNS 树上是"就近生效"。example.com 有一条 CAA，而 blog.example.com 自己没有 CAA，那么查 blog.example.com 时会继承父域的约束；但一旦在 blog.example.com 单独放了 CAA，就以它自己的为准，父域的约束管不到它。所以如果限制是加在子域上的，只改父域不一定放行，得改到真正出问题的那个名字。改完别只 dig 父域，出问题的域名在哪一层就 dig 哪一层的 CAA。签发是 CA 侧实时查记录，修完 DNS 再重跑一次签发，能过就说明 CAA 这关通了，不用等旧证书自然过期再验证。