当前位置：首页 > news >正文

食刻外卖全栈开源包：含用户小程序、商户后台、骑手APP及管理端完整源码

news 2026/6/2 7:15:50

本文还有配套的精品资源，点击获取

简介：提供一套开箱即用的外卖业务全链路源码，包含微信小程序（用户下单+查看订单）、商户管理后台（商品上架、订单处理、营业设置）、骑手端APP（接单、导航、配送状态更新）、PC端Web管理后台（多角色权限、数据统计、系统配置）以及后端服务代码。目录结构清晰，涵盖wxapp、app（Android/iOS双端）、web、addons插件模块和后端核心服务，全部源码无加密无混淆，兼容主流云服务器环境。内置商户入驻审核流程、实时智能派单逻辑、配送轨迹可视化、订单生命周期管理、多级权限控制等实用功能。附带基础数据库表结构、部署文档与安装说明，适合用于本地开发调试、高校教学实践、创业项目原型搭建或中小型区域外卖平台快速上线。

1. 项目概述：为什么“食刻”不是又一个玩具级Demo，而是一套能跑通真实业务闭环的外卖源码

我从2018年开始做本地生活SaaS系统交付，经手过二十多个外卖类项目——有高校食堂自营平台、社区团购+配送混合体、县城连锁餐饮统一收银系统，也有纯线上轻量版“小份菜”外卖。见过太多标榜“全栈开源”的代码包：前端UI炫酷但后端连订单状态机都没写全，小程序能点单却压根没对接支付回调，骑手APP里连GPS坐标上报逻辑都是空函数……这类代码，拿来当毕设PPT素材还行，真想搭个能接单、能履约、能对账的系统？三天就卡死在“用户下单后商户收不到通知”这个环节。

“食刻外卖全栈开源包”是我近两年见过最接近生产可用标准的一套完整链路代码。它不追求技术栈堆砌（比如硬塞上K8s、Service Mesh），而是把重心放在业务逻辑的完整性、状态流转的严谨性、多角色协同的真实感上。举个最典型的例子：它的派单不是简单“谁离得近就推给谁”，而是内置了三层调度策略——基础距离权重、骑手当前负载系数（已接单数+预计送达时间）、历史履约评分（超时率/投诉率），三者加权计算后生成实时派单队列，并支持人工干预覆盖。这个逻辑藏在backend/app/services/dispatcher.go里，不到300行Go代码，但每行都有注释说明权重计算依据，连测试用例都配好了。

关键词里提到的“外卖小程序源码”“骑手APP源码”“商户后台系统”，在“食刻”里不是割裂的四个模块，而是通过一套统一的领域事件总线（Event Bus）耦合在一起的。用户下单触发OrderCreatedEvent，商户后台监听该事件更新待处理订单列表，调度中心监听后启动派单流程，骑手APP则通过长连接订阅OrderAssignedEvent实时弹窗提醒。这种设计让各端代码可以独立迭代，只要事件结构不变，就不会互相拖垮——这才是真正支撑中小团队并行开发的底座。

它适合谁？如果你是高校教师带学生做《分布式系统实践》课设，这套代码能让你两周内讲清楚“服务间如何解耦”；如果你是刚创业的本地餐饮老板，租一台4核8G的云服务器，按文档操作两小时就能上线一个带支付、能接单、骑手能跑起来的最小可行产品（MVP）；如果你是想转行做后端的开发者，它的后端目录结构就是一本活的《外卖领域建模手册》——从order聚合根的设计，到delivery_route实体的状态迁移图，再到merchant_settlement结算周期的定时任务实现，全是教科书级的落地范例。它不教你“怎么用Spring Cloud”，但它会告诉你“为什么订单创建必须先锁库存再扣余额”，这种细节，才是真实世界里踩坑换来的认知。

2. 整体架构与设计思路：为什么选择这套组合，而不是更“时髦”的方案

2.1 技术选型背后的务实主义

先说结论：“食刻”的技术栈不是为炫技，而是为降低部署门槛、缩短调试周期、规避冷门依赖陷阱。我拆解过它的docker-compose.yml和build.sh脚本，所有组件版本都经过交叉验证——比如MySQL用的是8.0.33而非最新的8.4，因为后者默认启用了caching_sha2_password认证插件，而很多老版本PHP扩展（如mysqli）不兼容，会导致商户后台登录失败；Redis选6.2.6而非7.x，是因为7.x的ACL LOG功能在某些低配云服务器上会引发内存泄漏，影响订单消息队列稳定性。

后端核心：采用Go语言（Gin框架）+ MySQL 8.0 + Redis 6.2 + RabbitMQ 3.11
为什么不用Java或Node.js？Go的静态编译特性让部署极其简单——后端服务最终打包成单个二进制文件，扔到服务器上chmod +x && ./server就能跑，完全规避了JVM版本冲突、Node模块编译失败等经典痛点。Gin的中间件机制也天然适配外卖场景的强横切需求：auth_middleware统一鉴权、trace_middleware记录订单全链路耗时、rate_limit_middleware防刷单，每个中间件独立可插拔。
小程序端：基于微信原生框架（WXML/WXSS/JS），未使用Taro或UniApp
这是个关键取舍。跨端框架确实能“一次开发多端运行”，但外卖小程序对性能极度敏感——首页商品瀑布流滚动帧率、订单状态实时刷新延迟、地图SDK加载速度，任何一层抽象都会带来不可控的性能损耗。“食刻”的小程序代码里，pages/order/index.js中对wx.createMapContext的调用直接绑定到页面生命周期，onReady里初始化地图，onShow里拉取最新订单状态，没有中间层转发，实测在低端安卓机上地图缩放延迟低于80ms。
骑手APP端：Android用Kotlin（Jetpack Compose）、iOS用Swift（Combine框架）双原生开发
这里有个容易被忽略的细节：它的定位SDK不是简单调用系统API，而是实现了混合定位策略。在室内（GPS信号弱）时自动切换至WiFi指纹定位（调用WifiManager扫描周边AP MAC地址，匹配预置商圈数据库）；在高速移动中（如骑手骑电动车穿城）则启用加速度计辅助的航迹推算（Dead Reckoning），防止GPS漂移导致轨迹断点。这部分逻辑在app/android/src/main/java/com/shike/delivery/location/LocationFusion.kt里有完整实现，连测试用的模拟轨迹数据集都打包在test_data/目录下。
Web管理后台：Vue 3（Composition API）+ Element Plus + ECharts 5
选Vue而非React，核心考量是国内开发者生态成熟度。Element Plus的表格组件自带服务端分页、列宽拖拽、导出Excel功能，<el-table>配合<el-pagination>两行配置就能搞定日均百万订单的数据查询；ECharts 5的geo地图组件直接支持GeoJSON商圈热力图渲染，backend/api/v1/statistics/delivery_heatmap接口返回的经纬度聚合数据，前端一行chart.setOption({ series: [{ type: 'heatmap', data: res.data }] })就完成可视化——这种开箱即用的契合度，比自己封装React图表库节省至少三天工时。

2.2 目录结构即业务模型：从文件夹命名读懂外卖系统本质

打开源码包，第一眼看到的不是技术名词，而是清晰的业务域划分：

├── wxapp/ # 微信小程序（用户端） │ ├── pages/ │ │ ├── index/ # 首页（附近商家+推荐菜品） │ │ ├── order/ # 订单全流程（创建→支付→制作→配送→完成） │ │ └── user/ # 个人中心（地址管理、优惠券、历史订单） ├── app/ # 骑手APP（Android/iOS共用逻辑） │ ├── src/ │ │ ├── core/ # 核心能力：定位融合、离线缓存、消息推送 │ │ ├── domain/ # 领域模型：OrderEntity, DeliveryRoute, RiderProfile │ │ └── ui/ # 页面：接单大厅、导航页、订单详情 ├── web/ # Web管理后台（PC端） │ ├── src/ │ │ ├── views/ │ │ │ ├── merchant/ # 商户管理（入驻审核、店铺设置、商品CRUD） │ │ │ ├── rider/ # 骑手管理（资质审核、绩效看板、排班） │ │ │ └── system/ # 系统配置（费率设置、区域划分、短信模板） ├── backend/ # 后端服务（Go语言） │ ├── app/ # 应用层：HTTP路由、事件监听、DTO转换 │ ├── domain/ # 领域层：聚合根（Order）、实体（Merchant）、值对象（Money） │ ├── infrastructure/ # 基础设施层：MySQL Repository、RabbitMQ Publisher │ └── main.go # 启动入口（依赖注入容器初始化） ├── addons/ # 插件模块（可热插拔） │ ├── alipay/ # 支付宝支付对接（含异步通知验签逻辑） │ ├── sms/ # 短信网关（阿里云SMS SDK封装） │ └── wechat/ # 微信公众号模板消息（订单状态变更推送）

这个结构本身就在传递一个理念：技术是为业务服务的，目录就是业务边界的映射。比如backend/domain/order/目录下，你会看到order.go定义了订单聚合根，order_status.go枚举了从created→paid→confirmed→preparing→ready_for_pickup→picked_up→delivered→completed的12种状态，每个状态转移都强制校验前置条件（如ready_for_pickup只能由商户操作触发，且必须满足paid==true && preparing==true）。这种设计让开发者一眼就能理解“订单为什么卡在准备中”，而不是去翻几十个if-else判断。

再看addons/目录，它刻意把支付、短信、微信消息这些外部依赖抽成独立模块。这意味着如果你所在地区不支持支付宝，完全可以删掉alipay/目录，换成银联云闪付的对接代码，只要实现PaymentGateway接口，其他业务代码完全不用改——这就是领域驱动设计（DDD）里“防腐层（Anti-Corruption Layer）”的实际价值。

3. 核心功能实现详解：从代码到业务落地的关键细节

3.1 商户入驻审核流程：不只是表单提交，而是风控起点

很多开源外卖系统把商户入驻做成简单的“填信息→管理员审核→通过”，但真实场景中，这一步是反欺诈的第一道闸门。“食刻”的审核流程嵌入了三层校验：

前端初筛：小程序端pages/merchant/apply/index.wxml中，营业执照上传组件强制调用wx.chooseImage并限制格式为jpg/png，文件大小不超过5MB。更重要的是，它集成了OCR识别预检——调用addons/wechat/ocr.js中的idCardOcr()方法，对上传图片进行文字提取，自动填充“企业名称”“法定代表人”“统一社会信用代码”字段，并实时校验信用代码格式（18位，含数字和字母X）。
后端风控：当审核员在Web后台点击“通过”时，后端backend/app/handler/merchant_handler.go中的ApproveMerchant方法会触发：
- 调用天眼查/企查查开放API（配置在config.yaml中），验证企业是否存在、是否处于经营异常名录；
- 查询内部黑名单库（merchant_blacklist表），检查法人身份证号是否在历史违规商户库中；
- 对比营业执照图片的EXIF信息，检测是否为手机截图（非原始拍摄照片可能为伪造）。
自动化资质核验：审核通过后，系统自动生成merchant_verification_task，调用addons/sms/模块发送短信验证码至法人手机号，并要求其在48小时内完成实名认证（跳转至微信H5页面，调用wx.login获取unionId，与营业执照法人姓名比对）。

提示：这个流程的数据库设计很值得学习。merchant_apply表存储申请信息，merchant_verification_task表记录核验任务状态，merchant_license_ocr_result表单独存OCR识别结果。三张表通过apply_id关联，但绝不冗余存储——比如营业执照图片URL只存在merchant_apply中，OCR结果只存文本，避免同一张图片被多次解析导致性能浪费。

3.2 实时智能派单：距离不是唯一指标，负载与信誉才是关键

派单逻辑藏在backend/app/services/dispatcher.go，核心是CalculateScore函数。它接收一个骑手ID和一个订单ID，返回0~100的派单得分。计算公式如下：

Score = (0.4 × DistanceScore) + (0.35 × LoadScore) + (0.25 × ReputationScore)

DistanceScore（距离分）：不是简单算直线距离。系统调用高德地图direction/drivingAPI获取实际驾车路径距离（考虑实时路况），再通过math.Exp(-distance/3)函数转换为0~100分（3公里内满分，10公里外趋近于0）。
LoadScore（负载分）：动态计算骑手当前工作强度。查询rider_current_orders视图（MySQL物化视图），统计该骑手：
已接单但未送达的数量（pending_count）；
所有订单的预计总配送时长（estimated_delivery_time_sum）；
当前时间与最早订单预计送达时间的差值（time_to_first_delivery）。
公式：LoadScore = 100 × (1 - min(pending_count/5, 1)) × (1 - min(time_to_first_delivery/60, 1))，确保单量过多或首单快超时的骑手自动降权。
ReputationScore（信誉分）：读取rider_performance表中该骑手近30天数据：
准时率 =1 - (late_order_count / total_order_count)；
投诉率 =1 - (complaint_count / total_order_count)；
评分 =0.6 × 准时率 + 0.4 × (1 - 投诉率)，再映射到0~100分。

实操心得：我在本地测试时发现，单纯依赖API计算得分会导致高并发下派单延迟。解决方案是在dispatcher.go中加入本地缓存层：用sync.Map缓存最近10分钟内的rider_performance数据，每5秒异步刷新一次。这样即使高德API偶尔超时，系统仍能基于缓存数据快速决策，实测QPS从80提升至320。

3.3 配送轨迹追踪：不止是画线，更是履约过程数字化

骑手APP端的轨迹上报不是简单的“每隔5秒发一次GPS坐标”，而是实现了自适应采样策略：

静止状态（速度 < 0.5m/s）：每60秒上报一次，坐标精度要求±50米；
匀速移动（0.5m/s ≤ 速度 ≤ 8m/s）：每15秒上报一次，启用GPS+WiFi融合定位；
高速/转弯状态（速度 > 8m/s 或加速度 > 2m/s²）：每5秒上报一次，并附加陀螺仪角速度数据。

这些逻辑在app/android/src/main/java/com/shike/delivery/location/AdaptiveLocationClient.kt中实现。上报数据结构如下：

{ "rider_id": "rdr_789", "order_id": "ord_456", "timestamp": 1712345678901, "latitude": 39.9042, "longitude": 116.4074, "accuracy": 12.5, "speed": 6.2, "bearing": 142.3, "source": "gps_wifi_fusion" }

后端收到数据后，不直接存入数据库，而是先写入RabbitMQ的delivery_track_queue，由独立消费者服务track_processor处理：
- 过滤掉精度>50米的脏数据；
- 将连续坐标点聚合成“轨迹段”（segment），每段包含起止时间、平均速度、途经商圈；
- 更新delivery_route表中的current_segment字段，并触发SegmentCompletedEvent事件，通知商户后台更新“预计送达时间”。

注意：轨迹数据量极大，delivery_track表按date分区（如delivery_track_20240405），并为order_id和timestamp建立联合索引。我在部署时曾因忘记分区导致单表超2亿行，查询订单轨迹变慢至12秒——务必在初始化数据库时执行scripts/init_partition.sql。

4. 部署与二次开发指南：从零到上线的完整路径

4.1 云服务器环境准备：避开90%新手的坑

官方文档说“适配常见云服务器”，但实际部署时，以下三点必须手动确认：

时区统一：所有组件（MySQL、Redis、RabbitMQ、Go服务）必须设为Asia/Shanghai。MySQL执行SET GLOBAL time_zone = '+8:00';，Go服务启动前加export TZ=Asia/Shanghai。否则会出现“商户看到订单创建时间比实际晚1小时”的诡异问题。
文件描述符限制：外卖系统需维持大量WebSocket长连接（骑手APP）、HTTP连接（小程序轮询）。在Ubuntu系统中，编辑/etc/security/limits.conf：
* soft nofile 65536 * hard nofile 65536 root soft nofile 65536 root hard nofile 65536
并在/etc/systemd/system.conf中添加DefaultLimitNOFILE=65536，否则高并发下会出现too many open files错误。
Swap空间配置：Go程序内存占用波动大，建议分配2GB Swap。执行：
bash sudo fallocate -l 2G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile

4.2 数据库初始化：不只是导入SQL，更要理解表关系

database/目录下提供init.sql和sample_data.sql。但直接执行会有隐患：

init.sql中merchant表的status字段类型为ENUM('pending','approved','rejected','suspended')，但MySQL 8.0默认严格模式会拒绝插入非法值。需在执行前临时关闭：SET SESSION sql_mode=(SELECT REPLACE(@@sql_mode,'STRICT_TRANS_TABLES',''));
sample_data.sql包含测试商户、骑手、用户数据，但密码是明文123456。首次部署后，必须立即执行：
sql UPDATE merchant SET password = SHA2('your_new_password', 256) WHERE id = 1; UPDATE rider SET password = SHA2('your_new_password', 256) WHERE id = 1;

更关键的是理解核心表关联：
-order表的merchant_id关联merchant表，但rider_id为NULL（派单前）；
-delivery_route表通过order_id关联order，通过rider_id关联rider，形成“订单-配送”桥接；
-order_item表的sku_id指向merchant_sku（商户商品库），而非全局商品库——这是支持“同一菜品在不同商户价格不同”的设计基础。

4.3 小程序配置：微信侧必须完成的5项设置

源码中wxapp/project.config.json只是开发配置，上线前需在微信公众平台完成：

服务器域名配置：在“开发管理→开发设置”中，将request合法域名设为你的后端API地址（如https://api.shike.com），注意必须是HTTPS且备案域名。
业务域名：若小程序内嵌H5页面（如支付成功页），需在此处添加H5域名。
webview业务域名：同上，但针对<web-view>组件。
扫码进入小程序：在“功能设置→扫普通链接二维码打开小程序”中，配置URL Link规则，用于骑手APP分享订单给用户查看。
支付配置：在“微信支付→产品中心→APPID授权管理”中，将你的小程序APPID授权给支付商户号，并在backend/config.yaml中填写wechat.mch_id和wechat.api_v3_key。

实操心得：微信支付回调地址必须是https://yourdomain.com/api/v1/pay/notify，且该路径需在Nginx中显式放开（不能被location /api { deny all; }拦截）。我曾因此卡在“用户支付成功但订单状态不更新”，排查了整整一天才发现Nginx配置漏了一行proxy_pass。

4.4 二次开发避坑指南：哪些地方可以改，哪些绝对不能碰

安全可改区：
wxapp/pages/index/index.wxml：修改首页UI，增加“今日爆款”横幅；
backend/app/handler/order_handler.go：在CreateOrder方法末尾添加自定义钩子，如调用企业微信机器人推送新订单；
addons/sms/aliyun_sms.go：替换为腾讯云短信SDK，只需重写SendSms方法。
谨慎修改区：
backend/domain/order/order_status.go：新增订单状态（如refunded）必须同步修改OrderStatusTransition规则，否则状态机崩溃；
backend/infrastructure/mysql/order_repository.go：修改SQL语句前，务必检查GetOrderByID等方法是否被transaction包裹，避免破坏事务一致性。
禁止修改区：
backend/app/middleware/auth_middleware.go：JWT签名校验逻辑，改动可能导致全员免登录；
backend/domain/money/money.go：金额计算使用int64单位为“分”，任何改为float64的操作都会引发资金误差；
app/android/src/main/res/values/strings.xml中的app_name：此值关联Android签名证书，修改后需重新签名，否则无法更新应用。

5. 常见问题与排查技巧实录：那些文档没写的实战经验

5.1 小程序“白屏”问题：90%源于这3个配置

现象	可能原因	排查命令	解决方案
首页加载后空白，控制台无报错	`project.config.json`中`appid`未替换为你的小程序APPID	在开发者工具中打开“调试器→Console”，输入`wx.getAccountInfoSync()`	修改`wxapp/project.config.json`的`appid`字段，重启IDE
商品列表显示“加载失败”，Network标签显示404	后端API域名未在微信公众平台配置为`request合法域名`	在小程序中打开“调试器→Network”，查看请求URL是否被拦截	登录微信公众平台→开发管理→开发设置→服务器域名，添加你的API域名
地图不显示，控制台报`map component not found`	未在小程序后台开通“地图组件”权限	在小程序管理后台→开发管理→接口设置，搜索“地图”	开通“获取位置”“地图组件”两个接口权限

5.2 骑手APP定位漂移：不是代码Bug，而是硬件特性

在测试中发现，某款华为Mate 40 Pro骑手APP轨迹呈“之”字形抖动。排查后发现是GPS冷启动问题：设备长时间未使用GPS，首次定位需要30秒以上，期间系统返回的是基站粗略定位（误差500米）。解决方案：

在APP启动时，主动调用LocationManager.requestLocationUpdates开启高精度定位；
在AdaptiveLocationClient.kt中增加“冷启动补偿”逻辑：前3次上报坐标，若精度>100米，则丢弃并等待下一次；
向骑手推送引导文案：“请在开阔地带停留10秒，等待GPS信号稳定”。

5.3 订单状态停滞：数据库事务与消息队列的隐性冲突

现象：用户支付成功，但订单状态卡在paid，商户后台不显示新订单。日志显示OrderPaidEvent已发布，但merchant_listener服务无消费记录。

根本原因：backend/app/handler/pay_handler.go中，支付回调处理逻辑包含两步：
1. 更新order.status = 'paid'；
2. 发布OrderPaidEvent事件。

但这两步不在同一个数据库事务中！如果第1步成功、第2步因网络问题失败，就会出现状态不一致。

修复方案：采用本地消息表模式。在order表同库新建outbox_message表，支付回调中：
- 开启事务，同时更新order.status和插入outbox_message（状态为pending）；
- 启动独立goroutine，轮询outbox_message表，将pending消息发往RabbitMQ，并更新状态为sent。

该方案已在backend/app/services/outbox_service.go中实现，只需取消// TODO: enable outbox service注释并启动即可。

5.4 Web后台登录缓慢：别怪代码，先查Redis连接池

现象：Web后台登录页面响应超时（>10秒），但API接口正常。Nginx日志显示upstream timed out。

排查步骤：
1. 进入服务器，执行redis-cli -h your_redis_host -p 6379 ping，确认Redis可达；
2. 执行redis-cli -h your_redis_host -p 6379 info clients，查看connected_clients是否接近maxclients（默认10000）；
3. 检查backend/config.yaml中redis.pool_size是否过小（默认20），在高并发下连接池耗尽。

解决方案：将redis.pool_size调至200，并在backend/infrastructure/redis/client.go中增加连接池健康检查：

// 每30秒ping一次，自动剔除失效连接 go func() { ticker := time.NewTicker(30 * time.Second) for range ticker.C { client.Ping(context.Background()) } }()

6. 性能优化与扩展建议：让系统从“能用”走向“好用”

6.1 订单查询性能瓶颈突破：从全表扫描到精准索引

backend/app/handler/order_handler.go中的ListOrdersByUser接口，默认按created_at倒序分页。当order表数据超500万行时，LIMIT 20 OFFSET 10000查询耗时飙升至8秒。

优化方案分三步：

覆盖索引：在order表上创建复合索引：
sql ALTER TABLE `order` ADD INDEX `idx_user_status_created` (`user_id`, `status`, `created_at`);
此索引让WHERE user_id=? AND status IN (?) ORDER BY created_at DESC LIMIT ?查询走索引扫描，而非全表。
游标分页替代OFFSET：修改API参数，要求前端传入last_created_at（上一页最后一条记录的创建时间），SQL改为：
sql SELECT * FROM `order` WHERE user_id = ? AND status IN (?) AND created_at < ? ORDER BY created_at DESC LIMIT 20;
彻底消除OFFSET性能衰减。
冷热分离：将一年前的订单归档至order_archive表，主表仅保留近12个月数据。归档脚本scripts/archive_old_orders.sh已内置，每月1号凌晨自动执行。

6.2 多区域运营扩展：从单城市到跨城部署

“食刻”默认按单城市设计，但可通过以下方式支持多区域：

数据库层面：在merchant表增加city_code字段（如bj、sh），所有订单查询SQL追加AND merchant.city_code = ?条件；
配置层面：backend/config.yaml中增加regions配置块，定义各城市配送费规则、营业时间；
前端层面：小程序首页增加城市选择器，选择后通过wx.setStorageSync('city_code', 'sh')持久化，并在后续所有API请求头中携带X-City-Code: sh。

关键点在于区域配置的原子性：regions配置必须作为整体加载，不能允许部分城市配置生效。因此在backend/app/config/loader.go中，我们实现了配置热加载校验——每次更新config.yaml，先解析全部regions，验证每个城市的delivery_fee_rules是否包含必填字段，全部通过才生效。

6.3 安全加固清单：生产环境必须做的7件事

禁用Swagger UI：backend/app/router.go中注释掉r.GET("/swagger/*any", ginSwagger.WrapHandler(swaggerFiles.Handler))，生产环境绝不暴露API文档；
JWT密钥轮换：backend/config.yaml中jwt.secret改为环境变量JWT_SECRET，并定期（如每90天）更新；
SQL注入防护：所有数据库查询必须使用sqlx.NamedExec（参数化查询），禁用字符串拼接；
XSS过滤：backend/app/middleware/xss_middleware.go已内置HTML标签过滤，但需确保所有用户输入字段（如商户店名）在入库前调用html.EscapeString()；
敏感信息加密：merchant.bank_account等字段，使用AES-256-GCM加密存储，密钥由KMS托管；
日志脱敏：backend/app/middleware/log_middleware.go中，对req.Header.Get("Authorization")和req.Body中的手机号、身份证号正则替换为***；
DDoS防护：在Nginx配置中启用limit_req zone=api burst=20 nodelay，限制单IP每秒最多20次API请求。