飞飞乐航班助手：小程序从 0 到 1 的架构手记
「飞飞乐航班助手」是我最近在做的微信小程序：把秋季度随心飞的 1898 条航班数据变成随手可查的查询工具。这篇记录它的整体架构和几个关键取舍。
整体架构
小程序的体量决定了它不该用复杂架构，我的分层很朴素：
┌─ 视图层 ─────────────────────┐
│ 首页筛选 / 结果列表 / 地图展示 │
├─ 逻辑层 ─────────────────────┤
│ 查询引擎（往返/环线/中转） │
│ 筛选器（日期/航司/城市/时段） │
├─ 数据层 ─────────────────────┤
│ data/flights.json（打包静态） │
│ 城市坐标映射 cities.json │
└──────────────────────────────┘几个关键取舍
1. 数据打进包里，而不是走后端
1898 条航班的结构化 JSON 压缩后不到 200KB，完全可以直接随包发布。好处：无后端、零延迟、免运维；代价：数据更新要发版本。对"季度航线"这种低频变化数据，完全够用。
2. 查询引擎放逻辑层
往返查询本质是"同航线正反方向配对"，环线是"三段首尾相接"，中转是"两段航线的中转点拼接"。我把这些规则抽成独立的纯函数模块，方便单测，也方便以后加"多程"玩法。
3. 地图只用展示，不用实时定位
地图组件只做静态标注：把航线和城市用 polyline / marker 画出来。省去了定位授权和实时接口的复杂度，也让审核更省心。
踩过的坑
- 包体积：一开始 JSON 里塞了冗余字段，压到 200KB 靠的是只保留查询所需字段；
- 城市名不一致：Excel 里"北京/北京市/北京首都"混用，必须清洗归一；
- 往返配对：往返≠两条独立记录，要按"日期+航线"对齐，否则查出来是乱的。
小程序开发的关键不在框架，而在"边界感"：知道什么该做进包、什么该留到后端、什么干脆不做。
下一步：给结果页加"按价格/时长排序"（数据源允许的话），以及行程分享卡片。等实现了再回来写。