Python Flask与微信小程序打造水果百科与价格查询工具

做这个“python鲜而廉水果百科网站微信小程序”的时候，我并不是想做一个正经的生鲜电商。起因很简单：我妈在菜场买水果，总会被摊主一句“今天刚到的，新鲜”打动，但回家一吃又觉得亏。反过来，我的一个朋友在水果店打工，常常为店里当天的榴莲和草莓卖不动发愁。两头的痛点都非常具体——买的人不知道什么价格合理、什么状态算新鲜；卖的人不知道怎么让用户快速判断这批货值不值。

所以这个项目的定位非常明确：用 python 写一套后端服务，负责水果百科数据、多源价格数据和新鲜度评分；用微信小程序做用户界面，让用户在小程序里搜水果、看百科、查价格区间、看新鲜度提示。它不是一个通用商城模板，而是一个带“信息服务”属性的水果工具。接下来我会把整个设计与实现过程拆开讲，包括为什么选 Flask、数据库表怎么设计、价格和新鲜度怎么计算、小程序端怎么对接，以及上线时容易踩的坑。

1. 先想清楚一件事：这个项目到底要解决谁的什么麻烦

1.1 水果交易里的两头信息差

大多数水果类小程序一上来就做下单、支付、物流，结果连商品标准都没建立。我的思路是反过来的：先做信息服务，再考虑交易。买水果的人其实需要三类信息：这个水果是什么、现在这个季节值不值得吃、当前价格有没有买贵。对应到系统里就是百科、产季和价格。如果这三类信息足够准，用户自然会信任，后面再做社区、团购、优惠券才有基础。

“鲜而廉”三个字听起来像广告语，落到系统里其实是两个可计算的指标。鲜不是靠商家自吹，而是用产季、采摘/上架时长、产地距离三个维度做加权评分；廉也不是绝对低价，而是当前价格相对该水果近期市场均价的折扣程度。后面我会详细讲这两个指标的计算，这里先记住一个结论：这个项目的核心不是页面数量，而是数据质量和计算逻辑。

1.2 把“鲜”和“廉”拆成可计算的指标

如果只做展示，这个项目会非常单薄。我在需求分析阶段就把“鲜”和“廉”拆成了公式：

• 鲜度评分 fresh_score = 季节匹配分 * 0.4 + 上架时效分 * 0.35 + 产地损耗分 * 0.25
• 廉值参考 price_ratio = current_price / avg_price_last_30_days
• 当 price_ratio < 0.9 时标记为“低于近期均价”；0.9~1.1 为“正常”；超过 1.1 为“偏贵”

季节匹配分来自一个月份表，例如荔枝在6月属于产季，得分高；12月基本是反季存储果，得分低。上架时效分取决于商品首次录入或被商家标记的时间，越短越新鲜。产地损耗分根据水果产地到当前城市的距离估算，距离越近损耗越低。这三个分数在小程序里不是直接暴露原始数字，而是转换成“新鲜度很好/一般/建议谨慎购买”的文案，用户不需要理解算法也能用。

举个例子，用户在小程序里搜索“荔枝”，系统拿到当前月份为6月，从季节表查到荔枝产季是5到7月，季节匹配分90；用户所在城市是武汉，而数据库中荔枝的常见产地是广东茂名，距离约1100公里，产地损耗分50；该条商品在上午采集到的价格为8.8元/500g，近30日该城市荔枝均价是10.2元/500g，算出来 price_ratio=0.86，于是后端返回“属于当季水果，价格低于近期均价，整体建议购买”。这一系列判断从请求到返回必须在500毫秒内完成，不然用户在水果摊前等太久就会关掉页面，所以后端的接口缓存和查询索引非常重要。

2. 技术栈选择：为什么是 Python 配微信小程序

2.1 Flask 与 Django、FastAPI 的取舍

这个项目最稳妥的方案是 Python Flask + MySQL + Redis + 微信小程序原生，而不是用 uniapp 或者 Django。很多人会问为什么不直接用 FastAPI？FastAPI 的优势在于异步和高并发，但这个阶段的数据量级不会超过几万用户，性能瓶颈在数据采集和数据库查询，不在接口框架本身。Django 带了很多用不上的组件，后台管理、ORM、模板、middleware、auth，对一个百科加价格查询类应用来说太重，部署和内存开销也更大。Flask 足够轻，上手快，而且从最简单的 app.py 到模块化蓝图都可以平滑演进，非常适合这个项目。

我实际的项目结构这样组织：

text复制fruit_project/
├── app.py                 # Flask 入口
├── config.py              # 配置项：数据库、密钥、外部接口
├── models.py              # SQLAlchemy 模型
├── api/                   # 蓝图：auth, fruit, price, user
├── services/              # 业务逻辑：新鲜度、价格计算、采集任务
├── spider/                # 价格采集与解析
└── requirements.txt

这个结构不是一开始就有的。我最早把所有路由都塞在 app.py 里，后来水果种类超过50个、接口超过20个之后，文件变得不可维护，才拆成蓝图。如果你也是从单体开始，建议至少把 models、api 和 services 分开，后面不用返工。特别是 services 层负责新鲜度计算和价格聚合，把计算逻辑分离出来之后，写单元测试或者换接口框架都很方便，不会被路由代码