笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
激活了 venv，pip 却还在往全局 Python 里装
记录一个困扰了我快半小时的环境问题：source 进了虚拟环境，提示符前缀都变成 (venv) 了，跑 pip install 却装到了系统 Python 里，import 死活找不到包。结果发现不是 pip 的问题，是 bash 的 hash 缓存没刷新。
先交代环境：Debian 12 的机器，系统自带 Python 3.11，我给项目建了虚拟环境：
python3 -m venv .venv
source .venv/bin/activate
激活之后我顺手敲 pip --version 确认，输出的路径还是 /usr/bin/pip 而不是 .venv/bin/pip。这就说明 activate 虽然改了 PATH，但我这个 shell 里 pip 还指着旧位置。
原因很基础：bash 会记住你执行过的命令的全路径，存一张 hash 表。第一次敲 pip 的时候它找到的是 /usr/bin/pip，就把这个结果缓存了。activate 脚本只是往 PATH 前面加了 .venv/bin，并不会清掉 hash 表里已经记住的旧路径，于是你再敲 pip，bash 直接命中缓存的旧路径，压根不去新 PATH 里找。python 命令也一样，可能缓存了 /usr/bin/python3。
修法一句话：清掉 hash 缓存。
hash -r # 清空整张命令路径缓存
# 或者只清 pip 一条
hash -d pip
清了之后再 which pip，才会去 PATH 里重新找，回到 .venv/bin/pip。验证到底用的是哪个解释器，最稳的其实是让 Python 自己说：
python -c "import sys; print(sys.prefix)"
# 在虚拟环境里应该输出 /home/me/proj/.venv
sys.prefix 指向当前解释器真正的家，比 which 可靠，因为 which 只反映 PATH 查找结果，而 python -m 这种调用方式用的是当前解释器。
后来我干脆养成习惯：在虚拟环境里装包一律写 python -m pip install，不写裸 pip。python -m pip 等价于"拿当前这个 python 去跑 pip"，pip 装哪完全跟着解释器走，hash 缓存骗不了它。很多教程写 source activate 之后就裸 pip，对新手就是埋雷，尤其机器上装过多个 Python 或者用过 pyenv、conda 的，PATH 乱成一锅粥，裸 pip 指向哪全靠运气。
还有个常见连带现象值得记一下：Debian 12 起 pip 对系统解释器默认开了 PEP 668 保护，直接用系统 pip 装包会报：
error: externally-managed-environment
This environment is externally managed
意思是系统 Python 归 apt 管，不让 pip 随便往 site-packages 里塞东西，避免和 apt 的 python3-xxx 包打架。碰到这行别跟它硬刚，正确姿势就是建虚拟环境再装，或者用 pipx 装那种要全局用的命令行工具。我在别的机器上见过有人为了绕这行去加 --break-system-packages，结果某次把系统里一个被 ld 依赖的包升级坏了，属于得不偿失。
还有一个放大镜是 PATH 顺序本身。如果机器上同时有 pyenv、手动编译装到 /usr/local/bin 的 Python、或者装过 conda，activate 只是把 .venv/bin 插到 PATH 最前面，理论上优先级最高。但架不住哪天你手滑又 source 了第二个环境，或者自己 export 了别的路径到最前，python 和 pip 的指向就乱套了。which -a python 能把 PATH 里所有 python 按顺序全列出来，排最上面那个才是实际会执行的；type -a pip 同理。看到不止一个结果，就顺着 PATH 一项一项查，基本能找出是谁把该用的那个挤掉了。
刚建出来的 venv 里 pip 版本一般偏旧，我习惯顺手升一下：python -m pip install --upgrade pip。这个动作本身也是检验——如果升级完 pip --version 还指着旧路径，说明根本没进对环境，hash 缓存或者 PATH 还压在头上。新版 pip 装包时会打印目标环境路径，比如装到 /home/me/proj/.venv/lib/python3.11/site-packages，多瞄一眼输出能省掉一堆排查时间。
排查这类"装没装对地方"的问题，我的固定套路就三步：先 which -a pip 看 PATH 里到底有几个 pip、各在哪；再 python -m pip --version 跟 pip --version 对一下，两个路径不一致就是有人在偷梁换柱；第三步用 python -c "import sys; print(sys.prefix)" 确认解释器。大部分环境错乱，走完这三步都能定位到是 PATH 顺序还是 hash 缓存。到现在我也没把 pyenv 那套 shim 机制完全搞懂，反正项目里只用 python3 -m venv 建出来的干净环境，配 python -m pip 调用，基本不会再踩。