用Python+Flask从Excel数据清洗到可视化构建农产品推介系统

做这个项目的起因，是一份三十多兆的Excel表格。当时朋友所在的合作社要参加一场农产品推介会，让我帮忙从表格里挑出“国庆前后上市、适合礼盒装、供货量大的猕猴桃供应商”。我翻了三张工作表，发现价格字段有的是“3.5元/斤”，有的是“面议”，产地有的写到村，有的只写了“陕西”。半小时后我放弃了手动排查，第一次萌生了“为什么不用Python把这堆信息做成一个能搜的系统”的想法。

之后我陆续接触了几个产区的情况，发现这种信息断层相当普遍：洛川苹果、眉县猕猴桃、汉中仙毫、秦岭核桃……几乎每个特色产品背后都有一份或几份结构混乱的Excel，而外地采购商和消费者想了解陕西特色农产品，只能靠微信群和口口相传。于是就有了这套基于Python的陕西特色农产品推介系统：把农产品数据收拢、清洗、入库，再通过分类浏览、关键词搜索和偏好推荐三条路径，让信息真正“流动”起来。如果你手头也有类似的数据表格，想做一个可以拿去演示或落地的推介展示类系统，这篇文章的完整思路应该能帮你省下不少试错时间。

1. 这个系统要解决的核心问题：陕西农产品的信息断层

1.1 痛点远不止“没有网站”那么简单

先聊一个问题：陕西特色农产品缺推介渠道吗？其实不缺。政府有官网专题、农业公司有商城、县域也有电商平台。但真正到一线看，数据是断的：

• 官网专题更新慢，很多应季产品的实时信息根本不会出现在公开网页上
• 电商平台的商品信息由商户自行维护，但很多农户并没有时间系统整理
• 合作社的原始数据几乎都在Excel里，而且每个乡镇的表格格式都不一样

这意味着什么？意味着“有数据”和“可以用”之间隔着一整套清洗、结构化和检索的工作。这个系统做的事就是这一层：不是再建一个商城，而是把散落在表格里的农产品信息，变成人人都能查、能比、能用的结构化数据。我见过太多农业类的信息化项目，一上来就想着做交易、做物流、做溯源，结果半年过去连基本的产品目录都没建好。推介系统的本质，是先解决“让别人知道你有什么”的问题。

1.2 三类用户，三种诉求

在设计功能之前，我先把用户分成了三类，每类的核心诉求完全不同：

这三类诉求不是并列关系，而是层层递进的。消费者需要的是“看得见”，采购商需要的是“找得准”，农户需要的是“有人看”。所以系统的功能设计也按这个顺序展开：先有完整的信息展示，再做检索和筛选，最后通过推荐把热度资源倾斜给优质产品。顺序反了就会出现一个很尴尬的局面——搜索做得再智能，库里没几样东西可搜也是白搭。

1.3 项目边界必须划清楚

这个系统最容易犯的错误是“什么都要做”。我在最开始也想过：要不要加在线交易？要不要对接物流？要不要做溯源？后来全砍了。原因很简单：在线交易涉及支付资质、退款、售后，是一个完整的电商项目；物流对接需要相关的接口协议；溯源涉及物联网硬件。这些和“推介”是两个维度的事。

所以最终的项目边界定为：信息管理加检索、推荐、简单的可视化看板。让用户找到想要的农产品和联系人，剩下的事情线下完成。这个边界在开发时帮我省掉了至少一半工作量，也让项目能在一个月内从零跑通。务实地说，一个演示级甚至小型落地级的推介系统，做到“查得到、比得了、联系得上”就已经完成使命了。

2. 技术选型复盘：为什么够用就好，而不是越新越好

2.1 框架选型：Flask、Django、FastAPI怎么选

这个项目刚开始有人建议我用FastAPI，说性能好；也有人建议用Django，说自带后台管理。我最终选了Flask，理由不是技术洁癖，而是从项目规模倒推的：

选Flask还有一个实际原因：不同用户电脑里的Python版本差异很大。Flask对Python 3.7到3.12都兼容得很好，减少了一堆“环境装不上”的问题。如果是Django的较新版本，某些老机器上的Python 3.6直接装不了，你得先折腾半天升级Python。做这种中小型项目，稳定比炫技重要得多。

2.2 数据存储：SQLite起步，不要一上来就上MySQL

很多教程一上来就让你装MySQL，对这个小项目来说完全没有必要。SQLite是一个文件型数据库，单文件、零配置、支持标准SQL，阅读量在几千这个量级完全扛得住。我用Python的sqlite3标准库直接操作，不需要额外安装数据库服务，项目拷到别的电脑上直接就能跑。

只有遇到以下情况才需要考虑迁移到MySQL：

• 多人同时写入导致“database is locked”频繁出现
• 数据量超过几十万行且需要复杂事务处理
• 需要和外部系统做实时数据同步

当前这个推介系统，SQLite绰绰有余。我通过PRAGMA journal_mode=WAL开启预写日志模式，连并发读写的锁问题都基本规避了。这个细节后面会再提到，因为它是实际运行中最容易踩的隐藏坑之一。

2.3 前端方案：Jinja2模板加Bootstrap，不搞前后端分离

我知道现在前端流行React、Vue一套套的，但推介系统这种业务，前后端分离的成本是实实在在的：多一套Node环境、多一层接口调试、多一个打包步骤。我在这个项目里老老实实用了Flask自带的Jinja2模板，配合Bootstrap 5做样式。

模板渲染的好处是：数据直接在服务端拼好，页面刷新即是最新状态，部署时一个Python进程加四个文件夹搞定，不需要反向代理转发到前端静态服务器。等将来用户量上来、交互变复杂，再把接口层抽出来也不迟。我在这个项目里还发现一个额外好处：写模板时可以直接在HTML里判断数据是否存在，比如产品没有图片就显示占位符，这种“服务端兜底”比前端框架里写一堆条件判断要省心得多。

2.4 工程目录与虚拟环境

无论什么时候开始，先把虚拟环境建好，并固定依赖版本。这一步看似基础，但我见过太多人图省事全局安装，结果换台电脑项目就跑不起来。正确做法是：

python -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate pip install flask pandas openpyxl requests beautifulsoup4 waitress pip freeze > requirements.txt

目录采用最小可用结构：

shaanxi_agro/ ├── app.py # Flask 主入口 ├── database.py # SQLite 初始化与连接 ├── import_data.py # Excel 导入脚本 ├── crawler.py # 数据采集脚本 ├── templates/ # Jinja2 模板 │ ├── base.html │ ├── index.html │ └── detail.html ├── static/ # CSS/JS/图片 ├── data/ │ ├── shaanxi_products.xlsx │ └── products.db └── requirements.txt

这种分层的好处是：app.py只负责路由和页面逻辑，数据导入、数据库操作、爬虫各自独立，将来改任何一块都不会牵一发动全身。如果你只是临时演示，把代码全塞进app.py也能跑，但后面维护起来会想骂人。尤其是涉及大数据量重新清洗的时候，脚本独立成文件能节省大量来回测试的时间。

3. 把散落的Excel变成可检索的数据库：数据资产化的完整过程

3.1 数据字段设计：一开始想清楚比什么都重要

在导入任何数据之前，先定义好产品信息表的结构。这张表设计得合理，后面的搜索、筛选、推荐全都好做；设计得差，后面写多少补丁代码都觉得别扭。

我最终使用的字段如下：

特别注意：把tags设计成逗号分隔的字符串，而不是单独建一张标签表，是刻意为之。虽然不符合数据库第三范式，但这种小型推介系统的查询场景远多于写入场景，反范式设计能极大简化搜索逻辑。等到标签真的需要做多对多管理时再拆表也不迟。建表SQL如下：

CREATE TABLE IF NOT EXISTS products ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, category TEXT, origin TEXT, season TEXT, price_min REAL, price_max REAL, supply TEXT, contact TEXT, description TEXT, tags TEXT, image_url TEXT, view_count INTEGER DEFAULT 0, created_at TEXT DEFAULT CURRENT_TIMESTAMP );

3.2 pandas读取Excel并入库

实际工作中，数据来源几乎都是Excel。我用pandas读取原始表格，做基础清洗后一次性写入SQLite：

import pandas as pd import sqlite3 df = pd.read_excel("data/shaanxi_products.xlsx", sheet_name="汇总") # 去重：同一产品名和产地只保留一条 df = df.drop_duplicates(subset=["name", "origin"]) # 空值兜底 df["season"] = df["season"].fillna("全年") df["price_min"] = pd.to_numeric(df["price_min"], errors="coerce").fillna(0) df["price_max"] = pd.to_numeric(df["price_max"], errors="coerce").fillna(0) df["supply"] = df["supply"].fillna("面议") df["contact"] = df["contact"].fillna("待补充") conn = sqlite3.connect("data/products.db") df.to_sql("products", conn, if_exists="replace", index=False) conn.close() print("导入完成，共", len(df), "条记录")

这里有个实际细节：Excel中的“价格”列经常被pandas读成float，导致7显示成7.0。解决办法是在read_excel时指定dtype={"price_min": str}把价格先读成字符串，入库前再转REAL，或者直接在前端显示时做格式化。如果不做这一步，前端显示“7.0元/斤”很掉价，采购商看了也会觉得数据不严谨。

3.3 爬虫补充：从公开页面拿数据，注意分寸

Excel导入只能覆盖已有的数据，部分品类的公开信息还需要从网上补充。我写了一个轻量爬虫，从公开的农产品信息页面抓取品类、产地、价格等字段：

import requests from bs4 import BeautifulSoup import time headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36", } url = "https://example.com/agriculture/list" # 仅为示例，实际使用需确认目标站点授权 resp = requests.get(url, headers=headers, timeout=10) resp.encoding = resp.apparent_encoding # 防止中文乱码 soup = BeautifulSoup(resp.text, "html.parser") for item in soup.select(".produce-item"): name = item.select_one(".name").text.strip() category = item.select_one(".category").text.strip() origin = item.select_one(".origin").text.strip() print(name, category, origin) time.sleep(1) # 限制频率，避免给目标站点造成压力

三点提醒：

只采集公开可访问、明确允许展示的页面信息，不触碰任何需要登录或加密的内容。批量采集前查看目标站点的服务条款，确认数据用途合法合规。设置请求间隔，控制频率，别给目标服务器造成负担。

爬虫在这个项目里只是锦上添花，不是主力。核心数据源还是Excel和人工维护，爬虫只负责补充一些公开的、基础性的品类信息，比如某个产品的常规上市时间、常见价格区间。这样既能丰富数据量，又不会把系统的数据质量押在一个不稳定的数据源上。

3.4 数据清洗的关键步骤

数据清洗是整个项目里最琐碎但也最值钱的部分。我遇到的典型问题有三种：

一是名称不统一。“红富士苹果”和“洛川红富士”在原始表里可能是两条，我根据名称和产地双重判断后发现是同一产品，用drop_duplicates(subset=["name", "origin"])做了合并。

二是品类字段乱写。“水果”“生鲜水果”“鲜果”三种写法其实都是同一类，需要先归一化。我的做法是维护一个映射表，把常见别名都映射到标准品类名上，入库前统一替换。

三是价格、供货量这类数值字段里混进了“面议”“电话咨询”等文本。这些文本需要单独拆出来存到supply字段，价格字段则保留数值型，方便前端做区间筛选和排序。

我的原则是：清洗宁可多花三个小时，也不要省。因为后面所有查询、推荐、统计都建立在数据质量之上，脏数据一旦入库，返工的成本是导入时的十倍。尤其是当你已经基于错误数据做出了一些展示页面后，再回头改字段，往往还要连带改模板、改搜索逻辑，非常痛苦。

4. 三层推介功能拆解：从目录浏览到偏好推荐

4.1 第一层：分类浏览，让人最快找得到“有哪些”

系统首页是一个商品卡片列表，上方提供筛选条件：品类、产地、上市季节三个下拉框。翻页用简单的LIMIT/OFFSET分页，每页12条。

@app.route("/") def index(): category = request.args.get("category", "") origin = request.args.get("origin", "") page = int(request.args.get("page", 1)) page_size = 12 sql = "SELECT * FROM products WHERE 1=1" params = [] if category: sql += " AND category = ?" params.append(category) if origin: sql += " AND origin LIKE ?" params.append(f"%{origin}%") sql += " ORDER BY view_count DESC LIMIT ? OFFSET ?" params += [page_size, (page - 1) * page_size] rows = db.execute(sql, params).fetchall() return render_template("index.html", rows=rows, page=page)

为什么用LIKE ?查产地而不是等于？因为“洛川”和“延安市洛川县”这两种写法可能同时出现在数据里，模糊匹配能让搜“洛川”时把“延安市洛川县”的苹果也带出来。代价是搜索速度比索引查询慢一点，但在几千条数据量级，这个差异完全可以忽略。等数据量真的大了，再上一套全文索引也不迟。

4.2 第二层：关键词搜索，跨字段检索是核心

采购商最常用的动作是输入一句话：“冬天上市的核桃”或者“眉县的猕猴桃”。我的搜索路由会把关键词同时放到name、description、origin、tags四个字段里做匹配：

@app.route("/search") def search(): keyword = request.args.get("kw", "").strip() if not keyword: return redirect(url_for("index")) like = f"%{keyword}%" rows = db.execute(""" SELECT * FROM products WHERE name LIKE ? OR origin LIKE ? OR category LIKE ? OR tags LIKE ? OR description LIKE ? ORDER BY view_count DESC """, (like, like, like, like, like)).fetchall() return render_template("list.html", rows=rows, keyword=keyword)

这里有个细节：搜索结果按浏览量排序，把热门的放前面。这种“搜索结果排序等于业务热度权重”的做法，在没有复杂相关性算法时是非常合理的选择。用户搜“猕猴桃”，眉县的徐香猕猴桃被搜次数多、浏览量高，自然排前面，这本身就接近“相关性”的直觉定义了。

4.3 第三层：偏好推荐，不必非得用人工智能

一提到“推荐”，很多人第一反应就是协同过滤、深度学习。但这个项目的早期根本没有用户行为数据，你拿什么训练模型？所以我用了最简单也最实用的思路：热门推荐加相似推荐。

热门推荐逻辑很简单：浏览量最高的前6个产品直接展示在首页“大家在看”区域，这本质上是把马太效应显性化，在运营上是完全成立的做法。用户点进来看这个产品，说明关注度高，那么展示高关注产品就是在帮运营者做流量倾斜。

相似推荐逻辑：进入某个产品详情页时，自动展示同品类、同产地、标签重合度高的其他产品：

@app.route("/product/<int:pid>") def detail(pid): db.execute("UPDATE products SET view_count = view_count + 1 WHERE id = ?", (pid,)) db.commit() product = db.execute("SELECT * FROM products WHERE id = ?", (pid,)).fetchone() if not product: abort(404) related = db.execute(""" SELECT *, (CASE WHEN category = ? THEN 3 ELSE 0 END + CASE WHEN origin = ? THEN 2 ELSE 0 END) AS score FROM products WHERE id != ? ORDER BY score DESC, view_count DESC LIMIT 4 """, (product["category"], product["origin"], pid)).fetchall() return render_template("detail.html", product=product, related=related)

这个打分公式就是一个简单的加权求和：同品类加3分、同产地加2分，标签重合的部分拉回Python里再用集合计算加分，最终按总分和浏览量排序。实测下来，这种方案在没有任何用户行为数据的前提下，推荐的准确率已经很够用，因为农产品消费本身就具有较强的产地和品类偏好。看洛川苹果的人，大概率也会关注延安其他水果；看汉中仙毫的人，对陕南茶叶普遍有兴趣。

我当时没有在SQL里直接算标签重合分数，而是先把候选数据拉出来再在Python里算，原因是用SQLite的字符串函数去处理逗号分隔的标签非常别扭，而且数据量小，Python里用集合操作反而更快也更直观。

4.4 页面渲染：Jinja2模板加卡片布局

页面上我采用了Bootstrap的卡片布局，每张卡片包含产品图片、名称、价格区间、产地标签、季节信息。详情页再显示完整描述、供货能力、联系电话，以及“相关推荐”区块。

模板的关键点是条件渲染：

<div class="card h-100"> {% if product.image_url %} <img src="{{ product.image_url }}" class="card-img-top" alt="{{ product.name }}"> {% else %} <div class="text-center py-5 text-muted">暂无图片</div> {% endif %} <div class="card-body"> <h5 class="card-title">{{ product.name }}</h5> <p class="text-danger">{{ product.price_min }}-{{ product.price_max }} 元/斤</p> <span class="badge bg-success">{{ product.category }}</span> <span class="badge bg-info">{{ product.origin }}</span> </div> </div>

没有图片的产品一定要给占位符，否则整张卡片会变矮，页面看起来参差不齐。这个细节在演示现场很能体现专业度。我还给卡片整体加上了text-decoration: none，保证点击卡片任意位置都能进入详情页，而不是只能点标题链接。

5. 可视化看板与报表导出：让数据替运营者说话

5.1 可视化选型：为什么我选了ECharts而不是Matplotlib

两种方案我都试过。Matplotlib可以直接在服务端生成PNG图片塞进页面，但有两个问题：图片不支持交互，鼠标悬停看不到具体数值；每次数据更新都需要重新生成图片，缓存逻辑很麻烦。ECharts在浏览器端绘图，数据通过Flask的JSON接口下发，图表自带交互，刷新页面即是最新状态。

所以最终选型是：Flask提供JSON接口，前端引入ECharts渲染图表。这样还顺手把“图表数据接口”和“页面渲染”解耦了，后面如果要做大屏展示，直接复用接口就行。

5.2 三个核心图表：品类分布、产地排行、浏览量Top10

看板我做了三个图表，对应三个运营问题：

一是品类分布饼图，回答“我们平台上哪类农产品最多”，让运营者一眼看出品类结构是否失衡。二是产地数量柱状图，回答“哪些县区的产品录入最完整”，方便后续数据收集的方向。三是浏览量Top10横向条形图，回答“用户最关注什么”，这是推荐和内容运营的直接依据。

JSON接口示例：

from flask import jsonify @app.route("/api/stats/category") def stats_category(): rows = db.execute(""" SELECT category, COUNT(*) AS cnt FROM products GROUP BY category ORDER BY cnt DESC """).fetchall() return jsonify({ "categories": [r["category"] for r in rows], "counts": [r["cnt"] for r in rows] })

前端只需要一小段JS把数据喂给ECharts：

fetch('/api/stats/category') .then(res => res.json()) .then(data => { const chart = echarts.init(document.getElementById('categoryChart')); chart.setOption({ series: [{ type: 'pie', data: data.categories.map((name, i) => ({ name: name, value: data.counts[i] })) }] }); });

这里有个实用技巧：如果分类太多，饼图会挤成一团文字。我后来把占比低于5%的品类合并成“其他”，图面马上清爽很多。这个“合并小类”的逻辑可以放在SQL里用CASE WHEN做分组，也可以放在前端做归并，各有利弊，我选的是前端归并，因为接口返回原始分类，前端灵活调整展示方式更自由。

5.3 一键导出Excel：把数据还回运营者手中

看板解决“看”的问题，但运营者实际工作流里还是要用Excel做二次整理、发群、做汇总。所以我做了一个导出路由，把数据库全量导出为Excel文件：

from flask import send_file @app.route("/export") def export_products(): rows = db.execute("SELECT * FROM products").fetchall() df = pd.DataFrame([dict(r) for r in rows]) output_path = "static/export/陕西特色农产品清单.xlsx" df.to_excel(output_path, index=False) return send_file(output_path, as_attachment=True)

注意：send_file返回下载链接时，服务器端需要先生成文件。如果并发用户多，可以给文件名加时间戳避免冲突，比如陕西特色农产品清单_20251210.xlsx。我在这步还做了个小优化：导出前把view_count也导进去，这样运营者能直接看到每个产品的热度，不用再去后台查，省了一道工序。

5.4 图表与表格之外：一个很轻的“热度权重”逻辑

看板里的浏览量Top10除了展示，我还把它做成了一个运营配置项：运营者可以在后台设置“本周主推产品”，前端首页会把这个主推产品排在最前面，并打上“本周主推”的角标。这个功能虽然简单，但却是运营者最常用的功能，比任何推荐算法都能更直接地体现运营意志。

实现也不复杂，在products表里加一个is_featured字段，默认0，运营者手动置1的那个产品会在首页置顶。代码逻辑就是在首页查询里加一条排序规则：ORDER BY is_featured DESC, view_count DESC。成本极低，但演示时效果非常直观。

6. 部署、打包与六个实测踩坑记录

6.1 环境配置：vscode加虚拟环境，别再裸装包了

我遇到过不少朋友在自己的电脑上装了一堆Python包，结果项目一换电脑全部崩掉。这个项目我强烈建议第一步就在vscode里创建一个虚拟环境，然后所有依赖都从requirements.txt安装。配置好之后，在vscode里按Ctrl+Shift+P选择Python解释器，指向venv里的python。

pip install -r requirements.txt python app.py

如果启动时提示端口被占用，可以加一个PORT环境变量，或者在代码里改成app.run(host="0.0.0.0", port=8080)。演示的时候我习惯用5000之外的端口，一是避免和别的本地服务撞车，二是在局域网里给别人演示时，0.0.0.0监听能保证手机或另外一台电脑可以直接用主机IP访问。

6.2 中文编码三大坑

这个项目踩得最多的坑就是中文编码，前前后后遇到三种：

一是Windows控制台打印中文报UnicodeEncodeError。原因是Python在Windows下默认用gbk编码输出，而代码文件是utf-8。解决方法是启动前设置环境变量PYTHONIOENCODING=utf-8，或者在脚本开头加一句：

import sys sys.stdout.reconfigure(encoding="utf-8")

二是读取网页乱码。用resp.encoding = resp.apparent_encoding基本能解决，个别站点返回的apparent_encoding也不准，就手动指定gbk或utf-8试。

三是写入Excel后打开乱码。pandas的to_excel默认就是utf-8，一般不会有问题，但如果你用to_csv再让运营者用Excel打开，一定要加上encoding="utf-8-sig"，否则Excel会按本地编码解析，中文直接变乱码：

df.to_csv("products.csv", index=False, encoding="utf-8-sig")

这个坑非常隐蔽，因为csv文件在记事本里打开是正常的，双击用Excel打开就乱码，排查时很容易误以为pandas写坏了文件。

6.3 SQLite并发锁问题

项目跑起来后，有段时间一直报sqlite3.OperationalError: database is locked。查了半天发现是Flask的debug模式开了多线程，多个请求同时写数据库导致锁冲突。两个解决办法：一是在连接SQLite后立刻执行PRAGMA journal_mode=WAL，让读写可以并行；二是把数据库连接设置为check_same_thread=False，或者在每个请求里单独创建连接。我最后两者都用了，锁问题再没出现过。

conn = sqlite3.connect("data/products.db") conn.row_factory = sqlite3.Row conn.execute("PRAGMA journal_mode=WAL")

如果你要用更稳妥的方式，就在Flask的before_request里创建连接，在teardown_request里关闭连接。这样每个请求用的都是独立连接，从根源上避免跨线程共用连接的问题。

6.4 PyInstaller打包的资源和路径坑

项目最终要打包成Windows下可执行的exe，拿给没有Python环境的用户用。PyInstaller打包本身不难：

pip install pyinstaller pyinstaller -F -w -n 陕西农产品推介系统 app.py

但会有两个坑：

一是图标乱码或显示异常。exe名称用了中文后部分Windows版本显示会有问题，建议编译时加--icon指定图标文件，并把输出目录放到全英文路径下。

二是打包后找不到模板和静态文件。PyInstaller打包后程序运行在临时解包目录，直接用templates/xxx.html会报找不到。需要判断运行环境：

import sys, os if getattr(sys, "frozen", False): BASE_DIR = sys._MEIPASS else: BASE_DIR = os.path.dirname(os.path.abspath(__file__)) app = Flask(__name__, template_folder=os.path.join(BASE_DIR, "templates"), static_folder=os.path.join(BASE_DIR, "static"))

打包时再用--add-data "templates;templates" --add-data "static;static"把资源带进去。这些坑不提前处理，演示现场打不开模板页面真的会非常尴尬，我第一版exe就是在这个地方翻的车。

6.5 用waitress替代flask自带服务器

Flask自带的开发服务器在演示时如果开着debug模式，页面上出了错会直接显示调试信息，这在公开场合很掉链子。而且开发服务器性能一般，同一个房间十几个人同时访问就开始变慢。我在部署阶段换成了waitress，一个纯Python的WSGI服务器：

pip install waitress waitress-serve --host=0.0.0.0 --port=8080 app:app

waitress的好处是不需要额外编译、不依赖Windows服务，一行命令就能跑起来，足够应付几十人的演示场景。如果你需要后台常驻，可以用nssm把命令包装成Windows服务，但通常推介系统按需启动就行，不用常驻。

6.6 实测效果与后续迭代方向

系统在一个多月内从零到一完成，实际跑通后我自己最大的感受是：真正让这套系统有价值的，不是那几行推荐算法代码，而是前期的数据清洗和后期的数据看板。一个哪怕完全不懂算法的运营者，只要看到“浏览量Top10”就能很快知道该重点推哪些产品；一个采购商只要搜索“眉县 猕猴桃 礼盒”就能初步筛出一批候选，这比翻十张表格高效太多。

在几个合作社的实际使用反馈里，最打动我的一句话是：“原来别人想看咱的苹果，只能打电话问，现在发个链接就能看到照片和价格。”系统解决的不是什么高科技问题，而是最基础的可见性和可检索性问题。

后续的扩展方向我列了三个优先级：一是加一个用户反馈评分模块，让采购商对产品打分，积累真实行为数据后再考虑上更复杂的推荐；二是做一个小程序入口，因为合作社里真正高频使用的是手机而不是电脑；三是接一个价格日历，让季节性农产品在不同月份的行情变化趋势可以直观对比。这些方向都不算复杂，但都能让推介系统从“展示”走向“决策支持”。