笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
set -e 挡不住管道失败，脚本照样跑完
备忘一下自己备份脚本里踩的坑。脚本开头明明写了 set -e，结果管道中间那段命令挂了，脚本愣是没停，还一路往下跑，等真用到备份才发现产物是坏的。
当时的脚本大概长这样：
#!/bin/bash
set -e
mysqldump -u root mydb > dump.sql
gzip dump.sql
scp dump.sql.gz backup-server:/data/
这个写法其实没事，每行都是单条命令，任何一条非零 set -e 都会让脚本退出。真正的坑是我后来图省事，把导出和压缩并成一条管道：
set -e
mysqldump -u root mydb | gzip > dump.sql.gz
scp dump.sql.gz backup-server:/data/
有阵子 mysqldump 因为目录权限报错了，我以为 set -e 会立刻掐掉脚本，结果它照样跑到 scp 结束、日志还打成功。原因很基础：管道的退出码默认取最右侧那段命令的退出码，gzip 这边是成功的、返回 0，整个管道就是 0，set -e 根本看不见前一段 mysqldump 已经失败。bash 只看管道最右那一个的退出码，这是我以为 set -e 万能时翻的第一个车。
修法是补一个 pipefail：
set -euo pipefail
u 是碰到未定义变量就报错，o pipefail 让管道里任意一段非零整条就算非零。加上之后 mysqldump 一挂，管道退出码跟着非零，set -e 才会把脚本停住。我现在新写的脚本开头基本都是这一行。
可加了 pipefail 又冒出第二个坑：有些命令本来就会提前关掉管道，把前一段活活带崩。最典型的是 cmd | head，比如从日志里抓关键字只看前 10 行：
set -o pipefail
grep ERROR app.log | head -n 10
head 读完 10 行就关管道走人，grep 那边还在拼命写，撞上 EPIPE 被 SIGPIPE 信号干掉，退出码是 141。管道里有 141，整条管道被判失败，脚本就被"误杀"了。头一回见 141 我还以为是脚本别的 bug，后来把管道每一段的退出码都打出来才看明白。
set -o pipefail
some_noisy_command | head -n 5
echo "各段退出码: ${PIPESTATUS[@]}"
PIPESTATUS 是数组，下标 0 是第一段、下标 1 是第二段，顺着排。看到 [0] 是 141 就知道是前面被信号打断，不是它自己出错。想对 head 这种用法网开一面，可以单独放开管道末段：
set -o pipefail
grep ERROR app.log | head -n 10 || true
但 || true 会把真正的失败也一起吞掉，所以只适合"管道末段就是无所谓成败"的场合。更干净的做法是把要容忍的那一步放进 if 条件里。放在 if 或 while 条件里的命令，set -e 本来就豁免，不会因为非零退出，这是 bash 文档里写明的规则，跟想象中"任何非零立刻退出"不一样。像 grep 匹配不到返回 1、diff 有差异返回 1，这种拿退出码当结果的命令，放条件里才安全；直接裸写在脚本中间，碰上 set -e 就把自己搞挂。
set -euo pipefail
if grep -q "pattern" file; then
echo "命中"
else
echo "没有匹配，正常继续"
fi
函数里还有一个更阴的变体：local x=$(false) 这种写法。local 本身是内建命令，它的退出码是 0，把后面命令替换里 false 的真实状态整个盖掉了，set -e 在函数里就此失灵。我以前排过一个多小时没头绪，后来拆开写才解决：
# 错误写法：local 把失败状态吞了，函数还会继续往下跑
func() {
local x=$(false)
echo "这句还是会执行，x 是空的"
}
# 正确写法：先执行、检查退出码，再交给 local
func() {
local x
x=$(false) || return 1
echo "到不了这里"
}
为了排这种无声失败，我后来习惯在脚本开头加一个 ERR trap，配合 set -e 一起用：
set -euo pipefail
trap 'echo "第 $LINENO 行出错，退出码 $?" >&2' ERR
trap ERR 会在任意命令失败时先喊一嗓子，把行号和退出码打出来。就算 set -e 因为某些豁免没拦住，ERR 陷阱也多半能捕捉到，比脚本静默跑完再回头猜强太多。管道里具体哪一段失败，光靠 trap 还分不清，要配 PIPESTATUS 一起看才完整。
到现在 set -e 那些豁免细节我也没吃透，比如子 shell 里、函数里、命令替换里到底会不会退出，每次都不一样。遇到诡异行为我就 bash -x 跑一遍，看它实际停在哪一行、退出码是多少，比对着文档猜快。一句话给自己备忘：凡是会正常返回非零的命令，要么进 if 条件，要么显式存退出码再判断，别裸放；管道要么不用，要么配好 pipefail 再处理 SIGPIPE，不然 set -e 只是个摆设。