笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
proxy_pass 反代目标结尾带不带斜杠，转发路径差一截
给 Node 接口层配 nginx 反代，前端调 /api/user，后端 express 路由明明写的是 /api/user，却一直 404。后端 access log 打出来，收到的路径是 /user，/api 前缀整个被剥掉了。折腾半天才意识到是 proxy_pass 反代目标末尾斜杠的问题。
nginx 里 location 加 proxy_pass 时，反代目标带不带 URI 部分（最常见的"带不带结尾斜杠"），转发规则完全不一样，这是反代最容易踩的坑之一。规则就一条：proxy_pass 后面如果只写了协议加主机端口、没有 URI 部分，就把客户端原始的完整 URI 原样转发；如果反代目标里带了路径（哪怕只是一个斜杠 /），就会用这个路径替换掉 location 匹配到的那段前缀。
举我实际的例子。location 匹配 /api/，反代目标不带 URI：
location /api/ {
proxy_pass $scheme://127.0.0.1:3000;
}
请求 /api/user，后端收到的是完整的 /api/user，前缀没动。后端 express 路由按带 /api 前缀写的，这个写法就对。
那想剥掉前缀怎么办？普通写法（proxy_pass 不带变量）里，反代地址的主机端口后面只要跟了路径，哪怕只是一个斜杠，nginx 就会用这段路径去替换 location 匹配到的那一段前缀。同样是 /api/user，反代地址末尾多了个斜杠之后，/api/ 被整个换掉，后端收到的路径变成 /user。我最早把斜杠当成可选的装饰，觉得加不加无所谓，结果前后端 404 排查了一下午，后来拿两条日志一对才明白差在这。
后缀不带斜杠：/api/user 原样透传，后端收到 /api/user。
后缀带一个斜杠：/api/ 前缀被替换成 /，后端收到 /user。
这两种没有绝对的对错，全看后端路由怎么设计。后端接口按带 /api 前缀写的，用不带斜杠那版；后端内部没有 /api 这层、前端统一从 /api/ 进来，就用带斜杠那版把前缀剥干净再转发。
最容易翻车的场景是前后端约定不一致：前端以为调的是 /api/user，后端接口文档写的也是 /api/user，但反代层悄悄把前缀剥了，后端当然 404。反过来，后端路由没写 /api 前缀，反代又不剥，后端也会 404。所以排查这类 404 先别改代码，先看后端到底收到了什么路径。
确认后端收到什么路径最直接的办法是看后端日志。express 里加一行 morgan 日志或者临时打印 req.url，反代配完打一个请求就能看到真实转发路径：
curl -s 127.0.0.1/api/user -o /dev/null
然后去后端日志看打印出来的 path 是 /api/user 还是 /user，一目了然。比在 nginx 配置里猜半天强。
还有个连带坑：location 本身带不带尾斜杠也会影响替换结果。location /api 和 location /api/ 匹配的范围不一样，前者能匹配 /api、/apiabc 这种，后者只能匹配 /api/ 开头的。如果 location 写 /api 不带斜杠、proxy_pass 目标带斜杠，替换出来容易拼出双斜杠，比如请求 /api/user 可能变成 //user，后端收到 //user 又是一通 404 或者路由错乱。建议 location 和 proxy_pass 的斜杠风格统一，要么都带，要么都走无 URI 的原样转发，混着写最容易出鬼。
这类问题还有一个隐蔽变种：proxy_pass 里用了变量（比如 $scheme 这种）之后，nginx 的行为会变，URI 替换逻辑不再按普通规则走，而是把变量解析出来的值当目标。所以网上抄配置看到 proxy_pass 带变量、又带路径的，要格外小心，行为跟你以为的可能不一样。我一般能不用变量就不用，写死协议加端口最不容易出错。
再补一句排查心法，反代转发路径不对的时候，先分清是 nginx 层改的路径还是后端自己路由的问题。用 nginx 的 access log 看 nginx 收到什么，用后端 access log 看后端收到什么，两条日志一对，路径是在哪一层被改的一清二楚，别上来就改后端代码。我自己吃过亏：一 404 就去改 express 路由，把 /api 加上又去掉来回试，折腾半天，其实反代层一个斜杠的事，看日志五分钟就能定位。