我先把 FreshRSS 用 Docker Compose 跑起来。确认服务起来后，我在浏览器打开 127.0.0.1:8080，完成初始化、建分类并导入订阅。到这一步，基础 RSS 阅读没有问题。它已经能满足我最常用的流程，所以后面的扩展只是试验，不该反过来影响这个可用状态。

这次我想试三个扩展：Readable、freshrss-translate-summary 和 Three Pane Reader。我没有直接拿最新代码，而是下载各自固定提交的源码，免得上游更新后连排查对象都变了。随后我进入 FreshRSS 容器，确认容器名称和扩展卷里的扩展目录。复制时我一次只放一个目录进去，立刻回到 FreshRSS 的扩展页面刷新，确认页面真的识别到了它，再继续下一个。

启动服务时用的是这一条：

1
docker compose up -d

逐个复制的形式也很简单，关键是不要一次塞进一批：

1
docker cp <extension-directory> <freshrss-container>:<extensions-directory>/

每次复制后，我会在容器里列一下扩展目录，再刷新 Web 页面核对。文件在卷里和管理页能看到，是两个都要过的检查：

1
docker exec <freshrss-container> ls <extensions-directory>

三个扩展都被识别后，问题才开始出现。freshrss-translate-summary 需要连接本地 Ollama。我先确认宿主机上的 Ollama 本身正常，直接访问没有问题；但扩展从容器发请求时，始终没有收到有效的 HTTP 响应。这里不能把“宿主机能用”当成“容器也能用”。容器里的本机不是宿主机，扩展没有拿到可用响应，就谈不上翻译或摘要。我没有把 AI 翻译和摘要写进日常流程，因为它们实际上没有跑通。

Readable 的情况更直接。它需要一个解析器端点来抓取全文，而我当时并没有部署这个端点。设置页能打开不等于具备解析能力，缺少后端服务，扩展无法把摘要页变成全文页。几篇文章的验证结果都一样，我没有得到一次可用的全文提取。

Three Pane Reader 更容易误判。它可以启用，界面也会出现相应选项；但我刷新页面后，启用状态又回来了。既然开关状态都不能稳定保留，我就没有继续假定三栏布局可用，更没有把它当成成功安装。整个试验过程里，我没有为了安装扩展重启容器，问题也不是靠重启解决的。

到这里我决定停下，不再把缺少依赖或状态异常的组合硬接下去。我先把扩展卷里的这三个扩展目录做归档，然后从扩展目录移除，刷新 FreshRSS 的界面确认它们不再出现。这样做保留了之后复查的材料，也让当前实例回到干净状态。

结果并不戏剧化：三项扩展都撤掉了，AI 翻译和摘要、全文提取、三栏阅读都没有上线；但 FreshRSS 本体仍是一个稳定的 Docker RSS 阅读器，订阅、分类和阅读照常工作。这次记录对我有用的地方，不是把未完成的集成包装成成果，而是明确了下次试扩展时要先检查什么：容器能否访问依赖服务，所需端点是否真的部署，启用状态刷新后是否仍在。验证不过，就回到稳定版本。