Weapp-vite: 对小程序工程化的重新思考

副标题：从“功能堆叠”到“工程系统”

讲者：
时间：2026-03-04

layout: default

这场分享你能带走什么

一个可复用的工程化判断框架（5 个维度）
Weapp-vite 的关键取舍，而不是参数清单
一份可落地的 30 天迁移/升级路线

问题不在“有没有功能”

很多团队已经有：

Vue 写法
分包配置
热更新工具
Tailwind 或其他原子化方案
AI 编码助手

但依然会遇到：

协作不稳定
迭代速度波动
包体与首开相互拉扯
语法升级后运行时问题变多

layout: center

核心观点

小程序工程化的关键，不是多支持一种写法

而是把开发、构建、调试、协作接成一条链路

layout: section

1) AI 协作

从“会写代码”到“可控地参与工程”

AI 协作的三层结构

Skills：减少“看起来对，执行跑偏”
MCP：让 AI 真正读代码、跑命令、调用工具
llms：降低上下文遗漏和误判

这不是文档口号，有源码落地

关键证据：

packages/weapp-vite/src/defaults.ts
- mcp.enabled: true
- mcp.autoStart: false
packages/weapp-vite/src/mcp.ts
- 提供 stdio / streamable-http
packages/weapp-vite/src/cli/commands/mcp.ts
- 直接支持 weapp-vite mcp

结论：AI 不是外挂窗口，而是工程内角色。

团队落地建议（AI）

先统一 Skills 触发词和任务模板
MCP 只开放必要能力，避免过宽权限
在 PR 模板里增加一条：
- 本次变更是否可被 AI 工作流复现

layout: section

2) 原子化样式

不是审美选择，是治理选择

为什么是“治理问题”

样式体系一旦规模化，痛点通常是：

重复样式不断增长
组件样式语义不统一
改一个设计 token 需要大量回归

原子化样式的价值：

让样式复用从“复制”变“组合”
让设计约束从“约定”变“语法”

Weapp-vite 的处理方式：集成，而不重造

文档入口：website/integration/tailwindcss.md
脚手架：create-weapp-vite 自动补齐 weapp-tailwindcss
- packages/create-weapp-vite/src/createProject.ts
HMR 细节：检测到 weapp-tailwindcss 时自动 touch app.wxss
- packages/weapp-vite/src/runtime/buildPlugin/touchAppWxss.ts

这让“原子化写法”与“开发体验”绑定在同一条链路上。

样式体系的三个常见误区

把原子化当作“少写 CSS”的工具
没有组件级样式边界规范
缺少设计 token 与业务语义的映射层

建议：

先定 token，再定 class 约定
每个业务域维护最小组件样式规范
将“样式变更成本”纳入迭代评估

layout: section

3) 分包策略

从“会分”到“分得对”

分包真正的决策点

你每次都在做权衡：

首开速度优先？
总体积优先？
共享模块复制还是提炼？

weapp-vite 把这件事显式化为策略：

sharedStrategy: 'duplicate'（默认）
sharedStrategy: 'hoist'

`duplicate` vs `hoist`（工程视角）

策略	更适合	代价
`duplicate`	分包首开体验	可能增加冗余体积
`hoist`	控制总体积	分包首开可能依赖主包共享模块

源码锚点：

packages/weapp-vite/src/runtime/chunkStrategy/apply.ts
packages/weapp-vite/src/runtime/chunkStrategy/bundle.ts
packages/weapp-vite/src/plugins/core/lifecycle/emit.ts

分包治理建议

开发初期优先 duplicate（先保证体验）
稳定期结合数据评估是否切 hoist
使用 weapp-vite analyze 定期审查跨包共享与冗余
设定冗余体积告警阈值（duplicateWarningBytes）

layout: section

4) HMR

快很重要，稳定地快更重要

为什么很多团队 HMR 体验会波动

常见现象：

某些改动很快，某些改动突然变慢
共享模块改动后偶发不一致
“为了稳”被迫全量重建

weapp-vite 的思路：

默认 sharedChunks: 'auto'
能局部更新就局部更新
风险场景自动回退全量发射

HMR 证据与逻辑

性能参考（website/migration/v5.md）：

整体平均构建：约 1.86x 提升
热更新平均构建：约 2.50x 提升

关键逻辑文件：

packages/weapp-vite/src/plugins/hooks/useLoadEntry/index.ts
packages/weapp-vite/src/plugins/core/lifecycle/watch.ts

一句话：在正确性边界内，尽量缩小重建范围。

layout: section

5) 语法重写

不是“套个 Vue 壳”，而是编译 + 运行时协同

编译侧：完整阶段管线

wevu-compiler 中，compileVueFile 走的是完整链路：

parse
template
script
style
config
finalize

核心文件：

packages/wevu-compiler/src/plugins/vue/transform/compileVueFile/index.ts
packages/wevu-compiler/src/plugins/vue/transform/compileVueFile/parse.ts

模板与宏：结构化转换

v-if / v-else-if / v-else
- .../template/elements/tag-structural.ts
v-for alias/作用域解析
- .../template/elements/tag-structural.ts
v-model 宿主控件差异绑定
- .../template/directives/model.ts
definePageJson / defineComponentJson / defineAppJson
- .../transform/jsonMacros/*

这不是字符串替换，而是语义级编译。

运行时：为什么坚持 `diff + setData`

运行时关键文件：

packages/wevu/src/runtime/diff.ts

关注点：

快照 plain 化（可序列化）
差量路径计算
最小化 setData payload

这与小程序运行模型是对齐的。

为什么不是 `createRenderer` 主路线

结论不是“不能做”，而是“主线不划算”。

原因：

createRenderer 假设 host 节点操作模型
小程序核心更新模型是 setData(payload)
抽象错位会引入额外维护与性能成本

layout: section

6) 30 天落地计划

把“理念”变成“节奏”

第 1 周：基线盘点

跑一次 weapp-vite analyze，输出包体与共享模块图
盘点当前 HMR 耗时波动区间
梳理样式体系现状：token、组件、重复率
明确 AI 协作入口（Skills/MCP/llms）

交付物：当前状态基线报告。

第 2-3 周：小步试点

选 1 个业务分包试点 duplicate/hoist 策略
选 1 条页面链路试点 Vue SFC + wevu
选 1 个模块试点 AI 流程化协作

评估维度：

首开性能
迭代效率
缺陷率
回归成本

第 4 周：固化规则

形成团队配置基线（hmr/chunks/style）
把 AI 工作流写入工程文档与 PR 模板
制定版本节奏：每次迭代固定做一次 analyze
建立告警阈值：包体冗余、构建耗时、回归失败率

一句话：让工程化从“人治”变“机制”。

layout: center

总结

Weapp-vite 的价值不在“功能数量”

而在“系统一致性”

AI：可控协作
样式：可持续治理
分包：可解释策略
HMR：可预期速度
语法：可对齐运行模型

layout: center

Q&A

感谢聆听

可选补充材料： `website/blog/drafts/weapp-vite-rethinking-release.md`
`website/blog/drafts/weapp-vite-rethinking-deep-dive.md`

Weapp-vite: 对小程序工程化的重新思考 ​

layout: default ​

这场分享你能带走什么 ​

目录 ​

问题不在“有没有功能” ​

layout: center ​

核心观点 ​

小程序工程化的关键，不是多支持一种写法 ​

而是把开发、构建、调试、协作接成一条链路 ​

layout: section ​

1) AI 协作 ​

AI 协作的三层结构 ​

这不是文档口号，有源码落地 ​

团队落地建议（AI） ​

layout: section ​

2) 原子化样式 ​

为什么是“治理问题” ​

Weapp-vite 的处理方式：集成，而不重造 ​

样式体系的三个常见误区 ​

layout: section ​

3) 分包策略 ​

分包真正的决策点 ​

duplicate vs hoist（工程视角） ​

分包治理建议 ​

layout: section ​

4) HMR ​

为什么很多团队 HMR 体验会波动 ​

HMR 证据与逻辑 ​

layout: section ​

5) 语法重写 ​

编译侧：完整阶段管线 ​

模板与宏：结构化转换 ​

运行时：为什么坚持 diff + setData ​

为什么不是 createRenderer 主路线 ​

layout: section ​

6) 30 天落地计划 ​

第 1 周：基线盘点 ​

第 2-3 周：小步试点 ​

第 4 周：固化规则 ​

layout: center ​

总结 ​

Weapp-vite 的价值不在“功能数量” ​

而在“系统一致性” ​

layout: center ​

Q&A ​

Weapp-vite: 对小程序工程化的重新思考

layout: default

这场分享你能带走什么

目录

问题不在“有没有功能”

layout: center

核心观点

小程序工程化的关键，不是多支持一种写法

而是把开发、构建、调试、协作接成一条链路

layout: section

1) AI 协作

AI 协作的三层结构

这不是文档口号，有源码落地

团队落地建议（AI）

layout: section

2) 原子化样式

为什么是“治理问题”

Weapp-vite 的处理方式：集成，而不重造

样式体系的三个常见误区

layout: section

3) 分包策略

分包真正的决策点

`duplicate` vs `hoist`（工程视角）

分包治理建议

layout: section

4) HMR

为什么很多团队 HMR 体验会波动

HMR 证据与逻辑

layout: section

5) 语法重写

编译侧：完整阶段管线

模板与宏：结构化转换

运行时：为什么坚持 `diff + setData`

为什么不是 `createRenderer` 主路线

layout: section

6) 30 天落地计划

第 1 周：基线盘点

第 2-3 周：小步试点

第 4 周：固化规则

layout: center

总结

Weapp-vite 的价值不在“功能数量”

而在“系统一致性”

layout: center

Q&A