笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
systemd timer 该跑没跑，日志得去 service 里翻
备忘一条 systemd timer 的坑，搭进去小半个晚上才理清。
想给 mysql 加一个每天凌晨的备份，照老习惯写了两个 unit 放到 /etc/systemd/system/ 下面。一个是干活的，一个是闹钟：
# /etc/systemd/system/backup-mysql.service
[Unit]
Description=run mysql backup script
[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup-mysql.sh
# /etc/systemd/system/backup-mysql.timer
[Unit]
Description=daily mysql backup at 02:30
[Timer]
OnCalendar=*-*-* 02:30:00
[Install]
WantedBy=timers.target
写完 systemctl start backup-mysql.timer 手动验证，又顺手 systemctl start backup-mysql.service 跑了一次，备份文件正常出来，mysqldump 的输出也都在，就以为收工了。
第二天早上看 /backup 目录，还是昨天那个文件，一整天没新增。先查状态：
systemctl list-timers --all
输出里 backup-mysql.timer 的 NEXT 指着明天 02:30，LAST 那列是 n/a。n/a 的意思是这台机器上这个 timer 从来没成功触发过——我手动 start service 的那次不算 timer 的账，它只是把服务跑了一遍，闹钟的指针没动过。
真正的问题是我只 start 了 timer，没 enable。start 只是把 timer 拉起来等下一个触发点，机器一重启它就消失了；enable 才会在 /etc/systemd/system/timers.target.wants/ 下建好软链，让开机时自动带上这个定时器。而且我一开始差点 enable 错对象——想着"让备份开机自启"，手就伸向 backup-mysql.service。service 是 oneshot，enable 它只是说"允许它被触发时运行"，没有 timer 管着，它永远不会自己到点跑。闹钟要 enable 的是 timer 本体：
systemctl enable --now backup-mysql.timer
日志去哪看是另一个绕了很久的点。timer 自己不产生业务日志，它到点把 service 拉起来以后，真正的输出全在 service 的 unit 里。排查按这三个地方来：
systemctl list-timers --all # NEXT/LAST 两列，LAST 是 n/a 说明从没触发过
systemctl status backup-mysql.timer # 能看到上次 Triggered 的准确时间
journalctl -u backup-mysql.service # 备份那次会话的真实日志在这里
我一开始只 journalctl -u backup-mysql.timer，翻到底没几行有价值的，因为 timer 打印的东西极少。用 journalctl -u 'backup-mysql.*' 能把 timer 和 service 两段的日志一次拉出来对照，谁在什么时候触发了谁、脚本跑到哪一步停的，都看得比较清楚。顺手记一下 journalctl --since "yesterday" -u backup-mysql.service 这种时间窗过滤，排查"昨天到底跑没跑"很实用。
再补一个这次才彻底弄明白的点：OnCalendar 走的是实时时钟，也就是墙上时间。机器到点如果正好关机或者休眠，这次触发就直接错过，不会等你回来补。数据库备份漏一次就可能要出事，所以在 [Timer] 段加一行：
Persistent=true
加了以后，下次开机 systemd 发现上次计划触发点已经错过，会立刻补跑一次。日志归档、数据库 dump 这类任务建议都带上这个开关。代价是补跑可能发生在你没想到的时间点，比如周一早上开机先把周末漏的备份跑了，脚本本身要能容忍重复执行，别搞出主键冲突那种事。
OnCalendar 的写法校验有个小工具，别靠肉眼盯：
systemd-analyze calendar "*-*-* 02:30:00"
它会直接打印下一次、再下一次的触发时间。写错格式（比如把 02:30 写成 2:30，或者漏了秒段），当场就报给你，比写完丢进去等一天再发现强太多。
还踩到一个相关的小问题：timer 触发之后 service 跑失败，systemd 默认不会重试，除非你在 service 里配 Restart=on-failure。oneshot 型的 service 我一般会加 Restart=on-failure 和 RestartSec=30，配合 Persistent=true，基本能覆盖"夜里数据库刚好在重启、mysqldump 连不上"这类偶发。
timer 到点没跑先别急着怀疑 cron 和脚本本身，按 enable 有没有做 → list-timers 看 LAST 是不是 n/a → 去 .service 的 unit 翻日志，这个顺序基本能定位到是闹钟没响、还是响了没干活。脚本本身我后来又手动跑了两次确认没问题，锅全在 systemd 这层。Persistent 补跑有没有按预期生效，过两天再观察一轮。