斗南鲜花商城业务系统：Vue3、Node.js、MySQL、Redis、Nginx、PM2 的全栈项目复盘

项目概览

斗南鲜花商城业务系统，是一个围绕云南昆明斗南鲜花交易场景搭建的全栈业务系统。它不是单纯的静态展示页，也不是只有几个页面的商城模板，而是从用户注册登录、商品浏览、分类筛选、购物车、订单创建、库存扣减、订单状态流转，到后台商品管理、用户管理、订单查询、库存维护、客服会话和 DeepSeek 智能客服配置，都尽量按一个完整业务系统的方式去组织。

这个项目使用 Vue3、Element Plus、Node.js、Express、MySQL、Redis、Nginx、PM2 完成前后端开发和服务器部署。前端负责商城页面、购物流程、后台管理和在线客服交互；后端负责接口、鉴权、业务规则、数据库读写和 AI 客服调用；MySQL 保存商品、用户、订单、订单明细、库存和客服会话；Redis 作为可选缓存；Nginx 负责静态资源托管和接口反向代理；PM2 负责 Node.js 后端进程守护。

从项目定位上看，它更接近一个“可讲业务链路的全栈作品”，而不是只展示技术名词。鲜花交易有几个很典型的业务特点：商品批次变化快、库存需要及时同步、价格和规格要清楚、用户下单后不能出现库存不一致、后台要能快速查订单和库存、客服要能承接用户咨询。这些特点决定了系统不能只做一个好看的首页，还要把数据表、接口、状态、库存和部署都串起来。

为什么选择斗南鲜花这个场景

斗南是国内非常有代表性的鲜花交易市场。鲜花和普通商品不同，生命周期短，库存变化快，采购和配送时间敏感，用户往往会关心“今天有没有货”“适合送什么花”“什么时候能配送”“订单是否已经处理”。这些问题本身就很适合做成一个商城业务系统。

如果只是做一个普通商城，很多页面可以套模板，商品也可以随便写几条。但鲜花商城更容易体现业务理解：商品分类不仅是“商品类型”，还可以对应玫瑰、百合、康乃馨、配草配叶、永生花、节日专区等业务分类；商品详情不仅要显示图片和价格，还要体现产地、等级、单位、库存；订单状态不仅是“下单成功”，还要有待支付、已支付、已发货、已完成、已取消这些状态；库存也不能只显示一个数字，还要考虑下单扣减、取消回补和后台调整。

这个项目在设计时，就把重点放在“商城主流程能否闭环”上。用户可以注册并填写手机号，登录后浏览商品、加入购物车、提交订单；后台可以查看订单、处理库存、管理商品和用户；客服模块可以先由 DeepSeek 回复，失败或需要人工处理时再转人工客服。这样一来，项目既能展示前端页面能力，也能展示后端业务建模和部署运维能力。

技术栈选择

前端使用 Vue3 和 Element Plus。Vue3 的组合式 API 适合拆分页面状态和业务逻辑，Element Plus 提供了表格、表单、按钮、抽屉、标签、分页、弹窗、输入框等常用组件，可以快速做出后台管理和商城交互。页面风格上，商城前台走粉色、鲜花、可爱、柔和的视觉方向；后台管理则尽量保持清晰、可扫描、可操作。

后端使用 Node.js 和 Express。Express 足够轻量，适合快速搭建 REST API，也方便和 MySQL、Redis、JWT、DeepSeek 接口组合。后端没有把所有逻辑都塞在路由里，而是对订单服务、鉴权中间件、数据库连接、缓存配置、错误处理做了基础拆分。这样项目虽然不算特别大，但结构不会太乱。

数据库使用 MySQL。商城类项目天然适合关系型数据库，因为用户、商品、分类、订单、订单明细、库存之间关系明确。订单主表和订单明细表需要事务保证一致性，库存扣减也需要在数据库层面谨慎处理。MySQL 在这个项目里承担了核心业务数据存储。

Redis 在系统里作为可选缓存。开发和部署过程中也考虑到 Redis 可能没有启动或者服务器环境暂时不可用，所以后端做了降级处理：Redis 不可用时不影响主流程，商品、订单、登录、客服仍然能正常工作。这一点在实际部署里很重要，因为缓存应该提高性能，而不应该成为系统启动的硬依赖。

部署层面使用 Nginx 和 PM2。前端构建后由 Nginx 提供静态资源服务，/api/ 请求反向代理到 Node.js 后端。Node.js 后端由 PM2 守护，支持后台运行、日志查看、进程重启和开机自启。服务器最终通过 http://82.157.64.38:5001 提供访问。

系统功能模块

系统主要分为前台商城、普通用户、后台管理、在线客服和部署运维五部分。

前台商城包括首页、分类、商品列表、商品详情、购物车、订单提交、订单查看、搜索、导航、底部备案信息等。首页使用鲜花背景图，顶部有 Logo、导航、搜索、购物车、登录入口；右侧或移动端底部有新品推荐、优惠活动、花艺课堂、在线客服等快捷入口。商品区支持分类筛选和关键词搜索，商品卡片展示图片、名称、产地、分类、价格、库存和加入购物车按钮。

普通用户模块包括注册、登录、手机号填写、JWT 登录态、购物车和订单。注册时要求填写电话号码，这样更贴近真实商城场景。登录后用户可以把商品加入购物车，提交订单时填写收货人、手机号和地址。后端通过 JWT 鉴权识别当前用户，避免用户越权查看别人的订单。

后台管理模块使用 Vue3 页面实现，包含订单管理、库存管理、客服管理、DeepSeek 配置、商品管理、用户管理等。管理员可以查看订单总数、库存预警、库存品项和客服会话。订单管理支持按状态和关键词查询；库存管理支持查看库存、锁定库存和预警库存；客服管理支持查看用户会话和人工回复；DeepSeek 配置支持设置 API Key、Base URL、模型，并进行连接测试。

在线客服模块是这个项目后期重点完善的部分。用户打开客服后，默认先由 DeepSeek 智能客服回复。AI 不可用、超时或需要人工处理时，系统可以转接人工客服。后台管理员可以看到客服会话，并发送人工回复。前端还做了“正在回复”的状态、打字机效果和发送锁定，避免用户在 AI 慢回复时连续发送很多条导致体验混乱。

部署运维部分包括本地 D 盘环境、服务器部署、Nginx 配置、PM2 启动、MySQL 初始化、Redis 降级、GitHub 推送、安卓 APK 打包等。项目不仅在本地跑通，也部署到了云服务器，并生成了 Android 调试版安装包。

前端页面设计

前端最开始不是只做后台，而是先把商城的第一屏做出来。首页参考了鲜花商城的柔和插画风格，整体以粉色、白色、浅色阴影为主。顶部导航有首页、鲜花分类、永生花、花礼套装、节日专区、关于我们、后台管理等入口；右侧有搜索框、购物车按钮和登录注册按钮。

首页最重要的是第一眼能看出这是鲜花商城，所以 Logo、鲜花背景、主标题和按钮都放在第一屏。主标题“把斗南的清晨，送到每一次心动里”用来表达鲜花配送的情绪价值，下面补充说明系统支持在线下单、库存同步和订单追踪。按钮包括立即选花、注册会员和查看购物车。

商品区域使用卡片式布局。每张卡片包含商品图片、等级标签、商品名、产地、分类、价格、描述、库存进度条、购买数量、加入购物车和详情按钮。对于鲜花商品来说，图片非常重要，所以卡片顶部用大图展示。库存进度条能让用户直观看到库存状态，也方便后台演示库存管理。

商品详情页展示更完整的信息，包括商品图片、分类标签、名称、描述、产地、等级、库存、价格、数量选择和加入购物车。详情页不是单独存在，而是和商品列表、购物车、订单连起来，用户可以从列表点进详情，也可以直接加入购物车。

登录注册页则分成视觉区和表单区。视觉区沿用鲜花背景，突出“鲜花传情，爱在身边”；表单区支持登录和注册切换。注册表单包含账号、昵称、手机号和密码。系统同时保留了演示账号：管理员 admin / admin123，买家 buyer / buyer123。

移动端适配

因为用户明确要求系统适配安卓、苹果等移动端浏览器，所以项目对移动端做了专门处理。移动端不是简单缩放桌面页面，而是针对顶部导航、首页背景、快捷入口、商品卡片、详情页、登录页和客服抽屉做了多档断点。

在 900px 以下，顶部栏会自动换行，导航变成横向滚动，不再挤压按钮。Logo 缩小，搜索框宽度收缩，购物车和登录按钮保持可点击。对于平板或横屏手机，这种布局可以让导航完整保留，又不会占用过多空间。

在 760px 以下，页面进入手机布局。主内容去掉多余外边距，首页 Hero 区域调整高度和文字大小，按钮变小并自动换行。右侧快捷栏改成底部四宫格，固定在屏幕底部，并适配 iPhone 的安全区。这样用户在手机上可以随时点新品推荐、优惠活动、花艺课堂和在线客服。

商品列表在较窄屏幕下会变成两列，再到更小的 520px 以下变成单列。这样安卓大屏手机可以保持较高的信息密度，小屏 iPhone 不会出现卡片过窄和文字挤压。商品卡片里的数量选择和按钮也会变成整行或两列布局，避免“加入购物车”和“详情”按钮挤在一起。

客服抽屉在移动端限制为 min(100vw, 420px)，避免 380px 固定宽度在小屏上溢出。客服悬浮按钮也会避开底部快捷栏，防止两个固定元素重叠。这个细节对手机体验很重要，因为悬浮按钮、底部导航、浏览器地址栏和安全区经常会互相挤压。

移动端适配完成后，系统在安卓和 iPhone 浏览器上都能保持基本可用：顶部能导航，首页能看，商品能选，购物车能加，客服能打开，底部不遮挡主要操作。

后端接口设计

后端接口按模块拆分，包括认证、商品、购物车、订单、后台管理和客服。所有需要登录的接口都通过 JWT 鉴权中间件识别用户身份，后台接口再额外判断用户角色是否为管理员。

认证接口包括注册、登录和当前用户信息。注册时后端校验账号、密码、昵称和手机号，保存用户信息；登录时校验账号密码，返回 JWT token 和用户信息。项目里为了演示方便，初始数据使用 plain:admin123 和 plain:buyer123 这种简单密码格式，真实项目中应该统一使用 bcrypt 哈希。

商品接口包括分类列表、商品列表、商品详情。商品列表支持分类和关键词筛选，返回商品基础信息、分类名、库存、锁定库存和预警库存。商品详情返回单个商品的完整信息。商品接口会尝试使用 Redis 缓存，但 Redis 不可用时自动降级为直接查数据库。

购物车接口负责添加商品、查看购物车、更新数量、删除商品。购物车表里通过 user_id + product_id 唯一约束避免同一个用户重复添加同一个商品时产生多行数据。用户再次添加同一商品时，可以合并数量。

订单接口是后端的核心。创建订单时，需要从购物车或请求数据里读取商品，检查库存是否足够，计算总金额，插入订单主表和订单明细表，并扣减库存。这个过程必须放在事务里，否则可能出现订单创建成功但库存没扣，或者库存扣了但订单没创建的错误。

后台接口包括订单查询、库存查询、商品管理、用户管理、客服会话、DeepSeek 设置等。后台订单查询通过 SQL 联表获取订单、用户和商品明细；库存管理通过商品和库存表联查；客服管理通过客服会话表和消息表查询用户对话。

数据库设计

数据库是这个项目的业务核心。主要表包括 users、categories、products、inventory、inventory_logs、carts、orders、order_items、chat_sessions、chat_messages、system_settings。

users 表保存用户账号、密码、昵称、手机号和角色。角色分为买家和管理员。普通用户注册后默认是买家，管理员账号由初始化数据创建。手机号字段用于满足注册和商城联系需求。

categories 表保存鲜花分类。示例数据包括玫瑰、百合、康乃馨、配草配叶。分类表和商品表是一对多关系，一个分类下可以有多个商品。

products 表保存商品信息，包括分类、名称、封面图、产地、等级、单位、价格、状态、描述、创建时间和更新时间。鲜花商品比较关注产地、等级和单位，所以这些字段没有省略。状态字段用于支持商品上架和下架。

inventory 表用 product_id 作为主键，保存库存、锁定库存和预警库存。库存不直接放在商品表里，是为了让商品基础信息和库存管理分离。库存表还可以扩展批次、仓库、损耗等字段。

inventory_logs 表保存库存变更日志，包括商品、变更类型、数量、变更前库存、变更后库存、关联订单号和备注。这个表非常适合排查“库存为什么变了”。比如订单扣减、订单取消回补、后台手动调整，都可以记录一条日志。

orders 是订单主表，保存订单号、用户、总金额、状态、收货人、电话、地址、备注和各状态时间。order_items 是订单明细表，保存订单里的商品、购买价格、数量和小计。订单主表和明细表分开后，后台查询订单时可以同时看到订单整体状态和商品明细。

chat_sessions 和 chat_messages 用于在线客服。一个用户可以有一个未关闭会话，会话状态可以是 AI、人工或关闭。消息表记录用户、AI、人工客服和系统消息。这样后台可以回看完整对话，也能区分消息来源。

system_settings 保存系统配置，当前主要用于 DeepSeek API Key、Base URL 和模型配置。把配置放进数据库后，管理员可以在后台修改 Key，而不需要每次改服务器环境变量。

订单与库存流转

订单和库存是商城系统最容易出问题的地方。这个项目里，订单创建不是简单插一条订单记录，而是要完成一组动作：检查商品是否存在，检查库存是否足够，计算价格，创建订单主表，创建订单明细，扣减库存，记录库存日志，清理购物车。

如果这些动作分开执行，一旦中间某一步失败，就可能造成数据不一致。例如订单插入成功了，但库存扣减失败，后台会看到订单存在，但库存仍然没变；或者库存扣减成功了，但订单明细插入失败，用户看不到订单，库存却少了。这些问题在真实项目里非常麻烦。

所以订单创建需要使用数据库事务。事务开始后，后端先锁定或查询库存，再执行订单和库存相关操作。如果任何一步出错，就回滚事务；全部成功后再提交。这样能保证订单和库存要么一起成功，要么一起失败。

订单取消时也要考虑库存回补。如果用户取消待支付订单，系统应该把已扣减的库存加回来，并记录库存日志。否则库存会越扣越少，后台很难解释为什么有货却显示缺货。项目里通过库存日志可以追踪每次扣减和回补。

后台库存查询不仅看当前库存，还要看预警库存。比如某个商品库存低于预警值，后台可以提示运营人员补货。对鲜花业务来说，库存预警比普通商品更重要，因为鲜花采购和配送时间敏感，等用户下单才发现缺货就太晚了。

后台管理设计

后台管理不是另起一个独立项目，而是在同一个 Vue 应用里通过路由区分。管理员登录后可以进入后台管理页面。后台顶部仍然保持商城风格，但内容区更偏工作台。

后台首页展示几个指标卡片：订单总数、库存预警、库存品项、客服会话。指标卡片可以让管理员快速知道当前系统状态。下面通过标签页切换订单管理、库存管理、客服管理、DeepSeek 配置、商品管理、用户管理等功能。

订单管理支持按状态、订单号、用户、商品进行查询。表格显示订单号、用户、商品明细、金额、状态和操作。状态标签用不同颜色区分，方便快速扫描。后续可以继续扩展发货、完成、取消等操作按钮。

库存管理展示商品库存、锁定库存和预警库存，可以进行库存调整。库存调整不是直接改一个数字那么简单，最好配合库存日志记录调整原因。这样后续排查库存差异时，可以知道是订单扣减、取消回补还是人工调整。

商品管理和用户管理用于补足后台完整性。商品管理可以新增、编辑、上下架商品；用户管理可以查看注册用户、手机号、角色和创建时间。这些功能让系统更像一个业务后台，而不是只有前台页面。

客服管理展示用户会话和消息记录。人工客服可以选择会话，查看用户历史消息，并发送回复。这个功能和前台客服抽屉配合，就形成了一个简化版客服系统。

DeepSeek 智能客服

客服模块最开始的目标是让用户能点开在线客服，并由 AI 先回复。后来根据使用体验，又补了几个关键点：管理员可以在后台换 Key，AI 不可用时转人工，AI 回复慢时前端不能一直报错，正在回复时不能继续发送，回复出现时要有打字机效果。

后端通过 OpenAI 兼容格式调用 DeepSeek 或第三方兼容服务。配置项包括 Base URL、模型和 API Key。接口路径一般是 /chat/completions，请求体包含 system prompt 和用户消息。system prompt 会告诉模型：你是斗斗鲜花商城客服，回答要简短温柔，可以帮助用户选花、查询下单流程、说明库存与配送，无法处理售后或人工操作时引导转人工。

一开始遇到的问题是 AI 回复慢时，前端 axios 10 秒超时，用户界面会弹出错误。但实际上后端可能还在等待 AI 返回，或者第三方接口只是慢。这种体验会让用户误以为系统坏了。后来把前端超时提高到 90 秒，后端 DeepSeek 请求设置 75 秒超时。这样大多数慢回复能正常等待，真正超时才走降级。

前端在发送消息后，会立即把用户消息显示到聊天框，同时显示“正在回复...”。这时输入框、发送按钮、转人工按钮和 DeepSeek 接管按钮都会禁用，避免用户连续发很多条。如果 AI 返回成功，系统用打字机效果逐字显示回复；如果 AI 超时或失败，则显示系统提示，并把会话转为人工。

后台管理员可以把人工会话重新切回 AI。这个设计比较实用，因为有时候只是 Key 没配置好或接口临时不可用，修复后不应该让会话永远停在人工状态。

部署过程

项目本地部署在 D 盘，代码目录为 D:\github\dounan-flower-mall。本地环境包括 Node.js、MySQL、Redis、Nginx、PM2、Git、Android SDK 和 JDK。前端使用 Vite 构建，后端使用 Express 启动。

服务器部署在 82.157.64.38，访问端口是 5001。Nginx 配置监听 5001，静态资源目录指向 /opt/dounan-flower-mall/frontend/dist，接口 /api/ 反向代理到 127.0.0.1:3000/api/。Node.js 后端由 PM2 启动，进程名为 dounan-api。

部署时先把前端构建产物上传到服务器，再安装后端依赖，配置 .env，创建数据库，导入 schema.sql 和 seed.sql。MySQL 数据库名为 dounan_flower_mall，应用用户为 dounan_app。数据库初始化时创建用户、分类、商品、库存和系统配置。

PM2 用于进程守护。启动后执行 pm2 save 保存进程列表，并配置开机自启。这样服务器重启后，后端服务可以自动恢复。Nginx 则通过 nginx -t 检查配置，再 reload 生效。

部署过程中还遇到 Redis 不可用的问题。Redis 服务启动失败时，后端日志会刷连接错误。后来把 Redis 设计成可选缓存，通过 REDIS_DISABLED=1 和错误监听避免缓存服务影响主流程。这是一次很典型的部署经验：辅助组件应该可降级，不能让整个系统因为缓存失败而不可用。

GitHub 与版本管理

项目最终推送到了 GitHub：https://github.com/yhdxtn/dounan-flower-mall。一开始 GitHub CLI 登录遇到 device code 和网络超时问题，后来改用 SSH key 解决推送认证。先在本机生成 SSH 公钥，添加到 GitHub 的 SSH keys，再把远程地址设置为 git@github.com:yhdxtn/dounan-flower-mall.git，最后推送 master 分支。

版本管理过程中也注意了不要把 .env、node_modules、构建产物和 APK 文件提交到仓库。.gitignore 里排除了这些内容，避免泄露数据库密码、API Key 或产生超大的仓库。

项目提交记录也能反映迭代过程：初始系统提交、Redis 降级处理、数据库初始化脚本修复、AI 客服等待体验优化、移动端浏览器适配。每次提交都对应一个实际问题，而不是为了提交而提交。

安卓 APK

除了网页端，项目还使用 Capacitor 生成了 Android 调试版 APK。APK 的 WebView 指向服务器地址 http://82.157.64.38:5001，并配置了 cleartext 允许 HTTP 访问。Android 开发环境安装在 D 盘，包括 Android SDK、JDK 21 和 Gradle 缓存。

APK 构建过程里遇到过 JDK 版本要求问题，Capacitor Android 需要更高版本的 Java，所以安装了 JDK 21。Gradle 下载也做了本地缓存配置，避免每次构建都从网络下载。

生成的 APK 可以安装到安卓手机上测试商城页面。因为它本质上加载服务器 Web 页面，所以服务器更新后，APK 打开看到的也是线上最新版本。这种方式适合快速做一个演示版移动端，不需要单独写原生 Android 页面。

遇到的问题和解决

第一个问题是中文乱码。开发过程中有些文件在 Windows 终端里显示乱码，但浏览器页面显示正常。这个问题和终端编码、文件编码、数据库字符集都有关系。最终数据库统一使用 utf8mb4，SQL 初始化脚本也改成 utf8mb4_unicode_ci，避免导入时中文出错。

第二个问题是 MySQL 权限。服务器上 MariaDB/MySQL 端口和账号配置不一致，后端一开始报 Access denied for user 'dounan_app'@'localhost'。最后通过重置 root 密码、创建 dounan_app 用户、授权 dounan_flower_mall 数据库并导入表结构解决。这个问题说明部署时不能只看服务是否启动，还要确认端口、账号、权限和数据库是否匹配。

第三个问题是 Redis。Redis 没有正常启动时，后端虽然主流程依赖 MySQL，但 Redis 客户端仍然不断报错。后来把 Redis 改成可选缓存，监听错误并支持禁用，让系统在没有 Redis 的情况下仍然能跑。

第四个问题是 AI 回复慢。前端默认 10 秒超时太短，AI 还没返回，用户就看到错误。后来前端提高超时时间，后端加 AbortController，前端加正在回复状态和发送锁定，整体体验明显好很多。

第五个问题是移动端布局。桌面端首页好看，不代表手机上好用。移动端会遇到导航挤压、底部悬浮按钮遮挡、商品卡片过窄、客服抽屉溢出等问题。通过多档媒体查询和安全区处理，系统在安卓和 iPhone 浏览器上更稳定。

项目收获

这个项目最大的收获不是某个页面或某个接口，而是把一个商城系统从“能看”做到“能跑”，再做到“能部署、能讲清楚”。很多项目停留在前端页面，或者只有后端接口，但真正完整的业务系统需要前后端、数据库、部署、日志和运维一起考虑。

从前端角度，学到的是页面不能只追求第一眼好看，还要考虑用户路径。首页要能引导选花，商品卡片要能快速决策，详情页要能补充信息，购物车和订单要清楚，客服入口要随时可用，手机端不能遮挡核心按钮。

从后端角度，学到的是业务状态和数据一致性。订单、库存、购物车、用户、客服会话都不是孤立的表。下单时库存要扣，取消时库存要回补，后台查询要能联表，客服消息要能追踪，会话状态要能切换。

从部署角度，学到的是线上环境永远会有差异。本地能跑不代表服务器能跑，服务器端口、数据库密码、Nginx 配置、PM2 进程、Redis 状态、系统服务权限都可能出问题。部署不是最后一步，而是项目能否真正交付的一部分。

从作品展示角度，这个项目适合写进简历或博客，因为它有明确业务背景、完整技术栈、可访问地址、GitHub 仓库、截图、后台管理和部署说明。相比只写“Vue + Node 商城”，把订单库存、客服 AI、移动端适配、部署踩坑讲清楚，更能体现实际项目能力。

后续可以继续完善

后续如果继续扩展，可以加入支付模拟、物流单号、订单导出、商品批量导入、图片上传、更多库存日志、管理员操作日志、短信验证码、用户地址簿、优惠券和节日活动。对于客服模块，可以继续增加流式输出，让 AI 回复不是等完整结果后再打字，而是真正边生成边显示。

移动端也可以继续做 PWA，让用户在手机浏览器里添加到桌面。APK 可以进一步打正式签名包，配置应用图标、启动页和版本号。部署方面可以加入 Docker Compose，把 MySQL、Redis、后端和 Nginx 都放进统一编排，方便迁移服务器。

如果要做成更接近真实商业系统，还需要补充权限细分、接口限流、日志审计、异常告警、备份恢复和安全加固。比如后台管理不能所有管理员都拥有同样权限；API Key 不能明文展示；订单和库存操作要有操作记录；数据库要定期备份。

总结

斗南鲜花商城业务系统是一个围绕真实业务场景组织的全栈项目。它用 Vue3 和 Element Plus 完成前端商城与后台管理，用 Node.js 和 Express 提供接口，用 MySQL 保存业务数据，用 Redis 做可选缓存，用 Nginx 和 PM2 完成部署，并额外接入 DeepSeek 智能客服和 Android APK。

这个项目从商品、分类、用户、购物车、订单、订单明细、库存、库存日志、客服会话、系统配置等多个角度，把一个商城系统的基本骨架搭了出来。它也经历了真实部署中常见的问题：数据库权限、端口配置、Redis 不可用、AI 超时、移动端适配、GitHub 推送认证。正因为这些问题被解决过，项目才不只是一个演示页面，而是一段完整的工程实践。

后面再回看这个项目，我觉得最值得保留的是这条思路：先让主流程闭环，再补后台管理；先保证数据一致，再优化页面体验；先部署上线，再整理日志和回滚方式；先让 AI 能用，再处理慢回复和人工兜底。技术栈会变，但这种做业务系统的顺序很长时间都不会过时。