首页 / 技术

技术与安全底座 · 支撑小程序

把「不容易出错」
做进工程流程里

这套后端服务的就是那一个微信小程序:它要能同时扛住下单、支付、履约、内容发布和安全上报。 陪的是真人,过的是真钱,处理的是真出事,所以有一条底线: 宁可显性失败,不可静默出错。金额口径、角色边界、数据模型、发布流程, 每一样都只留一个来源,而且能被脚本自动验一遍。

Express + TypeScript Prisma + MySQL 四个唯一来源 发布前自动校验
工程原则

四条不许破例的规矩

不是建议,是写进代码结构和发布脚本里的硬约束。有了它们, 「这次改动会不会把小程序的账算错、会不会把用户位置泄露出去」这类问题,在评审阶段就答得上来。

原则 01 · 口径唯一

金额、定价、费率,各只有一个来源

资金字段在库里一律存「分」,接口对外一律返「元」,换算只发生在指定的那几个地方; 服务者定价、平台抽佣、订单试算共用同一套函数。 哪里冒出了第二次计算,哪里就是缺陷。

DB 存分API 返元定价单一入口退款唯一出口
原则 02 · 边界集中

角色与权限不散落在业务代码里

普通用户、陪陪、商户、谁能看后台,全由集中定义的角色模块说了算, 业务代码只声明「这里要什么角色」,自己不判断。 「某个接口忘了加判断」这种越权最难被发现,这样写就不会有。

集中角色定义接口声明式校验越权即拒绝
原则 03 · 发布前自检

结构漂移与接口健康,上线前先跑一遍

发布前自动比对代码定义和数据库实际结构,缺列、类型不符会直接输出待执行语句, 再由幂等脚本补齐;同时把所有模块的接口巡检一遍, 把「改完才发现」变成「改前就拦住」。

结构漂移校验缺列自动登记全模块冒烟失败即中止
原则 04 · 失败显性

不用默认值掩盖错误

接口错了就报错,不返回空数组让前端渲染成「这里本来就没有内容」; 没数据就写明「新加入」,不显示零分,也不留空。 空表和故障得能分得出来,信任才有落脚点。

错误可区分空态有文案不做沉默降级
系统架构

分层清晰,替换成本低

最上面是小程序,往下依次是接口、业务域、数据访问与外部服务, 每层只做自己的事:客户端不掺业务逻辑,业务逻辑不掺数据访问。 换支付渠道、换地图服务、换对象存储,每次只动一个接入点,不会牵着小程序里一片业务域一起改。

客户端层
微信小程序(唯一面向用户的入口)商户工作台(小程序内)运营治理后台(内部)
接口层
Express 路由(按业务域拆分)鉴权与角色校验参数校验请求限流统一异常处理响应封装
业务域层
账号与实名服务者与商户订单与履约资金与结算退款与纠纷内容与审核活动与报名安全与处置营销与优惠券消息与订阅
数据访问层
Prisma ORM(单一数据入口)事务封装幂等写入结构漂移校验列类型守护
数据存储
MySQL对象存储(图片 / 视频)缓存(首页与配置)
外部服务
微信登录与手机号微信支付与回调订阅消息腾讯位置服务(地图与路线)备案视频播放插件
可靠性能力

真实业务里躲不掉的那些坑

下面这些都已经在跑,不是规划里的承诺。

支付渠道自动就位

支付渠道在首次使用时自动初始化,空库不会出现「渠道不存在」;初始化失败会清空缓存并如实抛出,避免一次瞬时故障把支付功能永久挂死。

支付链路有硬超时

调微信收银台的整个过程带超时兜底和回调守卫。收银台出问题时,用户会收到一个明确结果,不会一直卡在「加载中」。所谓「点了没反应」,多半就出在这里。

退款唯一出口

所有退款走同一条链路:按订单实际支付与优惠构成试算金额,完成后由结单逻辑锁定状态,杜绝重复退款与超额退款。

数据模型不会被静默收窄

富文本、图片列表、用户内容这类字段按写入上界挑存储类型,发布前再核一遍类型和库内现状是否一致,免得迁移时不声不响把长文本截断。

订阅消息可靠触达

站内信落库即异步下发订阅消息,令牌集中管理防止互相顶掉;用户未授权或模板未配置时静默跳过,不影响主流程。

启动即校验运行环境

服务启动先查关键配置是不是占位值或弱值。非开发环境一律拒绝启动,免得线上带着演示密钥跑。

限流与鉴权按场景隔离

不同入口使用独立的限流与鉴权通道,避免后台的一次异常登录尝试影响到小程序的正常认证。

关键节点留痕

审核结论、订单状态、资金流转、事故处置等关键动作均记录操作者与时间,配合履约证据链,做到事后可复核。

数据与合规

实名、位置、联系方式,都按「最小必要」收

实名信息、联系方式、位置,都算敏感数据。小程序声明要用的隐私接口只有定位与地图选点两项, 所以我们守三条:只收服务必需、授权时讲清场景、 敏感项单独勾选,可以撤回。

最小必要

定位只用在三件事上:自动匹配所在的城市站、发布活动时选集合地点、路线页取起点。小程序申报的隐私接口只有定位与地图选点这两项,通讯录、相册、录音都不在申请之列。

位置分级可见

服务者的常驻位置由本人在地图上选点,用户侧只显示地名,坐标不随详情页下发;发布活动时选定的集合地点坐标,只用来在详情页算路线。

传输与存储

微信与支付的凭证只从环境变量注入,不写进代码、也不落进数据库配置项;生产环境启动前会校验关键配置,占位值或弱值一律拒绝启动。

访问边界

后台不提供用户实时轨迹的查看入口;账号按角色最小授权,权限边界集中定义,越权请求直接拒绝;审核、资金、事故处置这类关键操作记录操作人与时间。

内容合规

用户发布内容先审后展示(或发布后即时进入审核队列),违规内容可下架并级联处理关联评论,审核结论通知到发布者。

处置透明

事故受理后向当事人同步结论性状态,不公开事件细节;处置结果影响服务者状态时,在用户侧以事实陈述呈现,不使用营销标签替代。

说明:以上是产品与系统的设计原则和已实现机制。备案、认证与资质的具体状态,以官方公示和合同约定为准; 本页不构成任何合规认证承诺。

工程工具链

让每次发布都可被验证

平台自带一套巡检与修复工具,每次上线前跑一遍。有疑问就翻证据,不靠「应该没问题」。

全模块接口巡检

一次性遍历全部模块的接口,只把 5xx 视为失败——发布前 3 分钟就能知道「有没有把哪个接口跑挂」。

结构漂移校验

比对代码定义与数据库实际结构,输出待执行语句并拦截危险变更(例如把长文本列改窄)。

幂等修复脚本

缺列、类型不一致由幂等脚本补齐,可重复执行;失败即中止后续步骤,不会带着半成品上线。

前端离线自检

静态资源引用、标签结构、样式语法、内联脚本,提交前统一过一遍,页面不会因为一处笔误整页白屏。

技术合作

需要技术方案或
系统对接说明?

接口清单、字段口径说明、联调支持,我们都能提供。直接找我们就行。

接口文档按业务域分组,附字段口径说明
联调支持沙箱环境与测试账号