OK，OK，大家好，欢迎大家来到大鹏 AI 教育，我是张大鹏。

今天我想复盘一个有点反常的决定。

我不是因为 Docker 做不出来而放弃它。恰恰相反，我已经为如意浏览器做出了多阶段镜像、Compose 开发环境、真实 Camoufox 容器测试和内部持续集成，然后又把这些东西从当前项目里移除了。

这篇文章只回答一个问题：一个技术方案已经能运行，为什么我仍然决定停止投入？

Docker 最初为什么很有吸引力

如意浏览器依赖的不只是 Node.js。

它还依赖 Camoufox、Playwright、字体、图形库和浏览器运行环境。只要开发机、测试机和最终运行环境不一样，就可能出现“我的电脑正常，换台机器就失败”。

Docker 对这种项目天然有吸引力：把系统依赖、Node 版本和浏览器环境一起固定下来，开发、测试和运行尽量使用同一套基础镜像。

从技术逻辑看，这个方向没有问题。所以我没有只写一份 Dockerfile 就停下，而是把镜像、Compose、真实浏览器测试和 CI 都走了一遍。

问题也正是在走完整条链路后才变得清楚。

我真正要优化的不是环境一致性

项目当时已经明确了三个事实：

1. 它首先是我和 AI 助手长期使用的本地浏览器。
2. 正式运行平台是 Windows。
3. 后续还要交给学习项目的学生使用。

在这个范围里，最重要的问题不是“如何让 Linux 容器更像生产环境”，而是：

• Windows 上能否双击启动；
• 浏览器窗口会不会自己消失；
• AI 能否操作人正在观察的同一个窗口；
• 学生遇到端口、Node 或安装问题时能否自己判断；
• ZIP、安装、回滚和卸载是否可靠。

Docker 解决的是一组真实问题，但不是当时最贵的那组问题。

技术上能做，不等于现在该做

工程里最容易掉进去的坑，是把“已经投入很多”当成“必须继续投入”的理由。

如果我继续沿 Docker-first 往下走，还要长期维护容器基础层、Compose、缓存、CI、Windows 与 Linux 浏览器行为差异，以及学生电脑上的 Docker Desktop 和 WSL 资源问题。

这些工作不是没有价值，而是会持续推迟更直接的目标。

所以我重新做了一次范围判断：

判断问题	当前答案
是否需要公共云部署	不需要
是否有多开发者统一 Linux 环境	暂时没有
是否以 Windows 可见浏览器为正式体验	是
是否需要学生快速安装和自检	是
是否需要保留未来跨平台可能性	是，但不提前实现

结论不是“Docker 不好”，而是“Docker-first 不适合当前阶段”。

我删掉了什么，又保留了什么

当前项目树移除了 Docker、Compose、Railway、Linux VNC、公共发布和外部崩溃中继等路径，并增加了范围检查，防止它们在同步上游代码时被悄悄带回来。

与此同时，我保留并继续加强了这些能力：

• Windows 浏览器 ZIP；
• 安装、校验、回滚和卸载；
• 开始菜单快捷方式和正确图标；
• AI 托管的可见浏览器；
• 学生自检、修复和脱敏支持包；
• Windows 真实浏览器 smoke、recovery 和 soak。

这不是从“工程化”退回“手工作坊”。工程化仍然存在，只是围绕真实用户重新排序。

这次路线反转给我的三个提醒

第一，基础设施必须服务当前产品边界。技术再标准，如果没有缩短用户完成任务的路径，就应该重新评估优先级。

第二，做完一次实验并不浪费。正因为镜像、Compose 和容器测试都真正跑过，我才能基于证据停止，而不是凭感觉否定。

第三，删除也是交付。删掉不再需要的维护面，意味着以后同步上游、排查问题和给学生讲解时都少一层复杂度。

哪些事情还不能下结论

这次决策只适用于当前的如意浏览器：私有、个人使用、Windows-first，并服务一部分学生。

如果以后出现 Linux 服务器部署、多开发者协同、公开 SaaS 或跨平台课程需求，我会重新立项评估容器，而不是把今天的选择当成永久禁令。

我也没有做 Docker 与 Windows 的统一性能基准，所以这篇文章不讨论谁更快。

我的结论

我最终让如意浏览器回到 Windows，不是因为 Docker 失败，而是因为我终于把问题问对了：

当前最值得节省的，是环境差异，还是开发者、AI 和学生的总工时？

对这个阶段的如意浏览器，答案是后者。

技术路线不是信仰。能根据真实目标及时停止，和把功能做出来一样重要。