校园快递代领这个小程序是我去年在帮学弟学妹做毕业设计的过程中反复打磨出来的一套方案。当时有好几个人同时找我需求都差不多学校快递点太分散上课时间冲突大件快递搬不动想找个人代取。而市面上已有的跑腿小程序要么是通用型的跟校园场景匹配度不高要么就是要接入第三方支付和配送系统对个人开发者来说门槛太高。所以我干脆用Python写后端、微信小程序做前端从零搭了一套专用的校园快递代领平台。这篇文章就是把我整个设计和开发过程完整梳理一遍。从需求拆解、数据库设计、接口规划到小程序端页面实现、订单状态机、消息通知再到部署上线后遇到的实际坑都会讲到。无论你是想拿这个当毕业设计还是真有校园创业的想法或者只是想学习微信小程序加Python后端的完整开发链路这篇都能给你一条可以直接走通的路。1. 项目整体设计与技术选型1.1 核心需求拆解校园场景到底特殊在哪校园快递代领和普通跑腿最大的区别在于它有一个非常明确的“身份闭环”。下单的人是在校学生接单的人也是在校学生而快递驿站的取件码、身份码核销这些环节都跟校园账号体系强相关。所以这个平台不能简单做成一个“发任务-抢任务”的C2C模式它需要有一个“可验证的校园身份”作为信任底座。我从实际访谈里整理出了几个高频场景上课期间收到取件短信无法及时去驿站需要有人代取后送到宿舍楼下。大件快递整箱水、猫砂、小家电自己搬不动需要强壮劳动力。同时到了五六个快递分布在校园不同片区的驿站希望一次性代取。替室友、同班同学代取赚点生活费。这里面有个很关键的矛盾点代取人怎么证明自己真的取了件驿站取件又怎么跟平台结合我的方案是平台只做“需求的撮合与过程留痕”不碰驿站核销系统。代取人到达驿站后需要上传取件码截图和包装照片作为取件凭证。这个设计放弃了完全自动化但换来了极高的可落地性因为驿站系统本身不会对外开放接口硬接反而会卡死在商务合作上。1.2 技术选型为什么是Python加微信小程序小程序端选微信小程序这个没什么好说的校园场景下微信的渗透率是绝对的统治级用户不用下载额外App扫码即用。而且微信小程序的学生认证、手机号快捷登录这些能力刚好能帮我解决身份审核问题。后端选Python核心原因是开发效率。这个项目涉及到的核心功能无外乎用户认证、订单管理、消息推送、文件上传这些用Flask或者FastAPI写起来都非常顺手。我个人选择的是Flask加SQLAlchemy原因有两个一是Flask的生态最成熟网上资料多遇到问题容易搜到解决方案二是轻量不像Django那样自带太多东西对于一个小型校园平台来说Django的管理后台和ORM虽然优秀但杀鸡用牛刀了。数据库用MySQL部署用一台2核4G的云服务器加Nginx。微信支付没有接入这是刻意砍掉的需求。校园代领的小额交易我用了校内积分加微信转账结合的方式。具体来说用户充值积分到下订单或者直接下单后添加接单人微信转账。这个设计帮我避开了微信支付的类目审核要知道个人小程序要开通微信支付必须有企业资质这是很多学生开发者的硬门槛。1.3 功能模块划分小程序端和后台各自负责什么整个系统拆成四个端用户小程序端、接单端也是小程序里的一种角色切换、管理后台Web端、后端服务接口。小程序端主要包含这些页面首页订单大厅展示所有待接单的快递代领任务支持按片区、酬金、发布时间筛选。发单页填写取件码、快递点、送达地点、期望时间、重量体积、小费金额。订单详情页订单状态流转展示双方实时沟通的留言区。个人中心我的发布、我的接单、钱包余额、实名认证状态、信用分。接单工作台抢单列表、进行中的订单、历史完成记录。后台管理端是给平台运营者用的包含用户管理、订单仲裁、信用分调整、公告发布这些功能。用Flask-Admin搭了一个简易版本够用就行不追求好看。后端服务的核心接口用户认证相关微信登录、手机号绑定、学生认证。订单相关发布、接单、取消、确认送达、申诉。文件相关图片上传、凭证图片访问。消息相关订阅消息推送、站内信。2. 数据库设计与后端核心实现2.1 关键数据表结构设计数据库设计是整个系统的基础我踩过不少坑最后定下来的核心表有这些。用户表是设计的重点。除了基本的openid、昵称、头像我还加了一个user_role字段区分普通用户和接单员。但这里不是简单的是一个管理员而是同一个用户既可以发单也可以接单所以角色其实是“每人双角色”用一个is_courier字段标识是否开通了接单权限。订单表是业务核心我设计了这些字段order_no订单编号用日期加随机数生成。publisher_id发单人ID。courier_id接单人ID初始为空。pickup_code取件码。station_name快递驿站名称。destination送达地址宿舍楼号加门牌。expected_time期望送达时间。reward_amount小费金额用整数存储单位是分。order_status订单状态后面单独讲状态机。cancel_reason取消原因。凭证表用于存取证照片order_id、image_url、uploaded_by、created_at。每次上传都会留痕发生纠纷时这是最有力的证据。信用分表记录每次行为带来的分数变化user_id、change_score、reason。初始信用分为100分接单后无故取消扣10分被投诉核实后扣20分完成一单加1分。数据库字段设计有个容易忽略的点reward_amount必须用整数存储单位用分而非元。因为浮点数在MySQL里面做等值比较会有精度问题比如0.1加0.2不等于0.3。订单金额用分存储前端展示的时候再除以100这是金融系统里最常见也最稳妥的做法。第二个容易忽略的点是所有表都要加created_at和updated_at这两个时间字段索引也一定要建好。table如果没加索引订单多了一查询就是全表扫描用户体验会非常差。我的订单表上建了order_status, station_name, created_at这个联合索引因为首页订单大厅最常见的查询就是按状态加驿站筛选。2.2 订单状态机设计核心业务逻辑订单状态是整个系统最复杂的部分它不只是接单前和接单后这么简单。我最终设计了七个状态待接单用户发布成功后进入此状态展示在订单大厅。已接单接单员抢单成功进入配送准备流程。取件中接单员到达驿站标记开始取件。配送中已取到件正在送往目的地的路上。已送达放到了指定的地点等待发单人确认。已完成发单人确认无误订单关闭积分结算。已取消发单人或接单人取消分为无责取消和责任取消。这个状态机听起来不复杂但真正的难点在于每一个状态迁移都要触发对应的消息通知。比如从待接单变成已接单要通知发单人“有人接单了”从配送中变成已送达要通知发单人“快递已放到楼下”从已接单变成已取消要通知发单人“接单人取消了请重新下单”。状态迁移的合法性校验也要做好。我写了一个全局的状态机校验函数用一个字典维护状态迁移的合法映射关系。如果客户端直接发请求要把“待接单”改成“已送达”后端校验不通过就直接返回错误。这种做法可以防止有人通过抓包篡改订单状态。2.3 抢单机制与并发控制接单这个操作本质上是一个高并发下的资源抢占行为。比如一个酬金比较高的订单展示出来后可能在1秒内有几十个人同时点接单但订单只能被一个人抢到。这里必须处理好并发问题不然会出现超卖一个订单被多个人接走了。我的方案是在接单接口中使用UPDATE语句配合条件判断实现原子操作。核心SQL是UPDATE orders SET courier_id :uid, order_status 2 WHERE order_no :order_no AND courier_id IS NULL AND order_status 1这条SQL的关键在于先判断courier_id是不是NULL也就是说这个订单还没有人接。在MySQL的InnoDB引擎下UPDATE语句会锁住符合条件的行所以即使同时有几十个请求进来最终只有一条UPDATE能命中和执行成功。然后检查影响行数如果affect_rows等于1说明抢单成功如果等于0说明被别人抢走了。这里有一个很容易犯的错误就是先SELECT再UPDATE。你先查询订单状态是否为待接单然后再在业务代码里执行UPDATE更新这两个操作之间会有时间窗口并发情况下必然会出现两个人同时查到订单可接然后同时去更新导致超卖。数据库层面的原子操作是并发控制的正解。2.4 登录认证与身份核验小程序端通过wx.login接口获取code然后传给后端。后端拿着code去微信的接口换取openid同时拿到session_key。这里注意调用微信code2Session接口需要用到小程序的AppID和AppSecret这两个在微信公众平台可以找到但AppSecret一定要放好不能写在小程序前端代码里。学生认证模块我采用的是手动审核加学号邮箱验证的方式。用户提交学号和姓名之后后台管理员手动核对信息或者通过学校的统一身份认证接口验证。不过大多数学校不对外开放接口所以实际用的还是人工审核。对于校内真实场景来说学生数量有限一天几百个申请人工完全能处理。手机号授权使用的是小程序的基础库能力可以通过button组件开放能力直接获取用户手机号。这个接口现在已经改了规范必须企业认证的小程序才能调用。个人主体账号受限的话可以退而求其次让用户手动填写手机号。3. 小程序端页面实现与交互细节3.1 项目初始化与目录结构微信小程序端的项目结构建议直接使用原生的方式开发不引入uni-app等跨端框架。原因是这个项目本身只需要跑在微信上原生开发拥有最佳的调试体验和性能而且原生小程序对订阅消息、手机号授权这些功能的支持一定是最优先的。项目的目录结构大概是这样miniprogram/ ├── app.js ├── app.json ├── pages/ │ ├── index/ # 订单大厅 │ ├── publish/ # 发布订单 │ ├── orderDetail/ # 订单详情 │ ├── myOrders/ # 我的订单列表 │ ├── profile/ # 个人中心 │ └── auth/ # 登录与认证这里有个特别重要的经验小程序的tabBar页面最多只能配置5个所以我把主要的入口拆成了三个tab首页、发布、我的。订单详情和我的订单列表都做成非tab页面通过路由跳转进入。3.2 页面核心模块拆解首页订单大厅是小程序的门面。我用了scroll-view加onReachBottom做长列表加载的下拉分页每次加载10条。每条订单卡片显示取件驿站、目的地、酬金、重量等关键信息。卡片上还有一个“抢单”按钮点击的时候会弹出二次确认提示防止误触。发单页的核心是一个表单。这里最容易被用户吐槽的是字段太多所以我做了分段式的表单第一步选择驿站和填写取件码第二步选择送达地点和期望时间第三步设置酬金最后预览确认发布。这种分步骤的方式能把用户的心理负担降下来填写完成率比单页大表单高很多。订单详情页是一个信息流设计顶部是订单状态卡片下面依次是快递信息、地址信息、酬金信息、凭证图片区、留言区。这个页面用到了小程序的原生组件也有一个和H5最大的区别小程序不能直接渲染HTML富文本所以类似留言列表这种内容必须自己在JS里做数据解析然后通过循环渲染。个人中心里有一个很常用的功能是接单员身份的开通入口。用户点击“成为跑腿员”之后会弹出一个协议确认框同意之后角色权限就开通了。这里我又做了一层判断如果用户的信用分低于60分禁止开通接单权限同时显示原因。3.3 地图选点与地址匹配的取舍刚开始我设计的时候想在上面引入腾讯地图插件让用户可以在地图上选点作为送达地址。后来发现这是过度设计。因为校园场景的地址高度结构化本质上就是“X栋宿舍楼”“X号教学楼”“X食堂”这样的有限集合。所以我改用了地址库的解决方案。后台预置了校园内的主要建筑列表发单时通过picker组件让用户选择不需要手输地址。这个设计的实用价值非常大一是用户发单时间缩短到了30秒以内二是接单人不需要再看乱七八糟的自定义文字比如“三食堂对面树下那个石凳子”这种模糊地址在纠纷处理时真的是灾难。如果确实有补充信息需要说明我在表单里加了一个备注字段非必填限定100字以内。3.4 订阅消息解决“通知”这个核心问题小程序没办法像App那样推送任意消息只能用订阅消息而且用户得主动订阅一次你才能给他推一条。这里面有个重要的限制就是一次性订阅消息只能推一条如果你想推多次就得在用户操作时连续弹订阅弹窗让用户订阅多次。我在发单流程设计了一个细节用户点击“确认发布”的同时弹窗请求订阅消息授权文案设为“接单/取消/完成通知”。这样用户每次发单都会带起订阅请求虽然有些打扰但用户为了知道订单进展大多数会同意。接单员那边也一样在抢单成功后弹一次订阅请求授权取消或超时提醒。小程序的后端调用subscribeMessage.send接口通过access_token鉴权。这里需要注意access_token获取后有效期只有2小时我写了一个定时任务去提前刷新缓存起来避免每次发送都临时去换取。否则高峰期并发高的时候可能会因为获取access_token太频繁被微信限流。4. 后端API与业务模块的实现细节4.1 接口设计规范与防刷处理后端接口统一使用RESTful风格。返回格式固定为{ code: 0, message: success, data: {} }code为0表示成功非0表示各种错误码。小程序端封装了一个request方法统一处理后端返回的code当code为401的时候自动跳转登录页。这个统一处理思路非常重要如果每个页面都单独判断错误码代码会非常冗余。防刷方面我在几个关键接口做了限制。比如发布订单接口同一个用户一小时内最多发布5单超过限制直接返回“操作过于频繁”。抢单接口则限制了一个接单员同时最多进行中的订单为3单防止有人恶意接单后不履约占着资源。微信小程序的登录code是一次性的所以不存在重放攻击的问题但是后端接口建议统一做签名校验特别是涉及订单金额和状态变更的接口。4.2 文件上传与静态资源管理取件凭证和头像图片的上传我直接用Flask的request.files接收然后存储到云服务器的指定目录通过Nginx静态映射访问。这种做法优势是简单劣势是随着使用量增加磁盘空间会不断被占满。更好的方案是接入对象存储比如阿里云OSS或者腾讯云的COS。图片上传后返回一个带签名的URL小程序端直接用这个URL去请求。对象存储的好处是扩展性极强也不占用自己的服务器带宽。学生开发者如果没有条件接入云存储本地静态文件方案可以先顶着但要注意设置一个定时任务定时清理30天以前的凭证图片防止磁盘被写满。图片上传接口还有一个很值得注意的细节必须校验文件类型和后缀名。不能让用户传一个php文件或exe文件上到服务器否则会有安全漏洞。我这边校验了content-type和文件头的magic number两重校验都通过才允许保存。4.3 定时任务自动取消与超时提醒系统里有几个必须的定时任务。最核心的是超时未接单的订单自动取消发布后的订单如果在2小时内没人接单自动取消并通知发单人。这样可以避免订单大厅永远挂着无人问津的订单影响用户体验。第二个定时任务是超时未确认送达的自动确认接单员标记已送达后如果发单人在24小时内没有确认也没有申诉系统自动将订单状态改为已完成。这个是参考了闲鱼的交易规则起到一个“沉默即同意”的效果。Flask里我用的是APScheduler这个库来写定时任务。注意生产环境不要让APScheduler直接跑在Flask的进程里因为多worker模式下每个worker都会启动一份定时任务会导致任务重复执行。我采用的方案是单独起一个进程跑定时任务模块只执行一次。4.4 申诉与仲裁的业务设计有交易就会产生纠纷。我的平台遇到最多的纠纷类型有两种一种是接单人取错件了把A的快递取成了B的另一种是送达后东西损坏了发单人要求赔偿。申诉流程是这样设计的订单完结后48小时内双方都可以发起申诉。发起申诉后订单进入争议中状态后台管理员可以看到双方上传的凭证图片和聊天记录。管理员在后台做出判定后系统自动执行对应的扣款、扣分操作。这个模块让我明白了后台管理的核心不只是增删改查而是要围绕订单生命周期去设计权限和控制流。Flask-Admin虽然自带CRUD操作但为了防止管理员误操作我特意关闭了直接数据库编辑权限只开放了仲裁专用接口。5. 部署上线与常见问题排查实录5.1 服务器环境与部署流程部署环境我选的是腾讯云的轻量应用服务器2核4G的配置操作系统是Ubuntu 22.04。这个配置跑一个Flask应用加MySQL日常几十个并发是完全够用的。部署流程简单过一遍安装Python 3.10、MySQL 8.0、Nginx。创建虚拟环境安装requirements.txt。使用supervisor管理Gunicorn进程配置3个worker跑Flask。Nginx配置反向代理静态文件直接由Nginx处理接口请求转发到Gunicorn的Socket。使用certbot配置HTTPS证书微信小程序要求所有请求域名必须是HTTPS且不能使用IP地址访问。这里有个小提醒微信小程序后台需要配置服务器域名白名单。request合法域名、uploadFile合法域名、downloadFile合法域名这些必须在微信公众平台配置好不然真机调试的时候请求会被拦截。5.2 微信小程序审核注意事项审核是整个上线流程中最折磨人的环节。我第一次提审的时候因为类目选择了“生活服务-跑腿”结果要求提供《增值电信业务经营许可证》这个证个人开发者根本办不下来。后来我调整了一下思路类目改为“教育-校园服务”加上学生身份核验流程承诺仅面向本校师生服务审核就顺利通过了。这里面的逻辑是审核人员也清楚校园场景的跑腿是刚需只要你的表述和应用场景清晰不做大而全的C端服务审核是可以通过的。第二个要注意的是小程序的隐私协议必须写清楚收集了哪些信息、用在哪里。尤其是手机号、位置信息和相册权限弹窗告知的原因要和实际用途完全一致这个现在是审核的硬指标。第三个经验是审核环境需要提供测试账号。我在登录页做了个小开关审核人员和管理员可以通过邀请码进入体验模式在这个模式下内置了一批模拟订单方便审核人员完整体验从发单到接单再到送达的完整流程。5.3 真机调试与常见报错解决真机调试阶段我遇到的最多的一类问题是“request:fail url not in domain list”。这个是因为没有在微信公众平台配置服务器域名。解决方法是把正式域名的HTTPS证书配好然后在开发者工具的“详情-本地设置”中勾选“不校验合法域名”只能用于本地调试真机预览必须走正式域名。第二个常见问题是请求返回500。排查思路是先看服务器日志再确认数据库连接池是否正常最后看内存和CPU占用。我遇到过一次MySQL连接数被占满的问题原因是SQLAlchemy的connect_args没有配置pool_pre_ping和pool_recycle导致连接池中的连接失效后没有自动重连。配置之后这个问题彻底解决了。第三个问题是订阅消息发不出去。最常见的原因是用户没有点击订阅弹窗也就是没有拿到一次性订阅消息的配额。我调试的时候发现开发者工具里点击授权是有问题的很多开发者以为成功了但实际上没有。最终我是用真机去测发现授权弹窗正常、backend的access_token刷新也正常之后整个消息链路才算完全跑通。5.4 性能优化与校园热点活动我上线后遇到的第一个性能问题是开学季那一周。新生入学快递量暴增订单大厅的接口响应时间从正常的100毫秒直接飙升到了2秒多。做了排查之后发现瓶颈在订单大厅的列表查询。当时的SQL逻辑是每查询10条订单就要关联用户表查一次发布者的昵称和头像。这个在数据量大的时候会产生N1查询问题一共10条订单就要额外查10次用户表。优化方式是采用联表查询一次性把订单信息和用户信息查出来避免逐条查询。同时加了Redis缓存首页的订单列表缓存10秒。这个缓存时间经过测试是合理的对用户来说10秒内列表内容变化感知很弱但对数据库来说这10秒内减少的查询量是巨大的。校园活动的场景也值得说一下。每到双十一、618这种时间点订单量是平时的3倍以上。如果只是靠增加服务器配置硬扛成本太高。我的做法是给订单大厅页面加了一个“动态置顶”功能把酬金高、时效紧急的订单置顶引导接单人优先处理这部分需求用业务的逻辑来减轻系统的压力。6. 安全加固与运营避坑建议6.1 后端接口安全不只是登录态校验很多初学开发者做小程序以为只要能通过wx.login登录就安全了其实不是。小程序的登录态只是第一道门真正的安全重点在于接口级别的权限校验。比如订单详情接口必须校验当前请求的用户是不是订单的发布者或接单者否则别人通过遍历订单号就能看到无关人员的取件码和电话信息。取件码隐私尤其重要驿站取件的凭证就是取件码泄露出去等于裸奔。价格类的接口比如修改酬金的接口一定是后端加了权限校验的不能只在前端隐藏入口。有些攻击者会直接模拟POST请求把订单金额改成0甚至变成负数如果后端没有对金额做范围校验就会造成损失。我这边的做法是所有涉及金额变更的操作后端都必须做二次校验比如酬金最低1元最高200元。6.2 信用体系与风险控制校园跑腿服务的核心问题不是功能而是信任。我见过的很多类似平台最后运营不下去都是因为发生了传统快递纠纷没人说得清责任平台公信力崩塌。我的做法是搭建了一个轻量信用体系。初始信用分100分完成一单加1分被投诉核实扣20分接单后无故取消扣10分信用低于60分无法接单。这个规则非常朴素但能过滤掉绝大多数不靠谱的接单员。另一个比较有帮助的措施是接单员实名认证。我会收集学生的学号、姓名、手机号通过学号邮箱验证后完成认证。这个环节能很大程度上约束接单员的行为因为校园范围内的实名压力远大于互联网上的虚拟身份。6.3 资金与手续费的设计考量校园代领的酬金普遍在2到10元之间金额较小。如果引入复杂的分润体系对用户体验是一个很大的伤害。我的做法是平台不收取佣金有些规则的制定可以简单直接全部让利给接单员平台的价值通过其他方式来体现比如积分任务、置顶费、广告位。当然如果未来要做到商业化运营还是需要设计一个合理的抽成比例。我建议是控制在5%到10%之间再高接单员就没什么动力了。支付方式上微信支付的校园生意类目需要企业资质个体户也可以申请但如果不想碰支付牌照的问题可以先用积分加线下转账的模式跑通MVP验证需求后再考虑接入。6.4 数据备份与异常兜底小程序上线后用户数据就是最重要的资产。云服务器的磁盘有损坏风险如果数据库没有做备份一旦数据丢失整个平台的信用和业务都会瞬间瘫痪。我设置了一个每天凌晨3点自动备份数据库的任务备份文件保留最近14天。同时每周会手动导出一次全量数据到本地电脑双保险。订阅消息发送失败的日志也会保留30天万一用户说没收到通知可以回溯日志确认是没发还是发了没收到。还有一个兜底机制值得做每天定时扫描异常订单。比如有人发布了一个超高额酬金的订单但是迟迟没人接单这种异常情况需要平台管理员介入。系统会自动给管理员推送预警避免因为疏忽导致用户财产受损。7. 踩坑实录那些文档里不会写的细节7.1 wx.env.user_data_path 的本地存储限制小程序里如果要把文件保存到本地可以用wx.env.user_data_path这个路径。但这个目录是沙盒目录不同用户之间的数据是完全隔离的而且用户清理微信缓存的时候这个目录随时可能被清掉。我在设计凭证图片离线缓存的时候踩过这个坑。用户取件时我在本地先缓存了一份凭证图片准备网络不稳的情况下也能查看。结果发现切换账号之后本地缓存的数据直接丢了。后面我改用了一个思路凭证图片永远只存服务端本地只是临时展示这样才能保证数据的可靠性和跨端一致性。7.2 uni-datetime-picker在scroll-view中的异常项目里有一个页面我把日期时间选择器放进了scroll-view滚动容器中。结果发现在iOS上选择器弹层的位置会错乱而且滑动滚轮的时候选择器内部会跟着滚动体验非常差。排查之后才知道这是iOS小程序端WebView的渲染优化策略导致的滚动容器内部的fixed定位元素会出现渲染错乱。解决办法有两种一是把picker移出scroll-view用页面级定位来弹层二是使用官方picker组件的modemultiSelector代替第三方组件库的datetime-picker。我最后选了官方组件的方式虽然交互上稍微简陋一点但胜在稳定跨端表现一致。7.3 小程序右上角胶囊按钮的处理有用户反馈说小程序右上角的胶囊按钮挡住了页面的自定义按钮。尤其是自定义导航栏的时候这个胶囊按钮的位置是不固定的不同机型上它的高度和宽度都有差异。iOS和Android的胶囊按钮位置是不同的加上不同手机屏幕的宽度差异顶部布局很容易出现覆盖。我封装了一个工具函数通过wx.getMenuButtonBoundingClientRect获取胶囊按钮的位置信息再计算自定义导航栏的安全区域。这个函数是整个项目中复用率最高的工具函数之一凡是自定义了导航栏的页面都必须接入。7.4 图片旋转与上传前的预处理用户上传凭证的时候有时候会发现上传后的照片方向是歪的。这个问题的根源在于手机相册中的照片带有EXIF方向信息而Canvas或者服务端处理时忽略了读取这个信息。解决方案是前端用wx.compressImage做压缩时把旋转参数也一起处理掉。或者后端用Pillow库读取EXIF信息然后对图片做相应的旋转操作并重新保存。我在Flask后端加了统一处理函数任何上传的图片都会先归一化方向再压缩到合理尺寸再存储。这样处理后的图片在App端和后台管理端都能以正确的方向展示。7.5 审核被拒的修改记录前前后后这个项目被拒了四次我总结一下被拒的原因第一次是因为没有隐私保护指引微信要求小程序必须在设置里写明收集了什么信息。第二次是因为类目选择不当需要提供额外资质。第三次是因为客服消息没有及时回复微信要求小程序必须在24小时内响应客服消息。第四次是因为测试账号无法体验完整流程需要配置引导页和演示环境。每一次被拒其实都能发现项目中真实存在的问题我不建议去跟审核人员硬刚或者钻空子老老实实按平台规则去修改反而最快。现在这个平台在我学校实际运行了快一年注册用户4000多日均订单80到120单高峰期能到300单。从一个技术项目角度看它的架构不算复杂但每一层都经历了真实流量和真实业务的打磨。如果你也想做一个类似的校园跑腿平台先把快递驿站跑一圈问问驿站管理员每天有多少件没人取再回来写代码需求远比你想的清晰。