现场笔记:跨后端、网页与移动端运营电商平台

一次针对正在运行的电商平台所做的加固记录——Django 后端、网页商城,以及基于 Capacitor 构建的 iOS/Android 应用,工作期间始终有真实客户在下单。

两笔订单。同一件商品,同一个收货地址,下单时间只相差一分钟。一笔来自网站,另一笔来自手机 App。

网站预订的快递费用是 ฿37。App 却选择了自营配送(in-house),费用 ฿25——可自营配送根本没办法送到那个地址。系统没有崩溃,日志里也没有任何错误记录。两位顾客,得到了两种截然不同却毫无提示的结果。之所以能发现,唯一的原因是团队养成了把真实订单相互核对的习惯,而不是想当然地认为"某个平台能跑通就没问题"。

这正是多平台电商最典型的故障模式——真正致命的不是那些会崩溃的 bug,而是那些悄悄"各说各话"的 bug。后端负责计算价格、折扣与运费;网页商城必须把这些结果准确渲染出来;手机 App 要在完全不同的技术框架、完全不同的平台规则下,独立算出同一个答案;而两个应用商店,只要少一个元数据文件,就会直接拒绝你的构建包。这篇文章记录的,正是最近一次横跨这三层、在真实运行的平台上追查这类"分歧"的加固过程。这正是我们 Simplico 为电商客户日常提供的服务——不是演示环境,而是在真实结账流程持续运行的生产系统上完成的工作。

后端:正确性真正落地的地方

后端决定一笔订单的运费、快递方式与折扣——这里出错是代价最高的一类 bug,因为它会直接体现在顾客的付款金额上。

大部分商品的运费计算都在悄悄失败 平台通过把购物车里的商品做三维装箱(3D bin-packing),模拟装入标准尺寸的箱子,再拿计算结果去请求快递商的报价 API——但只要有一件商品在商品目录里缺少宽、高或长中的任意一项,装箱程序就会悄悄返回"零个可用箱子",而不是报错。抽查发现,556 个商品规格(variant)中有 485 个存在这种情况。没有箱子,就没有报价,结账流程于是在日志里没留下任何解释的情况下,回退到自营配送。我们把装箱这一步替换成了一套更具容错性的"整体包裹"计算逻辑,只要有任何可用的尺寸数据,就总能算出一个可用的报价——目录里的数据缺口,现在只会让结果优雅降级,而不是悄悄把订单导向错误的配送方式。

支付对账需要一个唯一可信的来源 平台接入了两个支付网关,中间还有一条容错回退路径;而支付完成后的一系列动作——扣减库存、发送确认邮件、预约快递——无论最终是哪个网关实际处理了这笔付款,都必须一致地执行。我们把这些逻辑收拢进同一条共享路径,并在运营后台加了一个清晰可见的支付网关标识,让客服人员能一眼看出某笔订单究竟是哪个网关处理的。

结账崩溃的根源在数据,不在代码 一处促销活动的查询逻辑用了 .get(),而数据结构上其实允许出现重复记录——只要没有活动真的产生重复数据就相安无事,可一旦发生,就会抛出一个从外部看起来像是支付失败的异常,直接让整个结账流程崩溃。我们把这处查询改成了始终返回确定结果,而不是随时可能抛异常的写法。

网页端:让本该"可交互"的那一层真正可交互

商城的结账页面,是在服务端渲染的 Django 模板之上,叠加了一层轻量的响应式框架(Alpine.js)——这是个务实的做法,但有一个特别容易踩的坑:你完全可以把可交互的标记拼成字符串再注入页面,它会渲染得完美无瑕,却什么都不会真正生效。 配送方式的单选按钮正是栽在这里——它们被拼成原始 HTML 字符串,再通过类似 innerHTML 的指令注入页面,而这种方式永远不会重新解析注入内容里的交互绑定。它们在每一张截图里都显示正常,却在不知道多长的一段时间里完全失效。我们把它重写成了真正会被正确编译的模板标记。

同样的教训还以更隐蔽的形式出现了两次:服务端渲染的条件判断和客户端渲染的条件判断,互相嵌套时并不安全。 一次出在只有"零已保存地址"的顾客才会看到的新增地址表单上,另一次出在需要"有可选优惠券"才会显示的优惠券模块上——两种情况都让客户端框架持有了一个指向"服务端其实根本没渲染出来"的元素的引用。我们重新梳理了结构:是否存在某个区块,由服务端决定;而客户端只负责决定怎么展示它。

移动端:两个平台,两套规则,一个产品

移动端要多缴一份网页端不用缴的"税":平台方既是合作伙伴,也是把关人,而他们的规则会在你毫不知情的情况下发生变化。

App Store 拒审,错误码 ITMS-91061 苹果现在要求应用必须声明隐私清单,说明为什么会调用某些"容易被滥用"的 API——而依赖树里有五个第三方 SDK 都没有自带这份清单。最直接的解决办法在真实的构建流水线里根本行不通:每次安装依赖,那个你想直接放文件进去的文件夹都会被重新生成一遍。于是我们做了一套更持久的方案——把清单文件纳入版本控制,每次安装依赖时自动注入并注册到对应目录,并且验证过反复构建多次结果依然一致。

Google Play 的政策要求和 Android 16 的适配截止日期,同一周撞在了一起 应用的相机相关依赖库,不论功能是否真的用到,都会无条件声明大范围的相册访问权限——这正是 Play 审核越来越会主动标记的模式。我们把照片和视频的选择功能迁移到了平台自带的系统选择器,完全不需要申请任何运行时权限,同时也在 Play 的强制期限前,把目标 SDK 升级到了 Android 16。这两处都用真机日志做了验证——一开始对旧插件权限行为的判断其实是错的,只有跟踪真机日志才发现了这一点。

登录功能在 Android 上正常,在 iOS 上却在悄悄失败 原因是配置里少了一行——请求身份令牌时,受众(audience)配错了——这个问题不去检查令牌本身的实际内容,根本看不出来。

还有开头提到的那笔订单 移动端的结账逻辑里,藏着一段网页端没有的代码:永远选择两个配送选项里更便宜的那个——哪怕那个更便宜的选项根本送不到顾客的地址。如果两个平台是各自独立开发的,这种问题非常容易被忽略;但只要拿真实订单数据把两个平台的结果互相对照,就很容易揪出来——这次也正是这样被发现的。

更改 API 的域名,现在已经不再需要走应用商店审核 我们在 App 启动流程里加了一步远程配置:每次启动,App 都会去一个很轻量的配置端点确认自己该用的 API 域名,并立即生效;如果检查失败,还会安全回退到备用值。过去要改域名,意味着重新构建再提交商店审核——起码要等上好几天——现在只是服务端的一行改动,顾客下次打开 App 时就会立刻生效。

性能:那些没人看得见的部分

正确性上的 bug 会被反馈——顾客看到价格不对,会说出来。加载慢的页面却几乎不会被反馈,顾客只会默默离开,日志里也不会留下任何原因。所以这部分工作从一开始就是一次全站审计,而不只是找 bug:并行审查了数据库查询、缓存、后台任务这三个方向,再按实际测得的影响大小、而不是猜测来排优先级。

某位顾客的订单历史页面,加载一次要 9.7 秒,发出 1,746 条数据库查询 原因是两层 N+1 问题叠在了一起:一层是订单明细和对应商品完全没有做预取(prefetch);另一层更隐蔽——那些本该已经预取好的关联数据,被后面链式调用的一个看似无害的 .order_by() 悄悄绕过,直接跳过了 Django 的预取缓存,重新打到数据库。两层问题都修复之后:3.5 秒,406 条查询——数据库负载降低了 77%。

一场正在进行的限时促销,把某个页面拖慢到了几乎无法使用的地步 分类列表页上的每一件商品,都在各自独立地重新计算"现在到底有哪些促销活动在生效"——完全相同的计算,每个商品都要重复一遍,每次页面加载都要重复一遍。我们把这个答案改成每次请求只计算并缓存一次。某个分类页的加载时间从 10.2 秒降到了 0.85 秒。

一个出现在每个页面上的菜单,竟然是服务器上开销第二大的东西 性能分析发现,某个页面大约四分之一的渲染时间,都花在了递归重建一个包含 209 个分类的下拉菜单上——而且是每次请求都重建一遍,尽管这个分类结构几乎从不变化。因为这个菜单位于所有页面都继承的基础模板里,一次性加个缓存片段就解决了问题,而且这个效果是全站生效的,不只是被分析的那一个页面。

还有本文前面提到的那些未压缩原图 ——那张 3.9MB、现在只需 14.9KB 就能送达的轮播 banner——其实是同一套思路用在了另一层上:图片本质上也是一种"查询",不做缓存和压缩,同样会很贵。

不是每一个提出的优化方案都真的有用,与其把数字说得好看,我们更愿意如实说明。有一处缓存改动,实现了、也测量了,但对目标页面没有任何实质改善——因为被缓存的值本来每次请求就只会被读取一次,根本没有重复可以省。我们还是保留了这处改动,因为在测量过程中顺带发现并修复了一个真实存在的正确性 bug。这一项的性能数字老老实实是零,我们也就如实记录成零。

贯穿始终的那条线

这里提到的每一个问题,单独看都算不上多离奇:少了一行配置、一个声明了过多权限的插件、一处 innerHTML 的捷径、一段只在一半使用场景里成立的价格比较逻辑。它们真正值得被揪出来的原因,是它们都藏在"接缝"处——后端与前端之间的接缝、网页与移动端之间的接缝、平台方今年要求的东西与代码去年默认成立的假设之间的接缝。单独看都很小。但累积起来,就是"大体能用的商城"和"真正靠得住的商城"之间的差距——就是同一笔订单,两位顾客拿到两个不同价格,与不会发生这种事之间的差距。

缝合这些接缝——让后端、网页和移动端,在真实的生产系统上始终保持一致——正是我们 Simplico 在做的事。如果你正在运营一个电商平台,想找一支把"只在一个平台上能用"当作 bug 报告、而不是当作里程碑来对待的团队,这正是我们 电商工程服务 存在的意义。