笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
构建产物带 hash 老文件不删，dist 越滚越大
查服务器磁盘的时候发现项目 dist 目录有几百 MB，进去一看 assets 底下躺着一堆一年前的 hash 文件，app.3f2a91b2.js 这种，好几个版本都在。明明每次构建文件名都带 hash，新文件会生成，可老文件一直没清，目录只会越来越大。
先搞清楚 vite 构建清理的机制。vite build 默认会清空 outDir 再写，条件是 outDir 在项目根目录内部，这时候 emptyOutDir 默认 true，每次构建都是干净的。问题出在两种常见情况：一是把 outDir 配到了项目根目录外面（比如直接配到 nginx 的站点目录 /var/www/app），这时候 vite 为了安全默认 emptyOutDir 变成 false，还给你打一行警告，于是每次构建只追加不清除，老 hash 文件全留着。二是构建产物先出到 dist，部署时用 rsync 同步到服务器，但命令里没加 --delete，服务器上已有的老文件永远不会被删。
我当时就是 rsync 没带 --delete。部署脚本大概是 rsync -avz dist/ user@server:/var/www/app/ 这种，-a 归档 -v 详细 -z 压缩，唯独没有 --delete。--delete 的作用是让目标目录里源端没有的文件一并删掉，不加它，rsync 只增不删。加上 --delete 之后，本地 dist 里没有的老 hash 文件，服务器上会被清掉，两边保持一致。改完跑了一次，dist 从几百 MB 掉回几十 MB。
但 --delete 有个前提：源目录得是完整的。如果构建是在服务器上做的，那就先本地清干净再传，或者构建脚本里先 rm -rf dist。CI 里常见的坑是缓存了 dist，导致每次构建基于上次的残留，老文件一直混在里面，构建前强制清一次最稳妥：
rm -rf dist
npm run build
rsync -avz --delete dist/ user@server:/var/www/app/
还见过一种部署方式是把每次的构建包按时间或版本号存目录，nginx root 指到一个软链，发版时改软链指向新目录，老目录留着方便回滚。这种方式下旧版本目录会一直占着磁盘，属于有意保留，但保留几份就够了，时间久了要手动清，别每个版本都留着，我见过留了二十几个 release 目录把 40G 数据盘塞满的。
老 hash 文件堆着不只是占磁盘，还有安全面：旧版本里可能带着已经删掉的调试接口、旧的环境变量、甚至泄露出还没来得及撤的密钥。尤其 SPA 全是静态文件，谁都能直接访问，旧 js 里的硬编码 secret 等于裸奔。所以构建清理不只是磁盘卫生，也是收窄暴露面。定期检查一下站点目录，find 按时间列出一年没动过的文件，该清就清。
CDN 那边同理，如果静态资源上了 CDN 并且源站没删，CDN 上的旧对象也会一直留着计费。给 CDN 桶配生命周期策略定期清，或者发布时同步删旧对象，别只在源站清。我这边源站清了之后 CDN 上还有一堆历史对象，后来给桶加了 90 天自动清理规则才消停。这块容易漏，因为源站磁盘满了会有感知，CDN 对象计费是后知后觉的。
怎么判断哪些文件是没人引用的孤儿？SPA 的入口只有一个 index.html，里面引着当前版本的 js/css，其它带 hash 的文件理论上都该是历史版本。先看当前 index.html 引了哪些：
grep -oE '[a-zA-Z0-9._/-]+\.(js|css)' dist/index.html | sort -u
拿这份清单跟 dist/assets 里的文件比对，清单里没有的基本就是孤儿。不过手动比对几百个文件不现实，我一般直接按时间清：半年以上没动过的 assets 文件，基本可以确认当前版本不会引用，因为 hash 一变文件名就跟着变，老文件不会再被新页面用到。
清理命令要注意别误删正在用的文件。稳妥做法是先 rsync --delete 干一次（源是干净 dist），再用 find 兜底扫超期文件：
find dist/assets -type f -mtime +180 -delete
-mtime +180 表示修改时间超过 180 天的，删之前先不加 -delete 跑一遍看列表，确认没有当前版本的文件再真删。也可以先 mv 到一个 backup 目录观察几天，确认线上没报资源 404 再清掉，求稳。
还有一个隐蔽的积累点：vite 的 public 目录。public 里的文件是原样拷贝进 dist 的，不进 hash 体系，如果部署脚本把 public 里的旧文件也带过去了，这部分不会触发 emptyOutDir 清理逻辑，得单独管。我见过有人把要下发的静态资源随手扔 public，结果 dist 里积了一堆手工维护的文件，跟 hash 清理是两条线。
教训是部署脚本里必须有一个"清理旧产物"的动作，要么 rsync --delete，要么构建前 rm -rf dist，二选一，别裸 rsync。我现在发布脚本固定是清 dist、build、rsync --delete 三步走，完事对比一下服务器和本地 assets 的文件数，数字对不上基本就是清理环节失效了，会立刻暴露，不用等磁盘报警。