笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
容器里是普通用户，往 -v 挂的目录写文件老报 Permission denied
容器里跑的应用我早就改成非 root 了（Dockerfile 里 USER 指令，安全习惯），一直没事。直到有次把宿主机一个目录 -v /srv/app-data:/data 挂进容器，应用起来就开始报 EACCES: permission denied, open '/data/xxx.log'，怎么都想不通：宿主机上那个目录明明当前用户能写，容器里也是同一个用户在跑，怎么就不行。后来才彻底想明白一个事：容器根本不认识宿主机上的"用户名"，它只认数字 uid，两个环境各自维护自己的 /etc/passwd，同名用户背后的 uid 可能完全不一样。
具体到那次：宿主机上 /srv/app-data 的属主是 uid 1000 的账号，容器里 USER 指定的那个用户实际 uid 是 999（官方镜像里常见，比如 node 用户是 1000，但很多别的基础镜像普通用户是 999 或 101），两边名字可能都叫 app，但 uid 对不上。进程在容器里以 uid 999 跑，写宿主机文件系统时内核直接拿 999 去比文件属主 1000，不匹配又没有组权限，就 EACCES。名字一样没用，内核只看数字。所以排查这种事第一反应是看两边 uid：
id -u # 宿主机当前用户
docker run --rm -v /srv/app-data:/data 镜像 id -u # 容器里实际用户
容器里应用是以什么 uid 跑的，最直接是 docker exec 容器 id，看输出的 uid 是多少，然后去宿主机 ls -ln /srv/app-data 看目录属主数字。对上思路就清楚了，修法挑一个：把宿主机目录 chown 成容器那个 uid，chown -R 999:999 /srv/app-data；或者在 compose 里把容器用户指成宿主机用户的 uid：
services:
app:
image: 内部镜像
user: "1000:1000"
volumes:
- /srv/app-data:/data
compose 的 user 支持 ${UID}:${GID} 这种变量，Linux 上 shell 会带 UID 环境变量，能自动匹配当前用户。macOS 上 UID 变量经常没有，得写死。还有一种更隐蔽的坑在命名卷上：一个全新的命名卷第一次挂到容器某路径时，Docker 会把镜像里这个路径的内容连同属主一起拷进卷里。也就是说镜像里 /data 属主是 999，新卷里 /data 也会是 999，如果容器以 root 跑就没事，以 999 跑也刚好能写，但要是两个容器共享一个卷、一个以 root 跑一个以 999 跑，root 写进去的文件属主是 0，999 那个再写就报错了。这种共享卷的权限冲突，比单容器难查多了，我后来一律规定共享卷里的文件目录属主统一成一个 uid，谁都不许用 root 往里面写。
另外容器日志经常把这类权限错包装成别的样子：比如应用起不来只说 listen EADDRINUSE 或者干脆静默崩溃，实际前一步是写 socket 文件、写 pid 文件没权限。看到应用能读不能写、或者某些文件能写某些不能写，先怀疑 uid 映射，别一上来就 chmod 777——777 一时爽，内网机器上无所谓，稍微正经点的环境早晚被安全审查揪出来。如果容器里不止一个用户要写同一个卷，或者要访问宿主机上多个不同属主的目录，靠单个 user 指不过来，可以在 compose 里给容器补附加组：
services:
app:
image: 内部镜像
user: "1000:1000"
group_add:
- "1001"
group_add 能把宿主机侧的附加组 gid 加进容器进程的组列表，配合宿主机目录设成 2775 属组可写，就能让一个容器同时写多个不同组共享的目录，不用反复 chown。这套在做 CI runner 挂载缓存目录、IDE 远程容器挂项目目录时特别有用，属于比 chown -R 更精细一点的解法。
还有一条我后来才注意到的：容器镜像如果是以 root 启动、运行中途自己 setuid 降权的（有些官方镜像入口脚本这么干），那卷的属主要对齐它降权后的 uid，而不是 root。判断进程最终以什么 uid 跑，别只看 Dockerfile 的 USER，要 docker exec 进去 ps -o user,pid,cmd 实际看一眼，或者看进程的 /proc/pid/status 里 Uid 那行。我遇到过 Dockerfile 里写 USER node 以为很安全，结果入口脚本里又有一段要以 root 跑、跑完没降回来，整个进程一直是 root，卷权限看着对其实全乱套。容器里 root 写的文件属主是 0，回到宿主机用普通账号删都删不动，只能 sudo，很被动。
从根上还有一招用户命名空间重映射（userns-remap），把容器里的 root 映射成宿主机上一个普通 uid，容器里再闹腾也出不了那个 uid 的圈。但这玩意开了之后卷的属主映射会变复杂，镜像里 chown 的路径、命名卷初始拷贝的属主全要重新对一遍，和现有镜像的兼容性也一般，我在正式环境试过一次，问题比收益多，又关回去了。普通场景还是把宿主目录 chown 到容器运行 uid 最直接。判断方向就一句：权限报错先看 uid 数字对不对，别盯着用户名猜。
正确姿势永远是"目录属主对齐容器运行 uid"，要么 chown 宿主目录，要么 user 指过去。