笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
CF Worker 绑自定义域名失败？
把一个小工具写成 Cloudflare Worker 后，想挂到自己的子域 tools.xxx.com 上，而不是用 CF 送的那个 workers.dev 域名。折腾了一晚上，把流程里几个坑都踩了一遍，记下来免得下次再犯。
先说结论：Worker 绑自定义域名，域名必须是一个"在 Cloudflare 上 active 的 zone"。我最初域名托管在阿里云，NS 完全不在 CF，直接在 Worker 的 Custom Domains 里填 tools.xxx.com，页面一直报错，大意是让我先把这个域名加进 Cloudflare（add a site），我一开始还以为是 Worker 配置写错，反复删了重建，纯浪费时间。
顺带把背景理清楚，CF 的 Worker 默认挂在 *.workers.dev 下，workers.dev 整个域名是 CF 自己保留的。早期有人想绕开"必须托管给 CF"的限制，在自己注册商那边把子域 CNAME 指到 workers.dev 的某个子域，想着 CF 边缘解析完直接回源到 Worker。这条路后来被 CF 收紧了，而且 CNAME 指过去后实际能不能路由到 Worker 受很多因素影响，遇到过的表现是时通时不通、或者访问时报错页面。现在官方推荐并且可靠的做法就是 zone 托管到 CF，然后用 Custom Domain 或 Route 绑。
DNS 层还有个根因，就是裸域（apex）在标准 DNS 里不能直接 CNAME。CNAME 要求这个名字下面不能再有其它记录，而根域通常都有 MX、TXT 这些，所以传统 DNS 里根域没法 CNAME 到任何地方。CF 能让你把 example.com CNAME 到一个目标，是靠它内部的 CNAME Flattening（展平）——CF 在边缘替你解析目标，把结果当作 A/AAAA 返回。Worker 没有固定 IP，纯靠 A 记录指不到它，所以想用根域绑 Worker，域名就必须在 CF 上，借它的展平能力。如果域名不在 CF，你自己的注册商即便支持 ALIAS/ANAME，也不一定解析得到 Worker 的地址，稳定性看运气。
操作上有几个具体坑：
- Custom Domain 添加成功后，CF 会自动在 DNS 里建一条 CNAME 记录，指向形如 xxx.your-worker.workers.dev 这样的目标（我理解是 Worker 在 CF 内部的标识），并且这条记录是橙云状态。别手贱把它切成灰云，一灰掉流量就不再经过 CF 边缘路由到 Worker，访问会直接落到空上，表现是 522 或超时。
- 如果你之前为了别的事给 tools.xxx.com 建过一条灰云的 A 记录，这里会冲突。Custom Domain 和 Route 都要占用这个主机名，旧的灰云记录不删，Worker 路由永远接不上，症状同样是访问不到 Worker。
- 两个 zone 互相抢同一个主机名会报错。如果 tools.xxx.com 这个子域已经在另一个 CF 账户的 zone 里被某个 Worker 占用，你这边添加时会提示主机名已被使用。需要去那个账户释放，或者换子域。
- Route 和 Custom Domain 是两种绑法。Route 写法是 tools.xxx.com/* 这样带路径，匹配到这个主机名的请求才进 Worker；Custom Domain 更省事，添加完自动把整站指过去。两者都要求 zone 在 CF。我用的是 Custom Domain，少配一层。
- 绑定完成后不是立刻全局生效。我这边添加完大概过了一两分钟访问才稳定，期间偶发 522。因为边缘配置要下发到各地 PoP，别刚加完就疯狂刷新判断失败，等几分钟再看。
如果域名真的不方便整体托管到 CF（比如有邮件服务、要保留注册商 DNS），还有一个办法是把 Worker 的请求地址换成 Cloudflare Tunnel 或者用自己另外一台能绑定的域名做跳板，但那属于另一套架构，为了一个小工具不值当，拖到后头我还是决定把域名整个迁到 CF 托管：NS 切过去，Mail 相关记录原样搬进 CF 的 DNS，跑了两周没出问题，比绕路省心。
排错时最有用的两个检查：看 zone 状态是不是 active，看 DNS 记录里那条自动生成的 CNAME 是不是橙云。两个都对，Worker 的 Routes 列表里能看到自定义域名，那就是好的。
还有一个我纠结过的点：绑定用 Custom Domain 还是 Route。Custom Domain 会把整站都指向 Worker；如果这个子域还想顺带服务静态文件，或者按路径分给别的 Worker，就要用 Route，按路径前缀做区分。Route 灵活，同一个域名下能挂多个 Worker，按路径分流；代价是每条 Route 都要自己保证和 DNS 记录不冲突，多一层维护。纯工具站只有一个 Worker 的话，Custom Domain 最省事，我后面也一直是这么用的，加完自动生成 CNAME 记录，橙云状态不用管。