D
Docker
容器化堆栈
主机操作系统
↓
Docker
Nginx
PHP
MySQL
Redis通过代码定义镜像、容器、网络和卷。
同一个 Laravel 项目，两种模式
相同应用，不同执行模型。
D
Docker
在 compose.yaml 中定义的容器化堆栈
主机操作系统
↓
Docker
Nginx 容器PHP 容器MySQL 容器Redis 容器网络：app-net
卷：db-data、redis-data
▤compose.yaml
在 compose.yaml 中定义的容器化堆栈。
VS
F
FlyEnv
主机操作系统上的原生服务
主机操作系统
Nginx原生PHP原生MySQL原生Redis原生
项目文件普通文件系统主机操作系统上的原生服务。
三个关键差异
两款工具的目标都是提供可用环境，但实现路径不同。
原生进程 vs 容器
FlyEnv 直接将 PHP、MySQL、Redis 和 Nginx 作为主机原生服务运行。Docker 则将它们组织为镜像、容器、网络和卷，与主机之间保持强隔离。
本地简洁性 vs 环境可移植性
FlyEnv 为本地开发提供更简单的思路，普通本地服务无需编写 Dockerfile 或 Compose 文件。Docker 的环境定义随项目一起保存，可让开发环境与 CI、预发布和生产保持一致。
图形界面管理服务 vs 基础设施即代码
FlyEnv：在图形界面选择版本、启动服务、创建站点。Docker：在 compose.yaml 中定义服务，再用一条命令启动整个堆栈。
日常开发中的实际体验
相同堆栈，两种不同工作流。
原生服务管理
FlyEnv 服务可在桌面应用中安装、启动和停止，并统一管理版本、端口和配置。
services:
app: # image, ports, volumes
db: # image, environment
redis: # image, networks
容器化服务定义
Docker 服务以 YAML 中的镜像、端口、卷和网络声明，形成精确且可版本控制的环境定义。
compose.yaml↓
开发→CI→预发布→生产
开发与生产一致性
Docker 的优势在于同一套定义可运行于 CI、预发布和生产环境；FlyEnv 则专注于本地计算机体验。
功能对比
比较的是运行模式，而不是功能数量——两者都能构建完整的本地环境。
| 能力 | Docker / Docker Compose | FlyEnv |
|---|---|---|
| 执行模式 | 容器 | 主机原生进程 |
| 环境定义 | Dockerfile / Compose YAML | 图形界面和项目配置 |
| 隔离 | 强容器隔离 | 主机级服务 |
| 生产环境可移植性 | 强 | 不是主要目标 |
| CI/CD 可移植性 | 强 | 有限 / 非主要目标 |
| 本地域名 / HTTPS | 通过堆栈或代理配置 | 内置本地站点工作流 |
| 运行时版本 | 容器镜像标签 | 托管的本地版本 |
| 数据库服务 | 容器镜像 | 托管的原生模块 |
| 网络 | Docker 网络 | 主机网络 |
| 卷 | Docker 卷 / 绑定挂载 | 原生文件系统 |
| 项目启动 | docker compose up | 图形界面和启动组 |
| 资源开销 | 取决于操作系统的 Docker 运行时或虚拟机 | 原生进程 |
| 图形界面管理 | Docker Desktop 和工具 | FlyEnv |
| 最适合 | 可移植、可复现的容器环境 | 原生本地开发 |
典型 Laravel 项目的两种方式
并排查看同类工作的处理方式。
D
使用 Docker
F
使用 FlyEnv
使用 Docker
1
编写或选择 Dockerfile 和镜像
使用 FlyEnv
1
选择 PHP 版本
使用 Docker
2
创建 compose.yaml
使用 FlyEnv
2
创建本地站点
使用 Docker
3
配置端口
使用 FlyEnv
3
启动数据库和缓存
使用 Docker
4
配置卷
使用 FlyEnv
4
启用 HTTPS
使用 Docker
5
配置网络
使用 FlyEnv
5
启动项目服务
使用 Docker
6
使用 docker compose up 启动
使用 FlyEnv
6
打开站点并开始开发
Docker 的额外配置也正是环境能够在不同计算机和部署阶段之间移植并复现的原因。
应该选择哪一个？
两款工具都很有用，正确选择取决于你的工作流。
选择 Docker 的情况
- ✓需要与生产环境保持一致。
- ✓团队已经使用容器部署。
- ✓需要强环境隔离。
- ✓需要可复现的 CI、预发布和开发环境。
- ✓项目已经包含 Dockerfile 或 compose.yaml。
选择 FlyEnv 的情况
- ✓主要需要快速的原生本地开发环境。
- ✓不需要容器隔离。
- ✓希望通过桌面界面管理运行时和服务。
- ✓偏好原生文件系统和网络性能，以及直接使用本地工具。
- ✓项目本身不要求使用容器。
考虑结合使用的情况
- ✓日常开发使用 FlyEnv 原生环境，同时为 CI、部署、集成测试或要求容器一致性的项目保留 Docker。
- ✓你使用原生方式开发，但团队以容器作为交付标准。
- ✓同一台计算机上的不同项目有不同需求。
FlyEnv 和 Docker 并不互斥——许多团队在本地使用原生服务，在其他环境使用容器。
常见问题
FlyEnv 能替代 Docker 吗？
不能。FlyEnv 管理原生本地服务；Docker 将应用打包到容器中。两者解决不同问题，也可以结合使用。
什么时候应该使用 Docker 而不是 FlyEnv？
当生产一致性、隔离性或可复现的 CI/预发布环境很重要，或者项目已经提供 compose.yaml 时。
什么时候 FlyEnv 更合适？
当你希望获得快速的原生本地环境，统一管理运行时、本地域名和 HTTPS，且不想编写 Dockerfile 或 Compose 文件时。
可以同时使用 FlyEnv 和 Docker 吗？
可以——常见做法是日常原生开发使用 FlyEnv，CI、集成测试或要求容器一致性的项目使用 Docker；请避免两者端口冲突。
FlyEnv 内部使用容器吗？
不使用。FlyEnv 在 macOS、Windows 和 Linux 上以宿主机上的原生进程方式运行各运行时和服务。
Docker 会自动提供本地域名和 HTTPS 吗？
默认不会。通常需要自行添加反向代理（Traefik、nginx-proxy）和证书（mkcert 或 CA）；FlyEnv 内置了用于域名和 HTTPS 的本地站点工作流。
团队更容易统一采用哪一个？
如果团队使用容器部署，Docker 的 compose.yaml 是最明确的团队统一配置约定；对于在 macOS、Windows 和 Linux 上进行原生开发的团队，FlyEnv 可提供一致的桌面工作流。
FlyEnv 能与已有 compose.yaml 的项目配合使用吗？
可以——compose 文件保持不变；你可以在 FlyEnv 中原生运行应用的运行时和服务，也可以继续为该项目使用 Docker。
使用 FlyEnv 尝试原生本地开发
创建本地站点，选择所需运行时和服务，然后开始工作——无需容器。