笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
容器里 /etc/resolv.conf 老被还原成 127.0.0.11：内网域名解析不过排查
有台 Docker 主机上跑着公司内部的几个服务，容器里要访问另一个内网域名 gitlab.corp.local（对应内网 DNS 10.32.0.2）。宿主机上 curl、dig 都好好的，可一进容器，应用日志就刷 getaddrinfo ENOTFOUND gitlab.corp.local，解析直接失败。进容器 cat /etc/resolv.conf 一看，里面写的 nameserver 是 127.0.0.11，options 里还带 ndots。我手动把它改成 10.32.0.2 之后容器里就通了，但只要容器一重启，文件又被还原成 127.0.0.11——因为 Docker 每次起容器都会自己生成这份 resolv.conf，手改没用。
127.0.0.11 是 Docker 内嵌的 DNS 服务，监听在容器自己的网络命名空间里。它起两个作用：同网络里容器互访按容器名解析，以及把不认识的外部域名转发给上游。关键在上游是谁——内嵌 DNS 转发用的上游，是 dockerd 启动那一刻从宿主机 /etc/resolv.conf 里读到的 DNS。我宿主机当时 resolv.conf 里只有 127.0.0.53 这个 systemd-resolved 的 stub，而 systemd-resolved 的上游又没配内网那台 10.32.0.2，于是内嵌 DNS 转发出去也问不到 corp.local 的权威记录，一路 NXDOMAIN 回来，应用就报 ENOTFOUND。宿主机自己能用是因为系统里其它工具走了别的解析路径，跟容器不是一回事。
排查可以这么一步步来。先对比两边的解析配置：
cat /etc/resolv.conf
docker exec 容器名 cat /etc/resolv.conf
docker exec 容器名 nslookup gitlab.corp.local
容器里多半没装 dnsutils，可以先 apt-get install -y dnsutils 或者用 getent hosts gitlab.corp.local 将就。如果确认是内嵌 DNS 转发链路的问题，修法不是去容器里改 resolv.conf，而是给容器显式指 DNS，docker run 加 --dns 10.32.0.2 --dns-search corp.local，compose 里对应：
services:
app:
image: 内部镜像
dns:
- 10.32.0.2
dns_search:
- corp.local
这样 Docker 生成 resolv.conf 时会把 nameserver 写成 10.32.0.2，重启也不丢。治本一点就把内网 DNS 加进宿主机 resolv.conf（或 systemd-resolved 的上游），这样 dockerd 启动时读到的上游就是对的，所有容器一起受益。第二个容易踩的是容器互访：默认 bridge 网络里两个容器靠名字解析是走不通的（老式 --link 是靠写 /etc/hosts 硬凑），只有把容器都挂到同一个自定义 bridge 网络里，内嵌 DNS 才会按容器名解析。我自己就吃过这个亏，web 容器里配的数据库地址写 db，怎么 ping 都 ping 不通，一查俩容器各自在 default bridge 上。建个自定义网络把两个容器都拉进去，docker exec web getent hosts db 立刻出 IP。再往里钻一层，127.0.0.11 对"短域名"的处理也有讲究。Docker 内嵌 DNS 对单标签名字（比如就叫 gitlab，不带点）优先当容器名去同网络的容器列表里找，找不到就可能直接 NXDOMAIN，不会拿 search 域去拼。所以容器里访问内网机器如果你写的是短名，解析不过很正常，要么写全 FQDN（gitlab.corp.local），要么给容器配 dns_search 让内嵌 DNS 知道该拿哪个域去补全。options 里那个 ndots 也会影响：ndots 默认是 1 时，名字里带点就先把整串当域名查，查不到再套 search 域；设成 0 则是先套 search。理解这个就能解释为什么宿主机上好的写法到容器里行为不一样，两边 ndots 和 search 域根本不同。
排查时如果手边没有现成的 nslookup，可以用宿主机的工具对照：宿主机 dig @10.32.0.2 gitlab.corp.local 能解析，容器里不行，基本就是容器到上游那条链路的问题；宿主机直接问内网 DNS 都问不到，那是内网 DNS 本身没这条记录，跟容器、跟 Docker 都没关系，别在容器上瞎使劲。还有种情况是容器里应用自己配了 DNS 库（Node 的 dns 模块默认读 /etc/resolv.conf，但有些 SDK 走 DoH 或者自己设了 nameserver），应用层的配置会盖掉系统 resolv.conf，这时候你改 Docker 的 dns 参数也白搭，得去应用配置里改。再有一种 daemon 全局改法：如果整台机器上绝大多数容器都要走内网 DNS，可以在 dockerd 启动参数里加 --dns 10.32.0.2 --dns-search corp.local，写在 /etc/docker/daemon.json 的 dns 字段里，所有容器默认继承，个别要特殊的再用 docker run --dns 覆盖。我后来是这么干的，比每个 compose 都写一遍省事，也少踩因为漏写导致的解析坑。
所以容器里遇到域名解析诡异，先分清是"外部域名转发失败"还是"容器名互访不通"，前者查 --dns 和宿主机上游，后者查网络是不是自定义 bridge。