笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
头像上传目录被人放了 PHP 马：nginx 里把 uploads 的执行权掐掉
一个 PHP 站点，有头像上传功能，传上来的图片放在 /var/www/html/uploads 下。某天被人传了个 PHP 文件进去，直接通过网址访问就能执行，服务器被拿去当跳板扫别人。查下来漏洞链条不复杂：上传接口只校验了文件后缀和 Content-Type，攻击者把 PHP 代码塞进一个伪装文件传了上来，而 nginx 的配置把凡是 .php 结尾的请求都丢给了 php-fpm 处理——包括 uploads 目录里的。等于上传目录既是别人能写文件的目录，又是能执行代码的目录，两个条件凑齐就 getshell 了。
修的方向很明确：让上传目录里的 PHP 执行不了。nginx 的配置核心在于 location 的匹配顺序。一般站点会有这么一段把 PHP 请求转发给 php-fpm：
location ~ .php$ {
include fastcgi_params;
fastcgi_pass unix:/run/php/php8.2-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
这段对整站生效，uploads 下的 .php 也会命中，因为正则 location 不区分目录。想掐掉 uploads 里的执行，要利用 nginx 的匹配优先级：^~ 开头的前缀匹配命中之后，不再继续找正则 location。所以在 server 块里加一段：
location ^~ /uploads/ {
location ~ .php$ { return 403; }
}
第一行 ^~ /uploads/ 把所有 uploads 下的请求都拦进这个块，块里再嵌一个只匹配 .php 的 location，返回 403。这样 uploads 里任何 .php 的访问都会被拒绝，而正常的图片请求不受影响，会继续往下走静态文件处理。改完记得 nginx -t 测配置，再 reload。
光有 nginx 这层还不够，因为如果攻击者上传的文件不带 .php 后缀，但内容能被包含执行，nginx 这层就拦不住。常见的二次利用是把马藏在图片里，再用文件包含漏洞去执行，所以源头还是上传校验。我后来把上传逻辑改了几处：文件后缀白名单改成只允许图片那几种，且不只查后缀，还要用 getimagesize 验证文件头确实是图片；文件名重命名成随机串，不让攻击者控制路径；上传目录挪到网站根目录外面，比如 /data/uploads，前端通过一个下载脚本输出图片，目录本身不做静态文件服务。这三条一起，能把“传上来就能执行”的路基本堵死。
php-fpm 那边也有个保险可以开。php.ini 里的 security.limit_extensions 默认是 .php，意思是 fpm 只执行 .php 后缀的文件，像 .php.jpg 这种双后缀默认不会被执行。但注意这防的是双后缀绕过，防不了直接传 .php 文件，因为 .php 本身在允许列表里。真正管用的还是把执行权从上传目录剥离，而不是指望后缀校验。
另外顺手把历史遗留的 shell 清一清。出事的站点我建议直接找近期新增的可疑文件：find /var/www -type f -name ".php" -newermt "2026-08-01" -ls，把网站目录里最近一个月新增的 PHP 文件全列出来，挨个看是不是自己写的。还有按内容特征找的：grep -rlE "eval(|base64_decode(|system(|shell_exec(" /var/www/html --include=".php"，命中的文件如果不在自己代码里，基本就是马。清理的时候先备份再删，别把正常代码误删。
上传目录权限也要配合收敛。uploads 目录属主改成 php-fpm 的运行用户，权限 755 而不是 777，让 Web 进程能写自己的文件就行，别给所有人可写。这跟之前记的那条全盘 777 排查是一套思路：能写文件的目录，就不要再给它执行代码的能力。nginx 掐执行、上传校验白名单、目录移出 web 根、可疑文件定期扫，这几层叠起来，图片上传这个入口才算稍微让人放心。折腾完这次，我把那台机器整个检查了一遍，crontab、authorized_keys、/etc/passwd 都没异常，应该是只被放了马、没被种后门，算是不幸中的万幸。