高校实验室管理系统：ThinkPHP+Laravel双后端与微信小程序实战

高校实验室管理系统：ThinkPHP + Laravel 双后端 + 微信小程序实战复盘

前阵子接了一个高校实验室管理系统的项目，标题很直白：Thinkphp和Laravel框架微信小程序的高校实验室管理系统设计与实现。项目规模不大不小，但很有代表性——后端要同时兼容两套PHP框架，前端落点又是微信小程序，学生、教师、管理员三端各有一套交互逻辑。做完之后我最大的感受是：这种“管理后台 + 小程序端”的组合，在校园信息化场景里会越来越多，而PHP老将和新秀同台的情况，也远比想象中普遍。

这篇文章我不会只贴代码，而是把整个项目的设计思路、选型逻辑、核心接口实现、踩坑记录全部摆出来。内容主要面向两类人：一是准备做毕业设计或课程设计的同学，二是想把实验室预约、设备管理这类业务快速落地的PHP开发者。如果你对ThinkPHP或Laravel已经有点基础，那这篇文章里的很多坑和经验，能帮你少走不少弯路。

1. 项目到底要解决什么问题

1.1 高校实验室管理的真实痛点

别看“实验室管理”这五个字简单，真正去调研一下就知道，里面的需求链路非常长。我前期去两所高校的信息中心聊过，也找实验室管理员和带课老师做过需求收集，整理下来痛点其实是这么几类：

预约靠人肉登记。很多实验室到现在还是微信群接龙或者纸质登记表，学生约实验课、做毕设实验，全靠自觉填表。老师想查“这个时间段有多少人约了设备”，得自己去翻群消息，效率极低。

设备使用情况不透明。实验设备谁在用、什么时候归还、有没有损坏，管理员基本靠巡检。大型设备（比如贵重的分析仪器）有人约了不用，或者用了不还，都没法及时发现。

安全管理与审批流缺失。有些实验室涉及化学品、高价值设备，使用前必须经过指导教师审批。但线下审批流程繁琐，学生嫌麻烦，老师也没精力盯，最后审批往往形同虚设。

通知和消息传递滞后。设备维护、课程调整、实验室开放时间变更，管理员只能张贴公告，学生和老师很难第一时间收到。

所以这个系统要解决的，本质上不是“能不能记录数据”，而是把实验室的场地、设备、耗材、审批、消息这些要素串成一个数字化的闭环。学生端用微信小程序，因为学生零安装成本、登录方便；管理端用Web后台，因为管理员要处理的数据量大、操作复杂。

1.2 为什么一套系统要同时用ThinkPHP和Laravel

很多人在看到项目标题第一反应是：ThinkPHP和Laravel，二选一不就完了吗？为什么两个都用？这个问题，我接下来说清楚。

先说实际场景。当时甲方给出的“硬性偏好”是：现有的一台服务器上跑着一个基于ThinkPHP 5.1的老系统，是实验室门禁预约模块，不能推翻重来；而新的设备管理、耗材管理、审批流模块，甲方的技术负责人更希望用Laravel，理由是后续可能交给第三方团队维护，而Laravel的Composer生态和目录规范更适合团队协作。

也就是说，这并非炫技，而是技术债务和新需求的折中方案——老模块继续用ThinkPHP，新模块用Laravel，中间通过统一的API网关和数据库让两边协同。这个思路在真实项目里非常常见，尤其在高校信息化场景中，一套系统往往要兼容历史遗留系统和新的技术栈。

从技术角度讲，两个框架各有不可替代的优势。ThinkPHP的优点是中文文档全、上手快、部署简单，小团队维护时效率非常可观；Laravel的优点是设计优雅、Eloquent ORM 好用、中间件和队列生态成熟，面对复杂业务逻辑时代码组织更清晰。你可以理解成一个是“皮实耐用的皮卡”，适合拉货跑糙路；另一个是“底盘扎实的轿车”，适合长途高速巡航。

我的实际做法是：ThinkPHP负责“门禁预约 + 实验室档案”这类相对独立的模块，Laravel负责“审批流 + 设备管理 + 耗材 + 消息通知”这类需要多表联动、状态流转的业务。两边共用同一个MySQL数据库和同一套微信小程序API入口，通过独立部署、接口路由区分来降低耦合。

2. 系统架构与核心功能设计

2.1 整体架构与数据库设计

整个系统的架构我画了个大概分层，不是严格的微服务，而是“一个入口、两个后端、三类终端”。

• 终端层：微信小程序（学生/教师）、Web管理后台（实验室管理员/院系领导）
• 接入层：统一的HTTPS API网关，按前缀区分路由（/tp走ThinkPHP，/lar走Laravel）
• 业务层：预约服务、门禁对接、审批流、设备状态机、耗材库存、消息推送
• 数据层：MySQL（业务核心）、Redis（缓存和分布式锁）、文件存储（实验报告、设备图片）

数据库设计是整个项目的奠基工作，我梳理了十来张核心表，其中这几张是关键中的关键：

实验室表（lab）：实验室名称、位置、可容纳人数、开放时间段、状态（开放/维护/关闭）。这张表是门禁和预约的基底，其他表几乎都要关联它。

设备表（device）：设备编号、名称、分类、所属实验室、状态（空闲/使用中/维修中/报废）、借出限制条件。这里有分类设计，比如“普通设备”无需审批、“贵重设备”强制审批。

预约单表（reservation）：预约人ID、实验室ID、设备ID、时间段（开始时间、结束时间）、用途说明、状态（待审批/已通过/已拒绝/已取消/已完成/超时未到）。状态流转是整个系统最复杂的部分。

审批记录表（approval_record）：记录每一步审批的节点、审批人、意见和动作，形成审批流闭环。

耗材表（consumable）：耗材编码、名称、安全库存阈值、当前库存、领用记录ID。低库存自动触发提醒。

用户表（user）：设计成了统一账户模型，通过role区分学生、教师、实验室管理员、系统管理员。小程序端登录后拿到user_id和role，后端在每个接口里做权限校验。

设计的时候特别注意了两个数据一致性的点。第一，预约和设备的关联是“一对多”还是“多对多”——真实业务里一个预约可以申请多台设备，而且每台设备的使用时间段可以不一样，所以我拆了reservation_device中间表，避免在预约单表里塞冗余的JSON。第二，所有表都加了created_at、updated_at和软删除字段，方便后面做统计和溯源。

2.2 小程序端的核心模块要怎么拆

小程序端面向的角色主要是学生和教师，以学生使用为主。我把页面拆成了五个Tab：首页、预约、扫码、消息、我的。

首页：展示实验室公告、今日可用实验室和设备数量、待办审批红点提醒。这里的核心难点是接口聚合——一次请求同时返回公告、统计、待办三个数据块。我最初的接口设计是三个独立请求，后来发现小程序端启动时并发请求太多，调试很麻烦，就改成了聚合接口/home/index，返回一个嵌套JSON。这个改动对体感提升非常明显。

预约模块：这是整个小程序端功能最重的页面。流程是：先选实验室 → 再选时间段 → 勾选设备 → 填写实验用途 → 提交预约。如果是贵重设备，提交后进入“待审批”状态；普通设备则直接“已通过”，生成门禁临时码。这里涉及时间段冲突检测，下面实现部分会细讲。

扫码模块：调用小程序端的扫码API，扫实验室门口的二维码，上报设备或者签到。扫码之后要做什么动作，我在后端设计了几种“动作枚举值”：checkin（签到）、checkout（离开）、device_report（设备报修）、borrow_device（现场借设备）。一个二维码承载多个动作，好处是管理员不用打印很多张不同功能的码。

消息模块：订阅消息和站内信结合。站内信存储于数据库，订阅消息用于实时触达。学生在预约状态变更、设备维护提醒、低耗材通知时会收到通知。不要把这两者混一起，站内信是兜底，订阅消息是增强。

我的模块：个人中心，展示我的预约记录、我的审批记录（教师角色）、我的设备借用历史、个人资料编辑。

2.3 管理后台的核心功能怎么拆

管理后台是给实验室管理员用的，功能比小程序端重得多。我没有用Vue或React重新开发一个单页应用，而是采用了Laravel + Blade + 少量Vue组件的方案。为什么这么做？因为管理后台要做30多个页面，如果全是前后端分离，工作量会翻一倍；而Blade服务端渲染在处理“多条件筛选表格 + 详情页”这类场景时，开发效率非常高，SEO也不是问题。

后台模块包括：

• 仪表盘：今日预约数、设备使用率、待审批数量、耗材预警数量。用Chart.js直接渲染统计图，数据从聚合接口取。
• 实验室管理：实验室CRUD、开放时段配置、门禁码管理。
• 设备管理：设备档案、状态变更、维修记录、设备图片上传（用了Laravel的Storage和本地磁盘存储）。
• 预约审核：待审批列表、审批通过/拒绝、批量操作。
• 耗材管理：入库、出库、盘点、低库存阈值设置。每次耗材变动都留日志，方便审计。
• 消息管理：公告发布、模板消息推送记录。
• 系统设置：管理员账号、角色权限、操作日志。

这里想特别提示一点：没有做过度设计。比如设备管理本可以做成扫码枪快速盘点的功能，但考虑到甲方实际流程还是人工为主，我最终没有上二维码盘点，而是保留了一个“批量导入Excel”的能力。做项目一定要贴合实际流程，不能为了技术亮点盲目堆功能。

3. 关键环节的落地实现

3.1 ThinkPHP端预约接口与并发控制

预约接口是整个系统里并发风险最高的接口。因为学生会在某个开放时间段集中抢预约，比如晚上8点开放下周预约，瞬间可能涌进来一两百个请求。如果直接用简单查询判空再插入，必然出现超约。我的做法是在ThinkPHP端用事务 + 数据库锁 + 状态机三层保证。

先说你最先想到的：查一下该时间段是否已有预约，如果没有，插入预约记录。但这个逻辑在并发下不可靠，两个请求同时查到“空闲”，然后同时插入，就冲突了。所以我改成了在事务里使用SELECT ... FOR UPDATE，把某个实验室某段时间的记录行锁住，再加一个唯一索引兜底。

关键代码逻辑如下（ThinkPHP 5.1，Db类操作）：

use think\Db; try { Db::startTrans(); // 锁定实验室在指定时间段内的状态记录 $lock = Db::name('lab_time_slot') ->where('lab_id', $labId) ->where('slot_date', $date) ->where('start_time', $startTime) ->lock(true) ->find(); if (!$lock || $lock['status'] !== 1) { throw new \Exception('该时间段不可预约'); } $cnt = Db::name('reservation') ->where('lab_id', $labId) ->where('date', $date) ->where(function($query) use ($startTime, $endTime) { $query->where('start_time', '<', $endTime) ->where('end_time', '>', $startTime) ->where('status', 'in', ['pending', 'approved', 'in_use']); }) ->count(); if ($cnt > 0) { throw new \Exception('该时间段已被占用'); } $reservationId = Db::name('reservation')->insertGetId([ 'user_id' => $userId, 'lab_id' => $labId, 'date' => $date, 'start_time' => $startTime, 'end_time' => $endTime, 'purpose' => $purpose, 'status' => 'pending', 'created_at' => date('Y-m-d H:i:s') ]); Db::commit(); return $reservationId; } catch (\Exception $e) { Db::rollback(); return json(['code' => 0, 'msg' => $e->getMessage()]); }

这里有几个细节值得说。where闭包里判断时间段冲突用的是交集判断：start_time < 请求的end_time AND end_time > 请求的start_time，这样能覆盖所有交叉情况，而不是简简单单判断相等。status in (...)很重要，因为已取消的预约不应该占用时间段，已完成的也不该继续占用。

另外，如果预约的表数据量很大（比如超过十万条），FOR UPDATE会影响并发性能。我实际测试后，把lab_time_slot表的lab_id + slot_date + start_time建了组合索引，再把锁粒度缩小到这个记录级别，性能可以接受。原则是锁的范围越小越好，事务时间越短越好。

3.2 审批流设计与Laravel中的状态机实现

审批流在Laravel端实现。设备分两类：普通设备直接通过、贵重设备和涉及危险品的实验必须走审批。审批链路是“学生提交 → 指导教师审批 → 实验室管理员复核”。

我实现了一个轻量级的审批状态机，没有用外部流程引擎，因为复杂度并不高。核心表结构是reservation里的status字段加一个approval_record表记录流转历史。

pending_teacher（待指导教师审批） → teacher_approved（指导教师已通过） → pending_admin（待管理员复核） → approved（完全通过） → rejected（驳回） → canceled（学生取消） → in_use（已使用，扫码签到） → finished（已完成） → no_show（超时未到）

Laravel里的状态机我用了laravel-actions这个库来组织每个“动作”。每个动作是一个类，用来定义“从某个状态到另一个状态”的转移逻辑。

class ApproveByTeacher extends Action { public function handle(Reservation $reservation, string $remark): Reservation { throw_if( $reservation->status !== 'pending_teacher', new \DomainException('当前状态不允许该操作') ); $reservation->status = 'teacher_approved'; $reservation->save(); ApprovalRecord::create([ 'reservation_id' => $reservation->id, 'action' => 'approve_teacher', 'operator_id' => Auth::id(), 'remark' => $remark ]); return $reservation; } }

这里面最关键的设计是throw_if的状态校验。任何状态变更都必须从一个明确的状态出发，不从“目标状态”反推“是否允许”，而是从“当前状态”查表判断“该做什么”。这个思路避免了很多业务逻辑的混乱。

再有一个非常重要的细节：审批动作执行后，要检查该时间段是否因为审批通过而再次发生冲突。比如学生A先提交了一个待审批的预约，学生B后提交了一个同一时间段且状态已经是approved的预约，此时A的审批通过后，就会出现两个approved记录冲突。所以我在审批通过的动作里，会重新执行一次时间冲突检测，如果冲突则自动将状态置为rejected，并发送站内信告知原因。

这个小设计在第一次对接老师需求时完全没有想到，是测试阶段同学反馈“我明明审批通过了，为什么学生说没预约成功”时才发现的。这也是项目里最有价值的坑之一。

3.3 微信小程序登录与获取手机号

小程序的登录流程，老生常谈但必须做好。千万不要在小程序里直接拿wx.login()的code去换取openid和session_key，然后把session_key返回给前端——这是非常危险的做法，session_key一旦泄露，任何人都能解密用户手机号和个人信息。

我的推荐流程是：

1. 小程序端调用wx.login()获取临时code
2. 将code发送到后端Laravel接口/lar/auth/login
3. 后端拿着code调用微信code2session接口，换取openid和session_key
4. 后端用openid这个唯一键去查/建用户，然后签发一个自定义的登录态token（我用的是Laravel Sanctum），返回给前端
5. 后续所有业务请求，都通过Authorization: Bearer token带这个token
6. session_key只保存在服务端，不返回给前端

关于获取手机号，新版小程序是一个按钮触发open-type="getPhoneNumber"，拿到code之后也是发给后端，由后端调用phonenumber.getPhoneNumber这个接口换取手机号。这里注意：以前旧版本的加密数据解密流程现在不建议用了，微信已经逐步迁移到新的接口模式。

Laravel端的核心代码片段大概长这样：

public function login(Request $request) { $code = $request->input('code'); $response = Http::get('https://api.weixin.qq.com/sns/jscode2session', [ 'appid' => config('wechat.mini_program.appid'), 'secret' => config('wechat.mini_program.secret'), 'js_code' => $code, 'grant_type' => 'authorization_code' ])->json(); if (isset($response['errcode']) && $response['errcode'] !== 0) { return fail('登录失败：' . $response['errmsg']); } $openid = $response['openid']; $sessionKey = $response['session_key']; $user = User::firstOrCreate( ['openid' => $openid], ['nickname' => '微信用户', 'role' => 'student'] ); $token = $user->createToken('mini-program')->plainTextToken; return success([ 'token' => $token, 'user' => $user->only(['id', 'nickname', 'role', 'avatar']) ]); }

这里面有一个容易忽略的地方：微信的jscode2session接口有频繁调用限制，如果学生在弱网环境下重复点击登录按钮，会快速触发接口限流。所以我在前端给登录按钮设置了loading状态，防止重复点击，同时后端加了一个简单的一分钟维度限流逻辑。

3.4 小程序端顶部导航栏与页面列表加载适配

小程序端的适配问题，网上的讨论非常多，但这个项目里真正被坑到的是几处细节。

第一个是顶部导航栏高度。很多页面用到了自定义导航栏（navigationStyle: custom），需要把右上角的胶囊按钮高度考虑进去，否则自定义标题会偏上或偏下。业界通用的做法是取wx.getMenuButtonBoundingClientRect()的top和height，配合wx.getSystemInfoSync()里的statusBarHeight来计算。

// utils/nav.js function getNavBarInfo() { const menuRect = wx.getMenuButtonBoundingClientRect(); const systemInfo = wx.getSystemInfoSync(); const statusBarHeight = systemInfo.statusBarHeight || 20; const navBarHeight = (menuRect.top - statusBarHeight) * 2 + menuRect.height; return { statusBarHeight, navBarHeight, menuRect }; }

这个计算逻辑网上有很多版本，记住一个原则：导航栏总高度 = 状态栏高度 + 胶囊按钮到状态栏的距离的两倍 + 胶囊按钮的高度。不同机型的胶囊按钮尺寸不一样，千万不要硬编码一个320px或者64px。

第二个是页面列表的加载更多。小程序的onReachBottom触发时机在不同机型上差异很大，尤其是iPad和折叠屏。我的经验是不要完全依赖onReachBottom，而是在列表底部放一个“加载更多”按钮兜底。数据交互上做一个标准的分页响应格式：

{ "code": 0, "data": { "list": [...], "page": 1, "page_size": 10, "total": 56, "has_more": true } }

前端用has_more判断是否继续显示加载组件，就不容易出问题。

第三个是uni-app打包后体积超过2MB的问题。很多同学用uni-app开发，结果微信小程序单包体积超限。解决方法是分包加载：把首页Tab这些核心页面放进主包，把预约流程、审批详情、图片预览等低频页面放进subpackages分包。这个项目我虽然没有用uni-app，但同样的分包策略在原生小程序开发里同样适用，建议提前规划。

3.5 微信小程序端访问后台的联调环境搭建

小程序开发的一大痛点是：正式环境要求HTTPS域名，而且域名还必须在小程序后台配置白名单。但在本地开发阶段，手机真机预览没法直接访问本地电脑的接口。

我常用的方案是把/proxy到后端服务。具体来说，在微信开发者工具里，可以在“详情-本地设置”勾选“不校验合法域名”，这样开发环境可以直接用http://localhost:8000访问本地PHP服务。但是手机真机预览时，localhost是手机的地址而不是电脑的地址，所以必须使用局域网IP。

正确做法是：

1. 电脑和手机连接同一个Wi-Fi
2. 后端服务启动时监听0.0.0.0，而不是默认的127.0.0.1
3. 小程序端request的URL里填入电脑的局域网IP，比如http://192.168.1.105:8000，再加上项目路径
4. 微信开发者工具中勾选“不校验合法域名”，就可以在真机上调试了

但过几天IP会变，接口地址要来回改，非常痛苦。我最后是用了一个集中配置变量，把baseUrl都放在config.js里，切换环境只需要改一行。如果项目要多人协作，也可以用env.js区分dev、test、prod三套环境。

除了局域网联调，我还发现有个特别好用的调试技巧：用Requestly或Charles抓包看微信小程序的请求。写代码阶段不要只在Console里看报错，要会看Network面板的请求和响应。小程序本身的Network面板够用，但如果遇到诡异的登录问题、会话问题，我会用抓包工具看完整报文——因为小程序开发者工具的Network面板对部分请求头有隐藏字段展示不全，这对排查问题是个不小的坑。

4. 部署运维与常见问题排查

4.1 两个框架的服务器部署方案

这个项目最终部署在一台4核8G的云服务器上，CentOS 7.9，PHP 8.1，Nginx 1.20。因为有一个域名（比如lab.example.com），所以Nginx需要同时路由ThinkPHP和Laravel两个应用。

总体部署思路是：用不同前缀路径区分两个框架的入口。例如https://lab.example.com/tp/*走ThinkPHP应用，https://lab.example.com/lar/*走Laravel应用。如果Nginx配置不支持子路径，也可以用不同二级域名，但子路径会更省事。

ThinkPHP的Nginx配置片段：

location /tp { alias /var/www/tp-lab/public/; try_files $uri $uri/ /tp/index.php?s=$uri&$args; location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $request_filename; include fastcgi_params; } }

Laravel的Nginx配置相对标准一点：

location /lar { alias /var/www/lar-lab/public/; try_files $uri @lar; location @lar { rewrite ^/lar/(.*)$ /lar/index.php?/$1 last; } location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $request_filename; include fastcgi_params; } }

部署时我花了最多时间解决的是伪静态配置。很多同学第一次在Nginx下跑ThinkPHP时，会遇到访问首页正常、但访问/index/login这种路由时404或500的情况，原因就是try_files规则没配对。我上面给出的配置是在线上跑了很久的版本，直接参考的话能少踩一大坑。

另外，小程序要求所有请求必须HTTPS，所以服务器上要配SSL证书。现在申请SSL证书已经非常方便，我用的Let's Encrypt的免费证书，配合certbot自动续期，整个生命周期都不需要人工干预。

4.2 高频踩坑记录：登录态、并发、样式问题

把我在这个项目里遇到的、值得单独记录的问题和排查思路列出来，有些是运行环境问题，有些是代码逻辑问题。

第一个是用户在小程序里点击登录，后端返回了token，但立刻请求业务接口又提示未认证。这个问题的原因通常不是Laravel的中间件逻辑错了，而是前端token存储后没有在请求头中带上。小程序端需要统一封装request方法，在header里自动附加Authorization: Bearer ' + wx.getStorageSync('token')。我最初没做这个封装，导致每个页面都要重复写token字段，漏写一处就出问题。做完封装后再也没出过这类问题。

第二个是并发预约同一设备超卖。我上面写的SELECT ... FOR UPDATE锁能解决大部分问题，但真机测试发现，当学生A和学生B同时预约的是同一台设备而非同一实验室时，只锁实验室时间段还不够。后来我在reservation_device表上也加了设备占用唯一索引（device_id + date + start_time + end_time），利用数据库层面的唯一约束做最后防线。超卖问题彻底解决。

第三个是列表加载时重复请求问题。小程序端的onReachBottom触发非常灵敏，如果处理不当，翻页时会连续触发多个分页请求，造成数据重复。我的解决办法是给列表加载加一个isLoading锁，每次请求前判断锁状态，请求完成后释放。同时在onPullDownRefresh时把page重置为1，清空旧列表数据。

第四个是iPhone某机型上扫码跳转页面白屏。这个排查了挺久，最后发现是wx.scanCode的success回调里新页面路径写的是绝对路径/pages/scan/result?id=xxx，在浏览器里没问题，但小程序里路径前面不能加/。去掉斜杠后白屏消失。很小的细节，但影响很大。

4.3 常见问题速查表

4.4 小程序端的多账号调试与数据隔离

最后聊一个容易被忽略的地方：小程序多账号调试。测试阶段，我手上测试了学生、教师、管理员三个账号，微信开发者工具会记录上次登录状态，导致切换角色时很混乱。我的处理办法是在“我的”页里加一个切换账号/退出登录的按钮，调用wx.clearStorageSync()清掉本地token和用户信息，重新走登录流程。

还有一个细节是不同角色的首页看到的内容完全不同——学生看到“我的预约”，教师看到“我的审批”，管理员看到“实验室概览”。这个路由权限策略我前置到了后端，每个接口都校验$user->role，小程序端只是根据登录后返回的role字段动态渲染不同菜单。如果放开前端控制，懂技术的学生抓包改掉role就能进入管理页面，风险很大。

实际排查问题时，光靠微信开发者工具自带的Network面板并不完全够用。我在排查微信小程序的蓝牙打印、网络请求偶发失败问题时，用到了抓包工具来看小程序请求到底发给了谁、响应了什么。这里给一个实用的经验：抓到包后重点看请求头里的Referer和User-Agent，微信小程序端的请求UA通常带MicroMessenger字样，如果UA不对，说明请求可能不是从微信环境发出的，排查方向就要变。

5. 项目复盘与个人心得

这个项目从前端到后端、从零到上线，总体周期四周左右。团队配置是一名后端PHP工程师加一名前端开发，前端开发负责小程序页面，我负责后端API和管理后台，同时兼顾项目管理。

我印象最深的收获是：双框架共存绝不是简单地在服务器上多跑一个项目，重要的是在业务层面划清边界。我在项目初期差点陷入一个误区——想把ThinkPHP的老代码迁到Laravel，于是花了两天研究数据迁移和接口重写。后来冷静下来，发现老系统稳定运行三年没有出过大问题，强行重写反而增加风险。于是果断调整方案，老模块继续用ThinkPHP，只是把对外接口改成统一的返回格式，新模块全用Laravel，两边通过统一格式对接。这个“两套框架共用一个服务体系”的思路，最后让项目按期交付，也获得了甲方的认可。

再分享一个小技巧：不管用哪套框架，对外API一定要统一返回结构。我在两个框架里都定义了JSON响应结构，格式是：

{ "code": 0, "msg": "success", "data": {} }

ThinkPHP 5.1里我用json()函数统一包装，Laravel里我定义了一个ApiResponsetrait，处理成功和异常情况。这样小程序端无论是请求旧模块还是新模块，解析逻辑都是一致的，前端不用在业务代码里去判断“这里返回结构怎么不一样”。

如果你也想做类似的毕业设计或实际项目，我给出的路线建议是：先梳理业务流程，明确管理端和小程序端各自的功能边界；再设计数据库，把状态机和审批流通过表结构确定下来；然后选一个你更熟悉的PHP框架把后端跑通；最后再通过微信小程序把常用功能串起来。如果你对ThinkPHP更熟，可以先用ThinkPHP实现全部功能，再参考Laravel的设计把代码分层优化一遍；如果你更熟Laravel，则反过来。框架是工具，业务流程和数据模型才是项目的地基。

最后提一个很多人忽视的实战点：真机预览、多机测试、网络环境切换是在小程序项目中最需要长期投入时间来做的事情。我最后整整花了三四天的时间专门做兼容性测试，找来了苹果、小米、华为、iPad等五六种设备，把所有页面挨个过了一遍，抓出了不少iOS和Android的样式差异问题。这些测试虽然枯燥，但做完之后产品稳定性直线上升，也让我对“适配”这俩字有了更实在的理解。