笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
sudo 报 command not found，但我明明装了那个命令
遇到个看着很蠢的问题：普通用户跑一个命令好好的，前面加个 sudo 就报 command not found。比如我自己编译装到 /opt/tool/bin/ 里的工具：
myserverctl status # 正常
sudo myserverctl status # sudo: myserverctl: command not found
命令明明存在，普通用户能执行，为什么 sudo 就找不到？因为 sudo 出于安全考虑，执行命令时用的是它自己的一套 PATH，叫 secure_path，跟当前用户的 PATH 不是一回事。默认的 secure_path 基本就是系统那几目录：
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
你自己加在 PATH 里的 /opt/tool/bin、~/.local/bin、/snap/bin 这些，sudo 根本不认。想验证一下 sudo 看到的 PATH：
sudo printenv PATH
输出会是上面那串默认值，而不是你 shell 里的 PATH，这就解释了为什么找不到。
解决办法看场景。偶尔用一次，直接写全路径最省事：
sudo /opt/tool/bin/myserverctl
经常要用，把目录加进 secure_path。编辑 sudoers 用 visudo，别直接改文件：
visudo
在文件里加一行：
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/tool/bin"
或者用 env_keep 让 sudo 保留用户的 PATH：
Defaults env_keep += "PATH"
但保留用户 PATH 有个安全顾虑：如果用户的 PATH 里有个可写目录，比如当前目录 . 或者 ~/bin，别人往里面放个同名恶意程序，sudo 执行的时候可能就中招了。所以我个人倾向加 secure_path 而不是 env_keep，明确、可控。
还有另一种 manifestation 容易跟这个混：不是在 sudo 后面找不到，而是连 sudo 本身都找不到，bash 直接报 bash: sudo: command not found。这种情况通常是 PATH 被整个覆盖了，比如 ~/.bashrc 里写了：
export PATH=/usr/local/cuda/bin
注意是等号赋值不是追加，把原来的 PATH 全冲掉了，连 /usr/bin 都没了，sudo、ls、cat 全找不着。这种要恢复，可以先用全路径调出命令：
/usr/bin/sudo /usr/bin/vi ~/.bashrc
把 export 那行改成追加写法：
export PATH=/usr/local/cuda/bin:$PATH
改完重新登录或者 source ~/.bashrc。我见过有人在 .bashrc 里手滑少写了 $PATH，导致每次新开 shell 都是半残状态，还不自知。
另外一个相关但不同的场景：用 sudo 跑自己装在 ~/.local/bin 里的程序，secure_path 里没有家目录，一样报 command not found。有些安装器（pip --user、cargo、npm -g）默认都往用户目录装，所以这个坑很常见。这时候与其改 secure_path 把家目录加进去（不太安全），不如用 sudo env 临时带一下：
sudo env PATH="$PATH" 你那个命令
sudo env 会把 PATH 重新设成你当前的，命令就能找到了。这条对我这种经常用 sudo 跑用户态工具的挺顺手，记一下。
还有个坑中坑：sudo 找不到命令的时候，如果命令其实在 secure_path 里的某个目录存在，但那个目录里的可执行文件权限/属主不对，会报 Permission denied 而不是 command not found，别被带偏。用 sudo -l 看看当前用户被允许执行什么，sudo -l 输出里会带 secure_path 的实际值。
排查这类问题我现在的顺序是：先分清楚是"sudo 后面那个命令找不到"还是"sudo 本身找不到"——前者查 secure_path，后者查 PATH 是不是被 export 覆盖了；然后 sudo printenv PATH 看 sudo 实际拿到的路径；再决定写全路径、改 secure_path、还是 sudo env PATH=$PATH 临时带。这次根因是 /opt/tool/bin 不在 secure_path 里，visudo 加进去之后就好了，普通用户那边本来就能跑，说明不是权限问题。