XDA Developers 撰稿人 Yash Patel 在自己的服务器上跑了 File Browser 好几年，一直没有换掉的理由。得知归档消息后，他没等真出问题才动手，而是提前挑替代品，最后选定了 Filestash。他给出的评价是：日常够用，速度比原来还快。

一、Filestash 适合什么样的需求

1. 它是网页版文件管理器，用浏览器就能管理服务器上的文件
2. 能对接多种存储，按官方说明包括 FTP、SFTP、WebDAV、S3、Git 以及各类云盘，不局限于服务器本地目录
3. 它不是网盘全家桶，没有日历、联系人、在线文档协作那一整套
4. 如果诉求只是「打开浏览器找文件、上传、下载、挪动位置」，这类精简工具反而更省心

二、按官方步骤用 Docker 部署

1. 准备一台 Linux 服务器，装好 docker、docker-compose 和 curl。官方给的硬件门槛很低：只要不做密集视频转码、不同时服务上千用户，128MB 内存加 1 核就够
2. 新建目录并拉取官方编排文件：先执行 mkdir filestash && cd filestash，再执行 curl -O https://downloads.filestash.app/latest/docker-compose.yml
3. 启动服务：docker-compose up -d
4. 浏览器访问 http://服务器地址:8334，首次进入的第一件事是设置管理员密码
5. 进管理后台勾选需要的存储后端，例如只保留 FTP 和 S3，保存后即可开始使用

部署过程中不需要搬动原有文件，把 Filestash 指向已有目录即可。该撰稿人也是这么做的：存储位置一动没动，接上要访问的文件夹就用起来了。

三、日常真正用得上的几处

1. 界面清爽不拥挤，文件操作按钮都在预期的位置，文件夹层级容易跟
2. 支持文件预览，图片等受支持的格式可以直接看，不必先下载一遍再确认是不是要找的那个
3. 附带文件分享、搜索、书签、用户账号和访问控制
4. 内置工作流自动化引擎，可以给文件相关任务配简单流程，比如批量移动、处理，或在某个事件发生时触发动作
5. 支持插件机制，缺什么功能装插件补，不用把整套配置改复杂

注意事项

Filestash 的实际速度取决于它连接的存储，底层服务器或链路本身慢、不稳定，它救不回来。该撰稿人还遇到过缩略图突然不显示的情况，原因没查清，服务器重启几次后自行恢复了。想加在线文档编辑之类的进阶能力，需要额外配置。

如果要放到公网使用，官方建议前面加一层反向代理负责 SSL 终止。后续升级也很简单：重新拉一次 docker-compose.yml，再依次执行 docker-compose pull 和 docker-compose up -d。

来源：XDA Developers

差异出在架构：Docker Desktop 的引擎跑在 WSL 共享虚拟机里，wslc 则每启一个容器就单独建一台私有虚拟机。好处是每次启动环境完全一致，坏处是内存和管理方式都得重新适应。

一、开启只要一条命令

1. 执行 wsl --update --pre-release 升级到预览版，wslc 命令随之可用。
2. 先记住收尾命令 wslc system session terminate，原因见下一节。

二、先学会清残留虚拟机

1. Docker Desktop 空载时含特权 Windows 服务一起算，占用不到 200 MB 内存；而跑一个 wslc 容器会新建一台以用户名命名的虚拟机，吃掉约 1.5 GB。
2. 微软称容器用完即消失——容器确实消失了，但托着内存的虚拟机不会，手动执行 WSL 关机也杀不掉。唯一解法是 wslc system session terminate，这条命令藏在三层子命令之下，wslc 自己也不会提示。
3. 更费内存的是连带效应：启动一个 wslc 容器会同时唤起一份全新的 WSL 共享虚拟机，并把已装的 Ubuntu 重新标记为运行中，一个空闲的命令行提示符合计吃掉 3.4 GB 内存。

三、速度实测：差距小到感觉不到

1. 早期报道称 wslc 启动容器不到一秒，Docker Desktop 要三到八秒。用 alpine 镜像配合计时脚本冷热各跑一轮，结果是热启动 wslc 357 至 384 毫秒、Docker Desktop 426 至 463 毫秒；冷启动（会话已终止或应用已退出）wslc 2387 至 2611 毫秒、Docker Desktop 2629 至 2973 毫秒。
2. 只有 Docker 非正常退出才拉开差距：强制结束进程后冷启动要 6667 毫秒，连辅助进程一起杀掉则是 9108 毫秒，其中包含一次权限确认弹窗。
3. 真正的优势是稳定：六次 wslc 启动全部落在 224 毫秒区间内，因为私有虚拟机不继承任何状态，无论怎么被强行拆掉都没有残留需要修复。

四、显卡能用，端口有坑

1. GPU 加速开箱可用：一个标准的 CUDA 12.4 镜像立刻认出 RTX 5090，只需加 --gpus-all 参数，不必在容器里折腾驱动，宿主机装 CUDA 13.3 驱动同样正常。注意这是显卡半虚拟化而非独占直通，显存和 Windows 桌面共用，规划时要留余量。
2. 网络默认绑定 127.0.0.1，而不是 Docker 习惯的 0.0.0.0。测试 nginx 时必须显式发布到 0.0.0.0 才通，且会弹出一条归属于 COM Surrogate 的防火墙提示——正是很多人误当成病毒的那种弹窗。

五、Compose 目前靠社区补丁

1. 截至 2.9.3 版本，wslc compose 仍然不可用。社区项目 wslc-compose 用一层轻量 Python 转译补上了这个缺口，通过 pipx（Python 命令行工具的隔离安装器）装好即可。
2. 实测拿 nginx 加 Postgres 两个服务、配置里写上依赖顺序，结果正常跑通：生成项目独立网络、数据库先于 Web 容器启动、两容器共用去重后的 Alpine 基础层，down -v 也能连网络一起清干净。

注意事项

1. 参数还不全：没有特权模式、设备直通和重启策略，会话一断里面的东西全没，常驻服务不适合搬过来。
2. 可见性是短板：Docker 的容器摆在图形界面里，wslc 得靠命令行才能看清有什么在跑，目前还没有对应的管理界面。

来源：XDA Developers

一、HomeBox：给家里建一份资产清单

解决：搬家翻箱倒柜、想不起备用 HDMI 线放哪。

用法：用 Docker 一条命令拉起；按房间、货架建位置，录入物品时加上照片、购买日期和序列号，还能生成二维码方便检索。作者实测空闲内存占用不到 50MB，跑在旧电脑或 NAS 上毫无压力；数据少先用 SQLite，以后量大可换 Postgres。

二、KitchenOwl：一家人共享购物清单

解决：你买的，家里人又买一遍。

用法：建一个家庭共享清单，成员手机实时同步；添加物品会自动归类。它还能管食谱——粘贴支持的食谱链接，自动把食材拉进清单；另有饮食计划和简单记账。

三、ntfy：让任意脚本给你发通知

解决：备份跑完、硬盘快满、门铃触发，你却后知后觉。

用法：自托管 ntfy 后，任意脚本用一条 HTTP POST 就能往你手机推消息；一个主题（topic）被订阅，相关设备全收到，能替掉 Discord 通知。

四、Espanso：把常用短语一键展开

解决：收货地址、邮件模板、常用代码，天天复制粘贴。

用法：设个短触发词，比如输入 :addr 就展开成完整收货地址；桌面端装好 Espanso，手机上也能用类似文本快捷键，重复输入从此交给工具。

注意：这几款大多需要自托管（HomeBox、ntfy 用 Docker，KitchenOwl、Espanso 有客户端或服务端），动手前先补一点 Docker 基础更顺手。它们轻量、可私有部署，正适合想逐步离开大厂生态的人。

来源：How-To Geek

第一次接触 Docker 的人，往往被镜像、容器、卷、端口、Compose 文件和满屏命令劝退，以为必须懂开发才能上手。镜像（image）可以理解成打包好的应用「蓝图」，容器（container）则是照蓝图跑起来的运行实例，二者并不相同。MakeUseOf 一位撰稿人分享，他真正跑起几个自托管应用后才发现，日常反复用的其实就是那么七八条命令。先把这七条记熟，Docker 就不再难懂。

二、七条核心命令

1. docker pull nginx：从镜像仓库下载名为 nginx 的镜像，相当于把「原材料」备好；
2. docker run -d –name myserver -p 8080:80 nginx：把镜像变成运行中的容器；-d 后台运行，–name 起名，-p 把本机 8080 端口映射到容器内 80 端口；
3. docker ps：查看正在运行的容器名称、状态、镜像与端口；加 -a（docker ps -a）可看已停止的；
4. docker logs myserver：查看容器输出日志，定位启动报错、配置或连接问题；加 -f 实时跟踪；
5. docker exec -it myserver sh：进入容器内部开一个交互终端，像在本机一样查文件、跑命令；
6. docker stop myserver：用完先停而非删，容器保留在系统里，下次一条命令就能再起；
7. docker rm myserver：确定不再需要时彻底删除容器（镜像仍在）。

一个最小流程就是：pull 拉镜像、run 起容器、ps 确认在跑、logs 排错、stop 收工。

三、理解工作流就不慌

镜像像图纸，容器是照图纸跑起来的实体。端口映射（-p 8080:80）的意思是：在浏览器访问本机 8080，流量会被转进容器里的 80 端口，这样外面的电脑才能打开容器里的服务。七条命令足以起步，其余等踩坑时现学现用。

注意事项

docker pull 并非每次必用，Docker 在 run 时缺镜像会自动补拉，但理解「镜像与容器」的关系能少走很多弯路。myserver 只是容器名占位符，换成自己实际名字即可；忘了名字就 docker ps 看 NAMES 列。删除容器前若仍在运行，要先 docker stop 再 docker rm，否则会报错。

来源：MakeUseOf

一台没人要的 2021 款 Fire 平板，被一位作者刷上 Linux、接上 Docker 和开源菜谱库，变成了厨房里专属的「菜谱终端」。这个项目不需要把找菜谱的事外包给大模型，也不用在长文里翻找做法，是旧设备再利用和家庭实验室入门的好例子。

动机：给爱做饭的人一个干净界面

作者戴维·巴克（David J. Buck）的妻子很会做饭，但找菜谱一直麻烦。她手头有一台不再使用的平板，市面上有不少在线菜谱，也攒了几本纸质菜谱，但都谈不上「顺手」。巴克不想把找菜谱这事儿交给聊天机器人，更不想打开一个菜谱前先读完博主的人生故事，于是想做一台联网的专属菜谱终端当礼物。

他最初的计划是用一台 Kindle Fire HD7，连 Fastboot 线都试了，设备始终不配合，只好放弃。备用方案是一台 2021 款的 Fire Tablet——这台机器刷 Linux 顺利得多（刷机细节他留到后续文章细说）。

三件套：Docker、Python 与 Mealie

整套方案跑在一台常开的 Windows 电脑上：装好 Docker Desktop，再用 Python 的 Textual 框架做界面。平板上运行 Linux，后端则由 Docker、在线资源和 Python 共同组成。

核心是一个叫 Mealie 的开源菜谱管理工具（项目托管在 GitHub 的 mealie-recipes/mealie）。它既能从网址一键导入菜谱，也能手动录入。巴克把妻子常做的几道菜加进去，又从开源菜谱库 Open Stove 抓了一些自己喜欢的方子。接着他在 Mealie 里生成一组 API 令牌，接进终端脚本。

脚本本身用 Python 的 Requests 库发请求、用 Textual 搭界面，取名 STEVE——取自妻子的一位旧上司，也是帮巴克解答 Python 问题的朋友。

跑起来：左选右看，三小时搞定

在平板的 Linux 环境里建好虚拟环境（venv）后，用 ./.venv/bin/python steve.py 启动即可；连接其他设备时，他把 Wi-Fi 设为「专用」（Private）以防被随意访问。

界面很简单：左边栏选菜谱，右边栏显示内容。每次往 Mealie 里新增菜谱（常常一次加好几道），重开 STEVE 就会同步更新。巴克说，除去折腾 Textual 界面和往 Mealie 里录菜谱的时间，真正搭起来也就三小时左右。

旧物复活的意义

这台原本打算回收的平板，最终成了妻子在厨房随手查方的专用终端；巴克自己也借着项目多写了 Python、用熟了 Textual。他认为这是家庭实验室「一举两得」的典型：设备不浪费，家人得便利。

想照做的读者要注意，Fire Tablet 需要先「改装」（解锁引导加载并刷机）才能装 Linux；Kindle HD7 在本例里难以搞定，2021 款 Fire Tablet 则顺利得多。刷机有变砖风险，动手前务必确认机型与教程对应。

来源：How-To Geek（作者 David J. Buck）

XDA 撰稿人分享了自己的替换过程：过去一直靠 TeamViewer 管理迷你主机，稳定好用，但随着家里自建服务越来越多，付费方案里那些面向企业运维的高级功能几乎用不上——需求无非是连上自己的几台设备而已。最终换成了开源的 RustDesk，并把中转服务器也搬到了自己的机器上。

RustDesk 是一款免费开源的远程桌面工具，支持无人值守连接、文件传输、剪贴板共享和多显示器，客户端覆盖 Windows、Linux、macOS、Android 和 iPhone。它最大的区别在于：既可以用官方公共服务器，也能自己搭一套中转服务，让连接不经过别人的服务器。

一、先跑起来：Docker 部署服务端

服务端由两个组件构成，hbbs 负责 ID 注册与打洞，hbbr 负责中继转发，两个都要跑。在装好 Docker 的 Linux 机器上执行三条命令：

sudo docker image pull rustdesk/rustdesk-server
sudo docker run --name hbbs -v ./data:/root -td --net=host --restart unless-stopped rustdesk/rustdesk-server hbbs
sudo docker run --name hbbr -v ./data:/root -td --net=host --restart unless-stopped rustdesk/rustdesk-server hbbr

几点要留意：--net=host 只在 Linux 上有效，作用是让服务看到真实来访 IP 而不是容器内网地址；Windows 上要去掉 sudo 和 --net=host。如果连接有问题，先把 --net=host 去掉试试。-v ./data:/root 一定要挂上，升级或重建容器时数据才不会丢。看不到日志可以用 docker logs hbbs 查看。

二、放行端口

在防火墙和路由器上开放这几个端口，缺一个都可能连不上：

1. 21115（TCP）：NAT 类型检测。
2. 21116（TCP 和 UDP 都要开）：UDP 用于 ID 注册和心跳，TCP 用于打洞与连接。
3. 21117（TCP）：中继服务。
4. 21114（TCP）：网页控制台，仅专业版可用，开源版不需要。
5. 21118、21119（TCP）：网页客户端专用。不用网页端就保持关闭——官方明确提示，直接暴露这两个端口存在伪造来访 IP 的风险。

三、取出公钥

首次运行 hbbs 时会自动生成一对密钥。到挂载出来的 data 目录里找到 id_ed25519.pub 文件，把里面的字符串复制出来备用。这是用于加密连接的公钥，和商业版的许可证密钥是两回事。

四、客户端指向自己的服务器

被控端和主控端都要设置一遍：

1. 打开 RustDesk 客户端，点 ID 旁边的三点菜单 [ ⋮ ]，选择”网络”。
2. 点解锁按钮，按提示提升权限。
3. 在”ID 服务器”填服务器地址，例如 hbbs.example.com 或 hbbs.example.com:21116。
4. 在”密钥”栏粘贴上一步取到的公钥内容。
5. 中继服务器和 API 服务器留空即可，RustDesk 会自动推导，中继默认指向 21117 端口。

设备多的时候不必逐台手填：在配好的那台机器上进”设置 → 网络”，解锁后点”导出服务器配置”，复制得到的字符串；换到新设备同样进”设置 → 网络”，解锁后点”导入服务器配置”，设置会自动填好，最后点”应用”。

注意事项

如果所在网络打洞成功率低，可以在 docker-compose 的 hbbs 环境变量里加上 ALWAYS_USE_RELAY=Y，强制走中继，稳定性换带宽。服务器建议放在有公网 IP 的机器上，否则外网设备找不到它。

来源：XDA Developers

这位作者的家庭服务器最早围绕一台联想 RD440 机架式服务器搭建，Unraid 一肩挑起存储、虚拟机与 Docker 三件事。在 2021 年那个时间点，TrueNAS 的稳定版还没有今天这样完善的 Docker 支持，原有的 jail 机制也远不如 Unraid 上的 Docker 好用，于是 Unraid 成了「什么都让一套系统搞定」的自然选择。

Unraid 曾是全能选手

客观地说，Unraid 作为存储平台表现相当出色，把存储、Docker 和虚拟机整合在一起，对刚接触容器的新手也很友好。作者坦言，正是在 Unraid 的图形界面里第一次用上了 Docker，比直接扑进 Docker Compose 或命令行要平缓得多。

但「能做某事」不代表「适合做每件事」。随着使用深入，作者想要的容器功能越来越多，Unraid 在不少地方把简单任务变得不必要地麻烦，尤其是当需求超出它预设的模板时。

卡在「应用模板」上

Unraid 的「应用模板」需要由社区或容器维护者手动提交，并非自动生成。作者开始遇到想用的容器却没有对应模板，只能手工凑配置，过程相当痛苦。模板本身虽好用，但修改起来往往比帮忙更添堵。

更烦人的是查找成本：在社区仓库里搜一个容器，可能冒出十几个看似相同的模板，有时标「官方」有时又不标，挑出最合适的一个成了日常消耗。相比之下，直接从维护者的 GitHub 仓库拿官方的 Compose 文件或镜像，定位反而清晰得多。

换回 Ubuntu 后打开了门

作者使用 Ubuntu Server 已超过十五年，命令行环境最为熟悉，迁移到 Ubuntu 跑 Docker 是顺理成章的决定。Ubuntu 原生支持 Docker，几乎每个主流容器都自带 Compose 文件，没有就用手写或 Portainer 补全，不必再受模板有无的制约。

迁移带来的直接好处是「几乎任何容器都能跑」，而且运行更稳定。对需要精细控制网络、存储卷和依赖关系的服务来说，直接用维护者提供的清单部署，比在模板系统里反复试错省心得多。

把家庭服务器拆开管

这篇文章给出的核心经验，是把家庭服务器按职责拆开：存储这件 Unraid 擅长的事继续交给它，Docker 编排这件 Ubuntu 擅长的事交给 Ubuntu。作者表示，正是因为 2025 年初把 Docker 从 Unraid 迁到 Ubuntu Server，家庭服务器才真正「起飞」，这是他为整套系统做过最对的一个决定。

对正在权衡家庭服务器架构的玩家，这未必是「Unraid 不如 Ubuntu」的结论，而是一次关于职责分离的提醒：当一套全能系统开始拖慢特定需求时，把最吃力的那块拆出去，往往比硬扛更划算。

来源：How-To Geek，作者 Patrick Campanale

编程智能体一旦放手，效率确实高；可真放手，又担心它顺手改错配置、误删文件，甚至把 .ssh 里的密钥亮出来。Docker 最近把 Sandboxes 推到了可用版本，核心思路是给 Claude Code、Codex、Kiro 这些智能体一人一个轻量级 microVM，让它们在该改的目录里使劲折腾，宿主机和敏感文件一概碰不到。

为什么容器还不够

用普通容器隔离智能体看起来省事，但很快会遇到三个坎。第一，OS 自带的沙箱机制在不同系统上行为不一致，写好的脚本换个平台就失灵。第二，智能体经常要跑 docker build 或 docker compose up，把 Docker socket 挂进容器等于把宿主机的 Docker 守护进程暴露给它。第三，传统虚拟机隔离强，但启动慢、配置重，换个项目就得重新搭。

Docker Sandboxes 想走的是第四条路：比容器硬、比虚拟机快，还允许「Docker 里跑 Docker」。

microVM 里关一只智能体

每个 Sandboxes 实例跑在一个独立 microVM 里，只把当前项目目录挂载进去。智能体可以安装系统包、改配置、删测试文件、甚至在里面再起容器，但宿主机的文件系统、网络栈、Docker daemon 都不在视野内。出了错也简单，一个命令删掉沙箱，重新起一个干净的即可。

它自带几层安全控制：

• 网络白名单/黑名单：可以只让智能体访问特定域名，默认 deny 状态下逐个放行。
• 文件系统最小挂载：只有项目工作区可见，家目录、系统配置、密钥目录默认隔离。
• 安全的 Docker 访问：智能体在沙箱内自建容器，不需要接触宿主 Docker daemon。

Docker 给出的安装方式也很轻：macOS 上 brew install docker/tap/sbx，Windows 上 winget install Docker.sbx。不需要先装 Docker Desktop。

哪些智能体能直接用

官方列出支持 Claude Code、Codex CLI、GitHub Copilot CLI、Gemini CLI、OpenCode、Kiro 以及 Docker Agent。另外像 NanoClaw、OpenClaw 这类新一代自主系统也能跑在里面，省下一台专门用来隔离的 Mac mini。

这些工具原本大多有个 --dangerously-skip-permissions 模式，开发者戏称为「YOLO 模式」——不弹窗、直接执行，效率最高也最危险。Docker 把它变成了默认：沙箱先替你画好边界，里面随它怎么 YOLO。

这还不是终点

Docker 在产品页和博客里列出的下一步包括 Linux 支持、MCP Gateway 支持、向宿主机暴露端口，以及接入更多智能体。目前 Sandboxes 可在 macOS 和 Windows 上直接下载使用。

对普通开发者来说，这意味着一个之前很纠结的选择题被改了题面：要么每步都点确认当「人形剪贴板」，要么冒着把环境搞坏的风险让智能体狂奔。现在可以先画好一个硬边界，再把钥匙交给它。

来源：Docker 官方博客

MakeUseOf 撰稿人分享了一套自建方案：用开源工具 ArchiveBox 把整页内容留在自己的硬盘上，并做了一次严格验证——先存档，再把原页面彻底下线，看还能不能还原。

一、部署

1. 准备一台 Ubuntu 26.04 虚拟机，4GB 内存，通过 Docker 安装 ArchiveBox。
2. 版本选稳定的 0.7.4，而不是仍在改版中的 0.9 开发分支，可以少踩不少坑。
3. 官方 Compose 文件有 278 行，捆了搜索、计划任务、Nginx 等一堆用不上的组件。实际只需要一个服务：镜像 archivebox/archivebox:0.7.4，启动命令 server --quick-init 0.0.0.0:8000，映射 8000 端口，把 ./data 挂载到容器内 /data，环境变量把 ALLOWED_HOSTS 设为 *、PUBLIC_INDEX 和 PUBLIC_SNAPSHOTS 都设为 False。
4. 依次执行三条命令完成初始化、创建管理员并启动面板：

docker compose run --rm archivebox init
   docker compose run --rm archivebox manage createsuperuser
   docker compose up -d

1. 关掉向 Archive.org 回传的开关，保证一切留在本地：docker compose run --rm archivebox config --set SAVE_ARCHIVE_DOT_ORG=False。

二、一次快照留下七份副本

抓取完成后，ArchiveBox 保留原地址，同时生成带时间戳的快照，里面包含 Wget 抓下的 HTML 副本、SingleFile 单文件页面、PDF、截图、渲染后的 DOM、正文提取版和 WARC 文件。SingleFile 最接近原貌且可正常浏览，正文提取版只留文字，PDF 和截图作为兜底——结果页看起来更像一份恢复菜单，而不是书签列表。

三、把原页面关掉之后

该撰稿人自建了一个含图片、说明文字和一个可下载配置文件的小页面，跑在同一台服务器的 8081 端口，页面里硬编码了标记 COPPER-FINCH-8247 便于核对。以深度 1 抓取快照后，他停掉服务并把源目录整个移走。

刷新浏览器，原地址报连接错误，而 8000 端口的存档照常打开：SingleFile 和 Wget 版本保留了排版与图片，PDF、截图、DOM、正文提取里都能搜到那个标记。存档前后用 sha256sum 对那个配置文件做校验，哈希值完全一致。

四、配上浏览器扩展才真正好用

1. 安装 ArchiveBox 官方的 Firefox 扩展。
2. 在扩展设置里填写本地实例地址，例如 http://192.168.91.136:8000。
3. 浏览器里若已登录 ArchiveBox，扩展会直接复用该会话，此后一键就能存下当前页面。

实测存一篇带多张图片、脚本和广告的长文章，SingleFile、Wget、PDF、截图、DOM 和正文提取全部成功，只有 Original 格式因为目标站不允许被嵌入而报了警告。

注意事项

存档掌握在自己手里，责任也一样。虚拟机一旦损坏，没备份 data 目录就前功尽弃。ArchiveBox 也无法保证完美复现需要登录的页面、视频播放器和重度 JavaScript 界面。空间方面：example.com 只占 384KB、17 个文件，加上那个自建测试页涨到 1.5MB、52 个文件，再加一篇长文章就到了 34MB、158 个文件。书签只存网址，存档要存 HTML、图片、PDF、截图、WARC 和元数据，量一大就会明显吃盘，因此值得只留文档、研究资料这类真正需要引用的内容。

来源：MakeUseOf

这不是错觉。Notion 官方帮助中心自己承认，数据库会随着页面、属性和复杂排序筛选的增加而变慢，单个数据库到 25 万行就彻底写不进去了。官方给的建议是拆分大页面、隐藏属性、压平嵌套——说白了，就是少用点你正在付费的东西。

离线也没好到哪去。Notion 2025 年才补上离线模式，还得按页面一个个手动开启；标了离线的页面，它的子页面不会跟着下载，嵌入内容、按钮和 AI 功能离线全部失效，数据库只能看 50 行。

XDA 撰稿人的解法是换成 AppFlowy——一个开源的块编辑器（内容以「块」为单位拼装的笔记工具），斜杠命令、块类型、拖拽手感几乎照搬 Notion，关键是能自己搭在电脑上。

搭起来只有四步

1. 装好 Docker Desktop（容器运行环境，装完不用管）；
2. 用一条 git 命令把 AppFlowy Cloud 仓库拉到本地；
3. 把 deploy.env 模板复制成 .env；
4. 运行 docker compose up -d，它会拉下约十个容器，几分钟跑完。

之后打开 localhost/console 创建账号，桌面端或网页端把服务器地址填成 localhost 即可登录。SMTP、第三方登录、证书这些只在团队协作或对外开放时才需要配。

我的判断是，这套方案最值钱的不是省钱，而是数据和编辑器跑在同一台机器上——页面秒开，拔了网线照样能写。代价也很明确：数据库功能没 Notion 那么密集，表格、看板、日历、筛选排序这些基础项齐了，复杂玩法就别指望。

要是你的 Notion 也开始卡了，先别急着清页面，试试把它搬回自己电脑。

来源：XDA Developers