笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
docker compose 里 ${VAR} 到底读的哪个环境：.env、shell、env_file 优先级备忘
用 docker compose 最烦的就是环境变量来路太多，一个 ${VAR} 到底从哪取值经常搞晕。这次是 CI 里跑 docker compose up，镜像 tag 一直不对，查了半天才理清楚 compose 的环境变量其实分两层：一层是 compose 文件本身做变量替换（插值），另一层是容器启动后进程能看到的实际环境变量，两层的取值来路和优先级不一样，混在一起就出事。
先记变量替换这层。compose 文件里写 image: 内部仓库/app:${TAG}，这个 ${TAG} 会被 compose 在解析文件时替换掉，取值优先级从高到低是：shell 里已经 export 的环境变量 > 项目目录下的 .env 文件 > 默认值。也就是说，如果你在终端里 export TAG=v1.2，就算 .env 里写了 TAG=v1.0，最终用的也是 shell 那个 v1.2。反过来终端没设，才轮到 .env。这个顺序坑过我一次：本地 .env 里明明写了 TAG=v1.0，shell 里残留着一个老环境的 TAG=v0.9，compose 一声不吭用了 0.9，镜像 tag 自然是错的。排查这类问题最靠谱的是先看 compose 解析出来的实际配置：
docker compose config
它会把所有变量替换完的最终配置打出来，镜像名、端口、挂载全在这，一眼就能看出 ${TAG} 被替换成了什么。改 .env 之后也要注意：.env 是 compose 解析时读的，光改文件不会自动生效，得重新 docker compose up -d 让它重新解析。shell 里那个 export 优先级更高，改完 .env 发现没变，先怀疑是不是 shell 里还挂着同名变量。
再记容器实际环境变量这层。它和替换是两码事，取值来路有三个：image 里 Dockerfile 的 ENV、compose 的 environment、compose 的 env_file。生效优先级是 environment > env_file > Dockerfile ENV。容易被绕进去的是：.env 里的变量不会自动进容器，除非你在 environment 里显式引用，比如：
services:
app:
image: 内部仓库/app:${TAG:-latest}
env_file:
- ./app.env
environment:
- DEBUG=${DEBUG:-false}
这里 .env 只负责喂 compose 文件里的 ${TAG}、${DEBUG} 替换；容器里 DEBUG 这个变量之所以存在，是因为 environment 里写了它。env_file 那个文件里的变量才是原样进容器的。还有个细节：env_file 的文件内容不做变量替换，里面写了 PASSWORD=${SECRET} 就真的是字面量 ${SECRET}，不会去展开，想展开得放 environment 里。想传字面量的美元符号进容器，compose 里要写 $$，比如 command: sh -c "echo $$HOME"，否则 compose 会先把 $HOME 替换掉再传给容器，容器里拿到的就不是它自己那份 HOME 了。
报错形态也记一下：${TAG} 没设又没默认值，替换出来是空，镜像名变成 app: 这种，docker 会报 invalid reference format，看到这个错先查是不是哪个变量空着没给值。取值想要容错就用 ${VAR:-默认值}，想要强校验用 ${VAR:?必须设置}，后者变量缺失时直接报错退出，适合 CI 里防止静默用错配置。compose 变量名还有限制，带点号、横杠的 key 有些写法不认，全用大写字母加下划线最稳。还有一个经常被忽略的取值顺序问题：docker compose 默认读的项目目录下 .env，但如果你用 docker compose --env-file 别的路径 up 指定了别的文件，那优先级里 .env 就被你指定的文件替代了，shell 环境变量仍然排最前。CI 里常见做法是准备几个 env 文件（dev.env、prod.env），跑的时候 --env-file 指过去，这样同一份 compose 文件在不同环境能解析出不同 tag、不同端口，不用维护多份 compose。docker compose --env-file prod.env config 可以先验证解析结果再真跑。
容器里要拿宿主机（或者 .env 里）的变量还有个简写：environment 底下只写变量名不写值，compose 会从 shell 环境或 .env 里把这个变量的值带进容器：
services:
app:
image: 内部镜像
environment:
- NODE_ENV
- API_BASE
这比 environment 里写死值灵活，适合那些值本身会变、又不想写进镜像的配置。不过这个简写只在变量真的存在时有意义，变量没设的话容器里这个变量就是空的，服务跑起来读不到配置直接报错，所以用简写最好配合 ${VAR:?err} 这种强校验在 compose 解析阶段就拦住。我一般给关键配置加 :? 校验，漏配的时候 docker compose up 直接红字报哪个变量没给，不用等容器起来再对着空配置猜。
再讲一个我踩得最狠的坑：.env 文件里写了带 # 的值，比如密码里有 # 注释符，compose 解析 .env 时把 # 后面全当注释吃了，密码变成半截，服务起来连不上数据库，报错却指向数据库地址，害我查了半天网络。.env 的语法很朴素，值里带空格、#、$ 这些特殊字符最好用引号包起来或者干脆别放 .env，挪到 env_file 里反而没这些解析问题。环境变量这种事，出问题时的表象往往和根因隔着十万八千里，能 docker compose config 先看解析结果，就别急着改业务代码。
绕了这么一圈，我现在的习惯是：镜像 tag 这类构建参数全走环境变量带默认值，容器运行配置全走 env_file，两边分开，别混在一个 .env 里。