基于PHP+小程序的手工艺品展销平台设计与实现

“文山手工艺品展销平台”这类题目，在毕设里属于非常典型的“小程序 + 后端接口 + 管理后台”三段式项目。市面上很多同学选它，不是因为简单，而是因为它的业务链路足够完整：用户端有登录、商品浏览、加购、下单，管理端有商品管理、订单处理、轮播图配置，一套下来基本把小程序电商该有的功能都覆盖了。再加上PHP这个老牌服务端语言，部署资料多、教材多、出问题好查，作为毕业设计确实稳妥。

本次拆解就以“基于php+小程序的文山手工艺品展销平台的设计与实现”为蓝本，从项目定位、数据库设计、接口实现、管理后台、部署上线到常见坑位，一层层讲清楚。内容不光是代码层面的“怎么做”，更会解释很多“为什么这么做”。对这个项目感兴趣的同学，或者已经在做类似商城小程序的，可以直接照着推进。

1. 先聊清楚：这项目到底在做什么

1.1 文山手工艺品的线上化难题

文山本地的手工艺品有个特点，品类多但分散。三七、刺绣、银器、扎染、手工纸，每种工艺背后都有对应的手艺人，但这些产品过去主要靠线下展销会、景区门店和熟人介绍销售，覆盖面有限。做一个展销平台，核心目的不是“炫技术”，而是解决两个问题：一是让外地用户能浏览到这些产品，打破地域限制；二是给手艺人一个低门槛的后台上架工具，让他们能自主维护商品信息。

所以你在设计系统时，脑子里一定要带着这个业务场景去思考。商品的展示维度不能只有简单的图文，还要考虑工艺简介、传承人信息、产地故事这些附加内容。这些在数据库设计阶段就要预留字段，否则后期再加，改表结构会非常痛苦。

1.2 php+小程序：毕设选题里的“黄金搭档”

为什么这个组合在毕设里这么流行？原因很现实。

小程序端解决了“用户入口”的问题。微信庞大的用户基数，不需要单独下载App，扫一扫就能打开，对评阅老师来说演示也方便。后端选PHP，尤其是ThinkPHP 3.2.3这种老牌框架，优点是学习曲线平缓、资料极其丰富，遇到问题几乎都能搜到现成的解决方案。

另外要说的一个点，这个项目的“完成度”往往比技术难度更重要。评阅老师看重的不是你用了多新的技术，而是整个系统的业务逻辑是不是完整闭环：用户能不能正常从浏览走到下单，管理员能不能在后台看到订单并处理。PHP在这方面的开发效率足够高，和小程序的交互通过JSON数据格式完成，边界清晰，很适合在有限时间里做出一套功能完整、能现场演示的系统。

2. 从需求到架构：系统设计思路拆解

2.1 角色划分与功能清单

拆解需求的第一步，一定要把角色和对应的功能边界划清楚。这个平台分两端：小程序前台和管理后台。前台用户的操作链路要短，核心是“看”和“买”；后台管理的操作链路要全，核心是“维护”和“处理”。

前台功能：

• 微信授权登录，获取用户基本信息
• 首页轮播图、分类入口、推荐商品位
• 商品列表，支持按分类筛选、关键词搜索
• 商品详情页，包含图片、价格、库存、工艺介绍
• 加入购物车、购物车列表、数量修改、删除
• 订单提交、订单列表、订单状态查看
• 个人中心，展示我的订单和基础信息

后台功能：

• 管理员登录、密码修改
• 分类管理，增删改查
• 商品管理，上架、下架、编辑库存和价格
• 订单管理，查看订单明细、修改订单状态、发货
• 轮播图管理，配置前台首页展示位
• 用户管理，查看注册用户列表

这些功能列表看起来很常规，但每一条背后都对应一段时间投入。我建议在动手写代码之前，先把这些功能项列成一张表，标注好优先级，避免开发中途不断加需求，最后哪个都没做好。

2.2 服务端分层：ThinkPHP 3.2.3下的MVC组织方式

ThinkPHP 3.2.3虽然是老框架，但对毕设来说完全够用。它的MVC分层机制，天然适合这个项目的代码组织方式。

我在控制器层推荐按业务模块拆分：

• IndexController：前台首页展示
• GoodsController：商品列表、详情
• CartController：购物车操作
• OrderController：订单提交、查询
• UserController：登录、用户信息
• AdminController：后台基础功能

模型层用ThinkPHP的Model类处理数据表交互，尽量别在控制器里直接拼SQL，否则代码维护起来很累。企业里最忌讳的就是控制器里塞一大坨数据库查询操作，毕设评阅老师看到也会减分。

视图层方面，后台管理可以用模板引擎输出页面，小程序端则完全走JSON接口。这里要注意，接口返回的数据格式必须统一。我习惯的格式是：

json复制{
    "code": 0,
    "msg": "success",
    "data": {}
}

code为0表示成功，非0表示业务异常。小程序端拿到这个结构后统一判断，不要每个接口各自定义一套返回格式，前后端联调的时候真的会疯。

3. 数据库设计：四类核心表背后的业务逻辑

3.1 商品表：卖的不是商品，是“故事”

商品表是整个系统的核心。我见过不少同学的初版设计，就是id、name、price、stock、image，五个字段就完了。这样做不是不行，但放在手工艺品这个场景里，很浪费。

我给商品表加这几个扩展字段：

• description：商品长描述，存富文本
• craft_intro：工艺介绍，手工艺品的核心卖点
• origin：产地信息
• artist：手艺人/传承人名字
• sales_count：虚拟销量，用于前台排序
• is_hot、is_recommend：推荐位标记

从业务价值上讲，手工艺品不是标准品，用户的购买决策很大程度取决于“这个东西背后的故事”。页面展示上如果只有一张图和价格，转化效果很差。从毕设的“设计”角度来说，这些字段的存在也体现了你对业务场景的思考深度。

商品分类表也很重要，建议用parent_id支持二级分类，因为文山手工艺品可能同时存在“按品类分”和“按工艺分”两套维度。比如一件刺绣摆件，既属于“刺绣”品类，也可能属于“装饰摆件”类目。

3.2 用户表与登录态设计

用户表字段相对固定：openid、nickname、avatar、phone、create_time。这里重点说openid。

微信小程序的用户体系很特殊，前端通过wx.login拿到临时code，后端用这个code调用微信接口换取openid和session_key。openid就是用户在你这套系统里的唯一标识，第一次登录时写入用户表，后续再登录就更新资料。

session_key这个字段要注意，它涉及用户信息的解密。如果小程序端需要获取用户手机号，需要把session_key传到后端去解密。不过毕设一般不做手机号授权，所以session_key在后端用完后可以丢弃，不需要存库。

登录态的保持，我用的是自定义token方案。用户首次登录后，服务端生成一个token字符串存到user_token表，同时存过期时间。小程序端把token存到storage里，每次请求接口时在header里带上。这个方案比session方案在小程序场景下更稳定，因为小程序的网络请求不依赖传统Cookie机制。

3.3 订单表与购物车表的主从关系

订单模块是最能体现“设计感”的地方，它涉及两张核心表：订单主表和订单明细表。

订单主表存的是订单整体信息，包含订单号、用户id、订单总金额、支付状态、物流状态、收货人、收货地址、联系电话、下单时间。订单明细表存的是当前订单下的商品快照，包含商品id、商品名称、商品图片、单价、数量、小计金额。

为什么要存“快照”？因为商品信息是允许修改的，比如管理员调整了价格，或者商品下架了。但用户已经下的单，订单内的商品名称和价格必须保持在下单那一刻的状态。如果订单明细表关联商品表实时取值，管理员改了价格，用户的历史订单也会跟着变，这在电商业务里是不允许的。

购物车表则简单一些：id、user_id、goods_id、goods_num、is_checked、create_time。不需要关联太多信息，购物车列表展示时再join商品表取商品信息即可。

4. 接口实现：小程序端与PHP后端的交互细节

4.1 微信登录的完整链路与常见失败点

小程序登录是很多新手第一个卡住的环节。完整的流程是：

前端调用wx.login获取临时code，把code传给后端PHP接口。后端发起HTTP请求到微信官方接口：

php复制https://api.weixin.qq.com/sns/jscode2session?appid=APPID&secret=SECRET&js_code=CODE&grant_type=authorization_code

请求成功后，微信返回openid、session_key，如果unionid存在也会一并返回。后端拿到openid后去用户表查询，不存在则创建新用户，存在则正常登录，最后生成token返回给前端。

这里有一个非常常见的失败现象：拿不到用户头像昵称。原因是微信在2021年左右调整了策略，直接通过wx.getUserInfo弹窗授权的方式被废弃了，现在必须通过“头像昵称填写能力”让用户主动填写，或者使用wx.getUserProfile。这算是平台策略变化导致的代码失效，如果同学们参考的老教程里还在用wx.getUserInfo，需要特别注意。

还有一个“小程序获取登录后的微信用户失败:wx1cb4398e1413dce7”这类报错。其实那一串就是你的AppID，出现这个报错通常意味着前端和后端的appid不一致，或者request合法域名没配置。解决方向就两个：核对AppID是否和微信公众平台一致，检查后端用来调jscode2session接口的appid是不是同一个。

4.2 商品列表的接口设计：一个接口解决“分类+搜索+分页”

商品列表接口我建议设计成“一个接口承载多个场景”，不要每个分类写一个接口。前端传参数来控制返回内容：

php复制public function getList() {
    $category_id = I('get.category_id', 0);
    $keyword = I('get.keyword', '');
    $page = I('get.page', 1);
    $size = I('get.size', 10);
    $where = array();
    if ($category_id) {
        $where['category_id'] = $category_id;
    }
    if ($keyword) {
        $where['goods_name'] = array('like', '%' . $keyword . '%');
    }
    $where['status'] = 1;
    $list = M('goods')->where($where)->page($page, $size)->select();
    $total = M('goods')->where($where)->count();
    // 统一返回结构
    $this->ajaxReturn(array('code' => 0, 'msg' => 'success', 'data' => array(
        'list' => $list,
        'total' => $total,
        'page' => $page,
        'hasMore' => $page * $size < $total
    )));
}

前端小程序用onReachBottom触发下一页加载，用switchTab或分类组件触发分类切换。这样的好处是前端代码干净，后端也只维护一个入口。

分页参数size建议设个上限，比如最大50，防止有人恶意拉取全量数据，把接口性能拖垮。这不属于毕设硬性要求，但提出来会让评阅老师觉得你有实际工程经验。

4.3 订单提交的幂等问题

订单提交这个接口要重点考虑“重复提交”问题。用户在详情页快速点击“立即购买”，或者小程序端网络卡顿导致请求重发，可能会出现一条订单被创建多次。

解决方案有两种。第一种是前端加防重复点击锁，在请求发出后到响应返回前，按钮置灰。第二种是后端做幂等处理，小程序端在提交订单时生成一个随机的requestId，后端收到请求先查这个requestId是否已存在，存在就直接返回已创建的订单信息，不存在才继续创建。

毕设场景下两种都做最稳妥。订单号生成规则建议用：日期 + 时间戳 + 随机数，避免并发下重复。

订单状态的流转节点是：待支付（默认） → 已支付 → 已发货 → 已完成。后台管理员发货后，小程序端订单列表要能看到物流状态。如果要做取消订单功能，还需要加一个“已取消”状态。状态字段建议用tinyint，0、1、2、3、4对应不同状态，不要用字符串，存储效率和查询速度都更好。

5. 后台管理端：一条龙服务里的“隐形大头”

5.1 后台框架与权限控制

后台管理我本身建议用ThinkPHP自带的模板引擎直接渲染页面，不要额外引入Vue框架。理由很简单：技术栈统一，你不必同时维护两套前端体系。用Bootstrap + jQuery写后台页面，开发速度快，浏览器兼容性也好。

管理员登录后的权限控制，做一个简单的session判断即可。在ThinkPHP的Controller构造函数或者公共控制器基类里加一段授权判断：

php复制public function _initialize() {
    if (!session('admin_id')) {
        $this->redirect('Login/index');
    }
}

所有后台控制器继承这个公共控制器，就天然实现了登录拦截。不需要上RBAC权限管理那一套，因为毕设场景下管理员通常就一个，权限体系做太重反而显得冗余。

5.2 图片管理与富文本的那个坑

后台商品管理里，图片上传是刚需。要涉及产品图片、详情页图片、轮播图。ThinkPHP 3.2.3自带Upload类，配置好上传目录和文件类型就能用。

这里提醒一个容易踩的坑：服务器目录权限。很多同学本地开发正常，部署到线上后图片上传失败，基本都是uploads目录的写权限没给对，改成755或777后问题解决。

富文本编辑器的选择上，我推荐用UEditor，虽然官方已停止维护，但功能齐全，和ThinkPHP搭配的案例多。要注意的是图片上传路径和实际访问路径的差异，编辑器的上传接口要配置好URL前缀，否则图片上传成功却显示不出来。

商品详情富文本里会有大量图片，小程序端展示时要用rich-text组件，这个组件支持的标签有限，样式也容易丢失。建议小程序端展示前对富文本内容做一次预处理，过滤掉不支持的标签，或者尽量在后台编辑时使用基础排版。

6. 部署上线与踩坑备忘

6.1 服务器环境与HTTPS

小程序部署有一个硬性约束：所有接口请求必须是HTTPS域名，并且这个域名要配置到小程序后台的request合法域名列表里。

环境搭配上，我推荐用Linux服务器 + Apache/Nginx + PHP 5.6或7.0 + MySQL 5.7。ThinkPHP 3.2.3在PHP 7.2以上的环境中会有Deprecated提示，虽然不影响运行，但错误日志会刷得很难看，调静态方法报Deprecated: Non-static method，处理起来也麻烦。为了图省心，PHP版本锁在7.0最佳。

HTTPS证书现在可以用免费的，比如Let's Encrypt，或者在服务商那里申请免费证书。小程序要求必须是HTTPS，不能用自签名证书，否则真机预览会报域名不合法。这一点务必提前准备，别等到最后部署了才着急。

6.2 小程序后台的几项隐藏配置

用过小程序的人都知道，代码写完只是第一步，小程序管理后台还有几项配置容易忽略。

第一项是“服务器域名”，必须是备案过的HTTPS域名。开发阶段可以在开发者工具里勾选“不校验合法域名”来调试，但体验版和正式版绕不开这个限制。

第二项是“业务域名”，涉及到在小程序里打开公众号文章。如果商品详情或活动页面需要在微信web-view组件里跳转公众号文章，必须配置业务域名，而且还要下载校验文件放到服务器根目录。这里就是“小程序无法打开公众号文章，需要配置什么”这个问题背后真正要做的操作：登录小程序后台，开发管理-开发设置-业务域名，填入提供校验文件并上传。

第三项是“类目”选择。展销平台建议选“电商平台”或“商家自营-百货/工艺品”，如果没有对应类目，提审时容易被打回。建议毕业设计作品以“演示”为主，类目选择尽量贴合实际经营范围。

6.3 代码讲解与文档：毕设答辩前的最后一道工序

很多同学只注重写代码，忽视了文档和讲解材料，结果答辩时连自己项目的架构图都画不清楚，这就非常不划算。一套完整的毕设交付，应该同时包含：

• 开题报告，说明项目背景和研究意义
• 需求分析文档，梳理功能模块和数据流程
• 数据库设计文档，包含ER图和字段说明表
• 系统截图，小程序端和后台页面的关键界面
• 答辩PPT，以流程图、功能清单、技术亮点为主

这里有个小技巧，数据库设计文档里的字段说明表，可以从小程序项目里直接导出，或者在数据库工具里导出Excel，效率比手写快得多。

在做代码讲解时，最忌讳的是从头到尾念代码。正确思路是：先讲清楚用户用这个平台做了什么，再按用户的操作路径串联起代码模块。比如用户从首页进入商品详情页，把它拆成小程序端的页面路由、前端请求、后端控制器、模型查询四个环节。评阅老师跟着这个思路走，会觉得你的逻辑很清晰。

7. 常见问题速查与避坑建议

实际上手写代码之前，花一天时间把数据库表结构梳理清楚，比盲目敲代码要划算得多。数据表之间的关联关系理清楚了，前端页面需要返回什么数据，后端接口怎么写，思路都会非常顺畅。

我个人在带这类项目时，通常建议按这个顺序推进：先搭数据库，再做后台管理端，再写小程序接口，最后联调。因为后台管理端的商品管理和订单管理，本质上就是对着数据库做增删改查，把这些页面做完了，数据库和数据流就自然熟悉了，后面写小程序接口的时候基本不会卡壳。

最后再分享一个小技巧，PHP文件里保留ThinkPHP框架版权注释“fast & simple oop php framework”这行字，平时没什么用，但在答辩时如果老师问起框架版本，你可以很自然地展示框架来源，显得你确实了解自己用的工具。项目做完后，可以尝试把后台的订单导出功能加上，用PHPExcel库把订单列表导出成Excel，这个功能虽然不属于核心需求，但特别容易出效果，演示时加分明显。