源于对消费级 NAS 产品（如极空间 zdocker）容器化实现的观察，与此前 RK3588/RK3562 嵌入式项目实践的交叉对比。
核心观点
嵌入式/边缘设备上的 Docker 化有两条根本不同的路径，不是"用不用 Docker"的问题，而是"Docker 在整个系统中扮演什么角色"的问题。
路径一：buildroot + Docker（全功能容器化）
特征
- 系统层极致精简（buildroot / 定制 Linux）
- 所有业务功能都跑在 Docker 容器里
- 硬件本身只保留最小系统（内核、网络、容器运行时）
优势
- 移植性极强：换硬件平台只需移植容器运行时，业务容器直接复用
- 环境一致性：开发、测试、生产环境完全一致
- 依赖管理简单：容器镜像自带依赖，不需要在目标系统上 apt/yum 装东西
- 快速回滚：容器快照、版本化，搞坏了直接还原
实践参考
- 一个 RK3588 项目：设计了一套完全兼容 ROS Noetic 的 buildroot + docker 部署方案
- 一个 RK3562 航测项目：纯构建 buildroot 开发方案，用 docker 承载全部 AP 功能
应用商店化
- 这是路径一的自然副产物
- 既然所有功能都是容器，把它们包装成"应用"上架只是加个 UI 和元数据的事
路径二：重系统 + Docker 扩展（极空间模式）
特征
- 底层是一个完整的服务器级 OS（Debian 11 + systemd）
- 核心服务（相册、视频、网盘、用户系统）是原生二进制（Go），直接跑在宿主机
- Docker 只用来承载第三方扩展应用（Ollama、浏览器、下载工具等）
优势
- 性能更好：核心功能没有容器开销
- 用户体验一致：原生应用和容器应用在 UI 层无差别
- 资源可控：低端型号直接禁用 containerd，不影响核心 NAS 功能
劣势
- 移植成本高：换平台要重新编译全部原生服务
- 依赖管理复杂：系统层和容器层两套依赖体系
两条路径的对比
| 维度 | 路径一：buildroot + Docker | 路径二：重系统 + Docker 扩展 |
|---|---|---|
| 系统大小 | 极小（几十 MB） | 大（Debian 完整发行版） |
| 核心服务形态 | 全部容器化 | 原生二进制 + 容器扩展 |
| 移植难度 | 低 | 高 |
| 性能 | 有容器开销 | 核心路径无开销 |
| 应用商店 | 自然副产物 | 额外工程投入 |
| 适用场景 | 嵌入式、边缘计算、工业设备 | 消费级 NAS、家用服务器 |
结论
- 做产品（to C）：极空间选路径二是合理的。用户不关心容器，只关心"相册快不快、视频卡不卡"。Docker 只是给用户一个装第三方工具的入口。
- 做平台/方案（to B/开发者）：路径一更合适。快速移植、环境一致、回滚方便，这些对工程团队是硬需求。
- 应用商店化本身不是目的，而是容器化程度足够高之后的自然结果。