笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
老证书带不了新子域名？SAN 里没它
手头一张证书一直好好的，是当初拿 certbot 一次性签的多域名，里面含 blog.xxx.com 和 api.xxx.com 两个名字，nginx 两个 server 块都用的同一份 fullchain。上周加了个移动端子站 m.xxx.com，图省事直接让新 server 块也引用了同一份证书文件，结果 Firefox 打开直接 SSL_ERROR_BAD_CERT_DOMAIN，Chrome 是 NET::ERR_CERT_COMMON_NAME_INVALID。我第一反应是证书文件坏了，折腾半天才想起来：证书里压根没有 m.xxx.com 这个域名，浏览器红锁是必然的。
要解释清楚就得知道现在的证书早就不看 CN 了。以前 SSL 证书能靠"证书里的 CN 字段"来证明它属于哪个域名，Chrome 58 以后 CN 就不作为匹配依据了，只看 Subject Alternative Name（SAN）扩展里列的名字。一份证书 SAN 里没有 m.xxx.com，配置引用得再对也没用，浏览器只认 SAN。想确认一份证书到底覆盖了哪些域名：
openssl x509 -in /etc/letsencrypt/live/xxx.com/fullchain.pem -noout -text | grep -A1 "Subject Alternative Name"
输出里就是 DNS:blog.xxx.com, DNS:api.xxx.com 这种列表。对着红锁域名看一眼就明白差在哪。线上排查也可以不落盘，直接对端口问：
openssl s_client -connect m.xxx.com:443 -servername m.xxx.com </dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"
修复方向看你要覆盖多少个名字。
如果子域就那么几个，用 certbot 把新域名扩进现有证书：
certbot certonly --cert-name xxx.com -d blog.xxx.com -d api.xxx.com -d m.xxx.com --expand
--expand 会在原来那组域名基础上加新的，不会把旧的挤掉。签完 reload nginx 就好。注意 renew 的时候 certbot 是按证书名记住它当初那组域名，你用 --expand 加的会保留在 cli.ini 里，后面自动续签会继续带这组，不用每次手动写全。
如果以后还会不停加子域，那更适合通配符。*.xxx.com 能覆盖 blog、api、m 这些单级子域，加新子域不用再动证书。但通配符有两个代价：一个是签发的验证方式只能用 DNS-01，Let's Encrypt 不接受 HTTP 方式给通配符发证，意味着你得能在权威 DNS 上临时加 TXT 记录。域名托管在支持 API 的地方（比如 Cloudflare）可以用 certbot 的 dns 插件全自动，否则每次签发和续签都要手动去加一条 TXT，90 天一续，挺烦人。
另一个代价是通配符不覆盖裸域也不覆盖多级。*.xxx.com 不含 xxx.com 本身，想裸域也 HTTPS 得再单独签一张或把裸域也加进 SAN；a.b.xxx.com 这种两级子域通配符也兜不住，要 *.b.xxx.com 才行。当初我要是知道后面会不停加移动端、静态资源、图片子域这类单级域名，直接上 *.xxx.com + 裸域，就省得这次扩 SAN 了。
顺带把 nginx 多证书的选择说明白：可以每张证书各自对应各自的 server 块，靠 SNI 区分，客户端握手时带上要访问的域名，nginx 按 server_name 挑证书。但前提是每块引用的证书 SAN 里得确实有那个域名。让多个 server_name 共用一份证书文件没问题，前提是这份证书 SAN 覆盖所有这些名字。缺名字就去扩 SAN，别去改 nginx 引用，改引用治标不治本，红锁照样在。
还有个细节：扩签或重签后记得 reload，不只是 renew 完就完事。nginx 进程不会自动重新读证书文件，我见过证书明明新签了、页面还是旧证书的情况，多半是没 reload。nginx -s reload 一下再看 SAN，确认新域名已经进去，浏览器强制刷新一把，红锁就没了。