前端开发为什么不该每次都 Docker / 全量编译？

Primer

① 先把后文会反复出现的词认清楚

规则：先知道术语是什么，再用它们做综合判断。卡片收起时就能看到一句话直觉；需要严格定义、边界和案例作用时再展开。

先认词：这一课的重点是把开发反馈和发布证明分层。先认清下面这些词，再讨论“什么时候该跑重任务”。

Runtime · 运行时程序真正执行代码、维护状态并调用平台能力的环境。

直觉: 源码像剧本，Runtime 是真正演出的舞台。
边界: 浏览器、Flutter Debug Runtime、微信小程序运行环境都属于 Runtime；它不是发布包。

Vite Development Server · Vite 开发服务器专门服务开发态前端并把源码变化快速送到浏览器的服务器。

当前案例: React/Vue/uni-app H5 日常预览优先复用 dev server，而不是每次做 production build。

Hot Module Replacement (HMR) · 热模块替换应用不整体重启，只替换发生变化的前端模块。

边界: HMR 证明开发态反馈快，不证明生产构建和目标平台已经正确。

Hot Reload · 热重载把新代码注入正在运行的调试应用，并尽量保留页面状态。

当前案例: Flutter 常用 Hot Reload 做 UI 与 Dart 逻辑的快速反馈。

Incremental Compilation · 增量编译只重新处理本次变化及其受影响依赖，而不是全量重建。

直觉: 只重印改过的章节，不重新印整本书。

Mock API · 模拟接口用可控假响应代替真实后端，稳定复现成功、空态与错误态。

边界: Mock 能验证前端逻辑，但不能冒充真实后端联调。

API Proxy · 接口代理开发服务器把 /api 请求转发到本地、测试或受控远端后端。

当前案例: 它让本地前端不用重建生产包就能连接真实 API。

Target Runtime · 目标平台运行时真正具有微信、Android、iOS 等平台生命周期、权限与原生 API 的环境。

边界: Chrome 正常不能自动推出微信或手机原生能力正常。

Production Build · 生产构建生成准备正式交付给用户的优化发布产物。

边界: 普通 UI 小改不必每次运行；候选或发布节点必须证明它能成功生成。

Docker Build · 容器镜像构建按 Dockerfile 把程序、依赖和运行环境组装成可部署镜像。

边界: 它属于交付与环境一致性层，不是普通前端预览默认前置。

End-to-End Testing (E2E) · 端到端测试从真实入口跨过多个组件验证完整用户链路。

边界: E2E 成本高，日常优先跑受影响链路，合并/发布再扩大范围。

Deployment Readback · 部署读回发布后从真实线上环境重新读取版本、页面、接口或健康状态。

当前案例: 它证明“刚验收的候选确实在线”，而不是只相信部署命令返回成功。

我能解释 Runtime、Vite Development Server、HMR、Hot Reload、Incremental Compilation、Mock API、API Proxy、Target Runtime、Production Build、Docker Build、E2E 与 Deployment Readback 分别证明什么。

Orient

② 现在再看这段材料到底在说什么

一句话：你真正要优化的不是“能不能彻底不编译”，而是每次小改是否只做与改动规模相匹配的最小反馈。把日常开发和发布证明混成一条流水线，才是“改一个按钮也要等 Docker”的根因。

核心判断：开发态应该优先复用已经运行的 Runtime，用 HMR / Hot Reload / 增量编译只更新受影响部分；Mock、真实 API 联调和目标平台验证逐级增加真实性；Production Build、Docker、全量 E2E 和线上 readback 留到合并或发布节点。

事实 · Docker 解决什么

Docker 的核心价值是封装运行环境和交付一致性。它非常适合后端、依赖复杂服务和生产部署，但它不是“看一眼前端按钮颜色”的必要前置。

推断 · 真正要缩短什么

应该缩短的是 修改 → 看见效果 → 判断对错 的反馈回路，而不是为了追求“零编译”把目标平台验证也删掉。

风险 · 快速检查不能冒充发布证据

Mock 成功、H5 正常或 Chrome 正常，都不能证明微信 Runtime、原生插件、生产构建和线上部署一定正常。快路径与发布门禁必须明确分层。

把开发想成数学研究：日常改动像先做数值实验和局部引理；只有准备提交“正式证明”时，才跑完整构建、全量测试、容器和部署读回。每改一个符号都重写整篇证明，当然会慢。

我已经能区分“快速开发反馈”和“发布证明”，不会再把 Docker 当成普通 UI 预览的默认前置。

Connect

③ 概念关系与最小知识闭包

把所有技术栈统一成五级反馈模型。越往右，运行环境越接近真实发布，成本和证明强度也一起上升。

读图：不是每次都跑到 L4；应该根据改动影响面选择“足以证明本次改动”的最低层级。

最小知识闭包：优化的是 Δ，不是整个仓库 N

把一次反馈时间粗略写成：

T_{feedback, full} = T_{install} + T_{full-build} (N) + T_{docker} + T_{full-test} (N)

而日常快速反馈更希望接近：

T_{feedback, fast} \approx T_{incremental} (Δ) + T_{affected-test} (A (Δ))

因此“无 Docker”不等于“零编译”。 uni-app、Flutter、小程序开发态仍可能做源码转换或增量编译；只要它复用 Runtime、只处理变化范围，它依然属于快路径。真正重的是每次都生成完整发布产物、完整容器、完整截图矩阵和完整 E2E。

级别	你在证明什么	典型工具	什么时候停在这里就够了
L0	布局、文案、基础交互	Vite、http.server、Widget Preview / Chrome	纯 UI/CSS/文案改动
L1	前端状态机在固定数据下正确	MSW、fixtures、Fake Repository、契约 Mock	接口未完成、异常态和空态开发
L2	前后端契约与真实请求正确	dev proxy、测试后端、API smoke	请求映射、权限、SSE、错误码
L3	目标平台能力正确	微信开发者工具、模拟器、真机	平台 API、权限、原生插件、生命周期
L4	正式交付链条正确	Production Build、CI、Docker、上传/部署 readback	提交、合并、发布候选、生产上线

Reconstruct

④ 把真实案例重新还原

把你前面遇到的三类项目放进同一个模型，会发现它们只是“最低可用 Runtime”不同。

案例 A · MathArc：静态前端 + Python Runtime

L0：纯 HTML/CSS/JS 页面可以直接由静态服务器提供，几乎没有前端编译成本。

python3 -m http.server 4173 --directory docs/prototypes

L1：用确定性的 demo server 返回固定 Agent 过程；L2：切到真实 workspace API；只有正式验收才跑完整浏览器门禁和发布流程。

这类项目说明：如果源代码本身就是浏览器可执行格式，“零前端编译”是真正可实现的。

案例 B · Sub2API：Vite 前端 + Go 后端 + Docker

L0/L1：Vite dev server + HMR 看页面或接 Mock；L2：dev server 通过 Proxy 接已经运行的本地/测试后端。

只改页面、样式和文案时，不需要重新编译 Go。修改后端逻辑时才重新构建后端；正式交付时再把前端 production build、Go 二进制、Docker 镜像与线上 readback 串起来。

生产后端代理的边界：如果为了方便把本地前端代理到生产 API，应默认只做安全读取；登录、支付、删除、配置修改等写操作不能当普通 UI 调试随意执行。

案例 C · AthleteOS 类跨端客户端

当客户端是 uni-app、Flutter 或原生小程序时，开发态不能简单理解成“完全不编译”，因为源码需要进入各自 Runtime。

正确做法是：先在最轻 Runtime 里完成大多数 UI/业务逻辑，再在涉及平台 API 时升级到 L3。例如 uni-app 先 H5，Flutter 先 Chrome，原生小程序直接在微信开发者工具中增量调试。

目标不是删除平台验证，而是让平台验证只在真的受平台差异影响时发生。

事实

uni-app CLI 把 dev:h5/dev:mp-weixin 与 build:h5/build:mp-weixin 分开；Flutter 也区分 flutter run 调试周期与 flutter build 发布构建。

推断

因此你的统一工程规范不应该写成“所有前端都不编译”，而应该写成“默认使用开发态 Runtime 与增量反馈，不执行发布级全量构建”。

风险

H5/Chrome 只是快速近似环境。平台组件、生命周期、权限、原生插件、微信 API 等一旦进入改动范围，必须升级到 L3。

我能为 MathArc、Sub2API 和跨端客户端分别指出日常开发的最低 Runtime，以及什么时候必须升级到目标平台或发布验证。

Map

⑤ 概念如何映射到现实

现在把三种跨端方案放到“最快反馈 → 真实联调 → 平台验证 → 发布”的同一张表里。

技术栈	最快看 UI / 业务	真实 API 联调	什么时候必须进目标平台	发布构建	日常要 Docker？
uni-app	`npm run dev:h5`；Vue3 Web 侧可使用 Vite 开发服务器。	H5 + Vite `server.proxy` 指向本地或测试 API。	`wx.*`、微信登录/支付、平台组件、平台生命周期等：`dev:mp-weixin` → 微信开发者工具/真机。	`npm run build:mp-weixin` 等目标平台 build。	通常不需要
Flutter	`flutter run -d chrome` + Hot Reload；移动端也可保持调试 Runtime 热重载。	运行中的 App/Chrome 连接测试 API，Repository 层可在 fake / real 间切换。	相机、蓝牙、推送、原生权限、platform channel / native plugin、真实性能等：Android/iOS 模拟器或真机。	`flutter build ...` 生成正式 Web/APK/App Bundle/IPA 等产物。	通常不需要
原生微信小程序	微信开发者工具本身就是开发 Runtime，保存后做开发态编译/刷新。	开发者工具连接 Mock、本地可达后端或测试环境 API。	它从一开始就在微信 Runtime；支付、授权、硬件与部分网络行为仍要真机预览。	正式上传、审核与发布前执行完整构建/检查。	通常不需要

一个实用比例：大多数页面和普通业务逻辑停在 L0–L2；只有平台相关改动进入 L3；只有提交、合并和发布候选进入 L4。具体比例取决于项目，但“默认从最低充分层开始”比固定跑全量流水线更重要。

给 AI / Vibe Coding 工作流一个统一入口

不要让 Agent 记住每个仓库几十条命令。给不同技术栈暴露同样的四个语义入口：

make preview       # 最快看 UI / 基础交互
make mock          # 固定接口状态，独立开发前端
make integration   # 连接真实测试 API / 目标开发服务
make verify        # 发布级完整证明：build / tests / Docker / readback（按项目需要）

内部实现可以完全不同，但语义稳定。例如：

入口	uni-app	Flutter	Sub2API / Vite
`preview`	`npm run dev:h5`	`flutter run -d chrome`	Vite dev server
`mock`	H5 + fixtures / Mock server	Fake Repository / Mock server	Vite + MSW / fixtures
`integration`	H5 proxy → test API；必要时 mp-weixin	Debug Runtime → test API	Vite proxy → local/staging backend
`verify`	目标 build + 平台 smoke	analyze/test + target build	production build + Go + Docker + E2E

最终工程原则：

Validation Scope = f (Change Impact)

。不是仓库越大，每次验证范围就必须越大。

当前版本的官方依据与可继续查阅的文档

这些链接是为了校正容易随版本变化的工具行为；本页的五级反馈模型本身不依赖具体版本。

Attempt

⑥ 现在把它当成一道题

假设你正在开发一个 AthleteOS 类客户端，后端测试环境已经稳定。今天 Agent 连续提交了下面 5 组改动。请给每组选择最低充分验证层级（L0–L4），并说明是否需要 Production Build / Docker。

A只改训练卡片的间距、字号和一句提示文案。

你会跑到哪一层？

B后端把 review_status 的枚举扩展了一个值，前端需要正确展示和处理 409。

Mock 和真实 API 各自承担什么？

Cuni-app 新增 wx.login，或 Flutter 新增一个调用相机的原生插件。

H5 / Chrome 还能不能作为最终证据？

DSub2API 修改 Dockerfile、Go embed 方式和生产静态资源路径。

为什么这次不能停在 Vite？

E准备正式上线。

哪些快路径可以复用，哪些发布门禁不能省？

你的作答

我已经完成自己的第一版作答，再进入提示。

Hint → Answer

⑦ 分级提示，最后就是实际答案

Hint 1 · 方向

先不要看技术栈名称，只问一个问题：这次改动改变了哪一层的行为？ UI → L0；固定状态 → L1；真实接口 → L2；平台 API → L3；构建/部署链 → L4。

Hint 3 · 接近答案

改动	最低层级	关键理由
A UI 文案	L0	不涉及接口和平台
B API 枚举/409	L1 → L2	先固定状态，再真实联调
C wx.login / native plugin	L3	必须目标 Runtime
D Dockerfile / Go embed	L4	改的是交付链本身
E 正式上线	L4	必须形成发布证明