笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
SSR 页面里接口地址渲染成 localhost，内网地址漏给了浏览器
线上 Nuxt3 项目，用户反馈页面里某个"接口状态"小组件永远显示连接失败。自己打开浏览器看渲染出来的 HTML，发现里面写死的接口地址是 localhost:3000。用户浏览器里的 localhost 是他自己的电脑，当然连不上。查代码，问题出在服务端渲染和浏览器端用了同一份接口地址配置。
这个组件是 SSR 阶段在服务端发请求渲染的。服务端进程跑在服务器上，代码里图省事把请求 baseURL 写死成 localhost:3000，服务端自己访问自己当然通，于是把结果连同这段地址一起渲染进 HTML 返回给浏览器。问题在于这段地址对浏览器完全不可用。服务端用的内部地址和浏览器该用的公网地址必须分开，写死一份必然有一边是错的。
代码里得按运行环境拆开：
const api = process.server
? createClient(process.env.INTERNAL_API_BASE) // 服务端直连本机，比如 127.0.0.1:3000
: createClient(process.env.PUBLIC_API_BASE) // 浏览器要用的公网入口
process.server 是 Nuxt 注入的编译期常量，打包时就把两段代码分别编进 server bundle 和 client bundle，比在运行时判断更干净。注意 service 端那个默认值也别写死，写死了换台机器就废。之前代码里那份写死的 localhost:3000 完整地址字符串，就是被当成字面量编进了模板，SSR 一渲染就原样吐给浏览器，属于最典型的翻车姿势。
但这样拆完又引出第二个坑：公网地址不能写死在仓库里，dev 和 prod 不一样。得用环境变量。Nuxt 里分 runtimeConfig.public 和 runtimeConfig，public 部分的变量会同时序列化到服务端和客户端，注意它的取值时机：
// nuxt.config.ts
runtimeConfig: {
public: { apiBase: process.env.NUXT_PUBLIC_API_BASE }
}
NUXT_PUBLIC_ 开头的变量会出现在两处：服务端进程启动时读一次，构建时还会内联进 client bundle 一份，页面 HTML 里能直接在序列化的配置数据里翻到。这里我吃过两次亏，一次是只改了 .env 然后重启 Node，没重新 build，浏览器端那份额外的旧代码一直没更新；另一次反过来只 build 没重启进程，服务端渲染用的还是老值。所以改了这类变量，重启进程和重新构建两个动作都要做，缺一个就有一半是旧的。
NUXT_PUBLIC_ 前缀的变量，构建时会内联进 client bundle，服务端进程是启动时读的。这两个时机不一样，是最容易串味的地方：改了 .env 只重启 Node 不重新 build，浏览器端的代码还是旧的；只 build 没重启进程，服务端渲染用的还是老值。我之前吃过这个亏，改完环境变量怎么重启都不生效，后来才意识到是没重新构建。
Next.js 那边同理，NEXT_PUBLIC_ 前缀的变量在 build 时打进 bundle，运行时改容器 env 不重新构建根本不生效，服务端读的 process.env 倒是每次启动取新值。所以"为什么我改了 .env 重启没用"这类问题，先分清你改的变量是 public 前缀还是服务端私有变量。
排查这类问题有个很直接的招：curl 抓渲染出的 HTML，搜绝对地址泄漏：
curl -s 127.0.0.1/some-page | grep -oE '[a-z]+://[^"'"'"' ]+' | sort -u
一眼看出有没有内网 IP、localhost、127.0.0.1 混在页面里。SSR 页面对外输出的每一处地址都必须是用户浏览器可达的公网地址，这是铁律。服务端内部请求可以用内网，但绝不能把内网地址渲染出去。
还有一个隐蔽场景：nginx 反代后面，如果服务端要用请求的 Host 拼绝对地址，记得确认反代把 Host 头传对了。之前配过一次漏了 proxy_set_header Host，服务端拿到的 Host 是反代目标的地址，拼出来的链接全是错的。nginx 默认反代时 Host 会变成 upstream 的地址，要显式传原始 Host。这块跟上面环境变量是两套问题，别混在一起查。先 curl HTML 看地址长什么样，再顺着地址是"写死的、env 注入的、还是 Host 拼的"去定位，比对着代码猜快。
页面本身走加密访问的话还有个连带坑：渲染出来的接口地址如果协议是明文那个，浏览器会当成混合内容直接整段拦掉，控制台报 blocked，地址即使是对的也连不上。这类不体现在后端日志里，因为请求根本没发出去，排查时容易在 Node 那边白找半天。我的经验是 SSR 地址问题统一从渲染结果入手：curl 拿 HTML，看里面对外地址的协议、域名、端口是不是用户浏览器能访问的那一套，不对就往上追它是从哪个配置项来的。把 PUBLIC 和 INTERNAL 两套地址用不同变量名分开管之后，这类问题基本绝迹，顶多发版时忘配新变量，报错也比以前直白。