1. 先搞清楚这次 v1.1 到底改了什么
手上这套 B2C 电子商务系统升到 1.1 版，同行第一反应往往是"又加了多少个功能入口"。但我把变更清单从头翻到尾，感受最深的不是新功能数量，而是这次升级的重心明显偏向了另一侧：功能升级与优化里，"优化"两个字占的分量比"升级"更重。旧版能跑通从商品上架到收款发货的整条主链路，这是底线；1.1 版要解决的是这条主链路上那些平时不显眼、一到活动大促就集中爆发的卡点——下单抖动、优惠叠加算错、后台列表越翻越慢、模板改了不生效、迁移之后支付回调收不到。
这套系统本身是典型的 PHP + MySQL 架构，前端走模板渲染，后台是标准的 MVC 分层，商品、订单、会员、营销、支付、物流几个模块耦合度不低。这类项目的升级最怕两种情况：一是"推倒重写"，二是"只改表面"。前者风险不可控，后者等于没升。我在下面会把这次 v1.1 的设计取舍、关键模块的实现要点、从旧版迁移的完整实操流程、以及性能和安全上的补丁，一条条摊开讲。
适合谁来读？如果你手上有类似的老商城系统要做版本迭代，或者你正在接手一套别人写了一半的 B2C 项目，再或者你只是想弄明白"一个商城系统为什么要这样设计订单状态和促销规则"，这篇内容应该都能给你省点时间。我不打算写成产品说明书的语气，就按实际动手的顺序来。
1.1 从"能卖货"到"卖得顺"：需求到底从哪来
1.1 把需求摊开看：真实痛点比功能清单重要
我习惯在动手改代码前，先把需求按"谁在用、什么时候用、出问题会怎样"三个维度过一遍。这次 v1.1 的需求大致能归成四类，每一类的来源都不一样。
第一类是商家侧的后台效率。旧版后台的商品列表、订单列表在数据量上万之后翻页明显变卡，运营改一个价格要等页面刷新三四秒，批量操作经常点完没反应。这类需求不是"加功能"，是"减摩擦"。
第二类是买家侧的下单体验。旧版购物车到结算页的跳转是整页刷新，选个优惠券要重算一次总价，网络稍差就白屏。移动端占比上来以后，这个体验问题被放大了好几倍。
第三类是营销规则的准确性。满减、折扣、优惠券、包邮这几套规则在旧版里是各自独立判断的，叠加时的优先级没有明确定义。运营配了一个"满 199 减 30 再叠加 9 折券"的活动，实际算出来的金额和预期差了几块钱，客服每天都要解释。
第四类是可维护性。旧版把不少业务逻辑写在了模板层和控制器里，改一个运费规则要动三四个文件，改完还得祈祷别的地方没被牵连。
把这四类摆在一起就能看出，v1.1 的核心命题是把散落在各处的规则收敛成有明确边界的模块，同时把链路上最慢的几个点掐掉。功能清单上的"新增 xx 管理""支持 xx 展示"都是这条主线的副产品。
提示：接手别人的老商城系统，别急着看功能列表。先花两小时把"加购—结算—支付—发货—退款"这条链路在测试环境完整走三遍，你会比看十页文档更快找到真正的痛点。
1.2 技术路线怎么选：为什么走渐进式改造而不是重写
这套系统要升级，摆在面前的路其实只有三条。
第一条是推倒重写，换框架、换数据库设计、前后端分离。好处是架构干净，坏处是周期以月计，且老数据迁移、老模板兼容、老插件生态全部要重新处理。对于一个还在产生订单的系统，停摆一周的代价就已经很难接受了。
第二条是只做加法，原样保留老代码，新功能外挂插件。这样上线快，但技术债越滚越大，性能问题一个也解决不了，等于把炸弹往后推。
第三条是渐进式改造：保持目录结构和路由规则不变，把最痛的几个模块原地重构，把慢查询和重复渲染掐掉，把新增能力做成可插拔的组件。我最终选了这条。
选择它的理由很实在：升级的可回滚性比升级的彻底性更重要。渐进式改造的每一步都是可单独验证、可单独回滚的，出问题最多影响一个模块；重写则是一荣俱荣一损俱损。另外这套系统的模板层已经被商家改过不少，保持模板标签的向后兼容，能省掉大量沟通成本。
具体到代码层面，改造遵循三条纪律：
- 控制器只做参数校验和调度，业务判断下沉到服务层，禁止在控制器里直接写 SQL。
- 模板层只做展示，不允许出现价格计算、库存判断这类逻辑。
- 所有跨表写操作收进事务，尤其是下单、支付回调、退款三条路径。
这三条听起来是老生常谈，但真正落到一个历史项目里，光是"把控制器里的 SQL 挖出来"这一件事，就占了这次改造相当大的工作量。
1.3 影响范围盘点：哪些地方会被牵动
升级前我把影响范围列了一张表，这张表后来救了我至少两次。做老系统升级，最怕的不是改错，是改完之后忘了某个角落也在读同一份数据。
| 影响面 | 具体位置 | 风险等级 | 处理方式 |
|---|---|---|---|
| 数据库结构 | 商品表、订单表、优惠券表新增字段 | 高 | 增量 SQL，不动老字段，保留默认值 |
| 模板标签 | 商品列表、购物车、结算页 | 中 | 保留老标签，新增标签并行 |
| 支付回调 | 异步通知地址、签名校验 | 高 | 新旧回调地址同时可访问 |
| 缓存键 | 商品详情、首页楼层、分类树 | 中 | 统一加版本前缀，避免脏读 |
| 定时任务 | 订单超时关闭、库存回补 | 高 | 任务脚本与业务逻辑解耦后单独验证 |
| 伪静态规则 | 商品、分类、文章详情页 | 低 | 规则不变，仅新增跳转兼容 |
这张表的价值在于：它把"我要改什么"变成了"我改完之后要验证什么"。每完成一项，就在对应行打个勾并补一条验证记录，升级结束时这张表本身就是一份验收清单。
注意：缓存键前缀这一项特别容易被忽略。老系统的缓存键往往是
goods_123这种裸写法，新版本如果改了商品数据的结构却沿用同一个键，上线瞬间就会出现"价格显示了旧值"的诡异问题，而且刷新页面也不一定复现，排查极其痛苦。
2. 核心模块拆解：功能升级落在哪些具体位置
这一章讲实现。我会挑四个改动最大、也最容易出问题的模块展开：商品与规格模型、订单状态机、促销规则引擎、支付回调。其他的像会员等级、物流模板、后台权限，思路类似，就不逐个铺开了。
2.1 商品与规格模型：把"一个商品多种规格"讲清楚
旧版的商品规格处理方式比较粗糙：商品表里存一个总库存，规格信息用一段序列化字符串塞在某个字段里，前端展示时再反序列化。这种做法在只有两三种规格时还能凑合，一旦出现"颜色 5 种 × 尺码 4 种"这种组合，库存就没法精确到单个 SKU，超卖几乎必然发生。
v1.1 把它拆成了三层：
- 商品主表：存标题、主图、类目、品牌、上下架状态、基础价，这些是所有规格共享的。
- 规格项表：存"颜色""尺码"这类规格名，以及每个规格下的具体值。
- SKU 表：存规格组合、独立价格、独立库存、独立编码、独立图片。
拆完之后最关键的一步是库存扣减必须落在 SKU 维度。这里我用的是带条件的原子更新，而不是"先查再改"：
UPDATE goods_sku SET stock = stock - 2 WHERE sku_id = 1024 AND stock >= 2;执行完检查影响行数，返回 0 就说明库存不足，直接抛业务异常回滚事务。这样即使两个请求同时进来，也不会出现把库存扣成负数的情况。
// 服务层扣减库存（伪代码，标注语言类型便于阅读） $affected = $db->execute( 'UPDATE goods_sku SET stock = stock - ? WHERE sku_id = ? AND stock >= ?', [$num, $skuId, $num] ); if ($affected === 0) { throw new BizException('库存不足，请调整购买数量'); }这里的stock >= ?是整条语句的灵魂。很多人写WHERE sku_id = ?就完事，然后把判断放在 PHP 里，高并发下必然超卖——因为"查"和"改"之间有时间窗口。
规格组合的展示是第二个坑。前端选规格时，需要实时判断哪些组合是"有货可点"、哪些是"置灰"。我的做法是渲染商品详情时一次性把所有 SKU 的库存状态打包成 JSON 塞进页面，前端点选时纯靠本地计算，不再请求接口。代价是页面体积大了几 KB，收益是选规格的响应速度从 300ms 级别降到接近零延迟。
实操心得：SKU 表一定要加
(goods_id, spec_hash)的唯一索引，spec_hash是把规格组合按固定顺序拼起来算的哈希值。没这个索引，后台保存商品时可能因为重复提交生成两套一样的 SKU，之后库存对不上账会非常难查。
2.2 订单状态机：为什么不能用一个字段随便改
旧版订单只有一个status字段，取值 0 到 6，含义写在某个注释里，谁都能改。结果就是：已经退款的订单还能被改成"已发货"，已完成的订单能被客服手动改回"待付款"，财务对账时经常发现状态和流水对不上。
v1.1 把订单状态收成了显式的状态机。核心思路是状态只能通过预定义的动作迁移，不能直接赋值。
| 当前状态 | 允许动作 | 目标状态 | 触发方 |
|---|---|---|---|
| 待付款 | 支付成功 | 待发货 | 支付回调 |
| 待付款 | 超时取消 | 已关闭 | 定时任务 |
| 待付款 | 用户取消 | 已关闭 | 用户 |
| 待发货 | 发货 | 已发货 | 后台 |
| 待发货 | 申请退款 | 退款中 | 用户 |
| 已发货 | 确认收货 | 已完成 | 用户/自动 |
| 退款中 | 退款通过 | 已退款 | 后台 |
实现上我用了一张迁移表来约束，动作执行前先查表，不在表里的组合一律拒绝：
$allowed = [ 'pending_pay' => ['pay_success' => 'pending_ship', 'cancel' => 'closed'], 'pending_ship' => ['ship' => 'shipped', 'apply_refund' => 'refunding'], 'shipped' => ['confirm' => 'finished'], 'refunding' => ['refund_ok' => 'refunded', 'refund_reject' => 'pending_ship'], ];这样做的直接好处是动作日志天然完整。每次迁移都往order_action_log写一条记录，谁在什么时间、用什么身份、把订单从哪个状态推到了哪个状态，全都有据可查。客诉时不用再靠猜。
还有一个容易被低估的细节：订单关闭时的库存回补必须幂等。定时任务扫超时订单，如果任务因为某种原因重跑了一次，库存就会被补两次。解决办法是在订单表上加一个stock_returned标记，回补前先做条件更新：
UPDATE orders SET stock_returned = 1 WHERE order_id = ? AND stock_returned = 0;返回影响行数为 1 才继续往下走，为 0 说明已经补过了，直接跳过。这个模式在支付回调、优惠券退还等场景里可以反复套用。
2.3 促销规则引擎：优惠叠加为什么总对不上
促销这块是这次改造里最费脑子的部分。旧版的做法是每个促销类型写一个函数，各自判断能否使用、各自算减免金额，最后直接把结果相加。表面上没问题，实际一叠加就乱：
- 满减和折扣券同时可用时，先算减还是先算折，结果差几十块。
- 包邮和满减同时满足时，运费该不该免，逻辑分散在两处。
- 优惠券有使用门槛，但门槛是按原价算还是按折后价算，没有定义。
v1.1 把促销做成了规则链：所有可用规则先收集，再按固定优先级排序，逐条应用，每条规则只关心"在当前金额基础上我能减多少"。优先级顺序定为：单品折扣 → 订单满减 → 优惠券 → 运费减免。
举一个具体的例子说明计算过程。假设订单商品原价合计 320 元，用户有一张"满 300 减 40"的券，同时店铺在做"满 200 打 9 折"的活动，运费 12 元。
- 先算订单满减：320 ≥ 200，折扣后金额 = 320 × 0.9 = 288 元。
- 再判断优惠券：券门槛是满 300，当前金额 288 元，不满足，券不可用。
- 运费：无包邮规则，运费 12 元。
- 最终应付 = 288 + 12 = 300 元。
如果顺序反过来，先判断券再打折，结果就变成了 (320 − 40) × 0.9 = 252 元，差 48 块。这就是为什么优先级必须写死、必须可配置、必须记录在订单快照里。
订单快照是这块必须做的一件事。下单时把当时生效的每条促销规则、减免金额、计算顺序，序列化存进订单的promo_snapshot字段。之后无论后台怎么改活动配置，这笔订单的明细都能复现。用户来问"为什么是 300 不是 252"，直接调快照给他看。
注意：优惠券的"占用"和"核销"是两个动作。下单时先占用（状态置为锁定），支付成功才核销，订单关闭要释放。如果只做核销不做释放，用户取消一次订单，券就白扔了，这类客诉占比很高。
2.4 支付回调：最容易在上线当天出事的地方
支付回调的坑我踩过不止一次，所以这块单独拎出来说。旧版的回调处理逻辑大致是：验签 → 查订单 → 改状态 → 返回成功。看起来四平八稳，实际有三个隐患。
第一个是重复通知。支付渠道在没收到成功响应时会重发通知，短时间内可能来三五次。如果处理逻辑不幂等，订单会被重复改状态，库存重复扣，优惠券重复核销。解决办法是在处理入口先做一次原子占位：
UPDATE orders SET pay_notify_lock = 1 WHERE order_id = ? AND pay_notify_lock = 0 AND status = 'pending_pay';只有影响到行才继续处理，否则直接返回成功。这个写法和前面库存回补的思路是同一个。
第二个是验签用的密钥读错环境。测试环境和生产环境的密钥不同，配置文件里如果按环境变量读取，很容易在部署时漏改。我的做法是把密钥放在一个独立配置文件里，部署脚本强制校验，缺失就直接启动失败，宁可起不来也不要带着错密钥跑。
第三个是回调里的业务逻辑太重。旧版在同一段代码里做了改状态、扣库存、发短信、写积分、生成发货单，五件事串行。一旦最后一步因为外部接口超时失败，前面四步已经提交，订单就卡在中间状态。v1.1 改成：回调里只做验签和"标记支付成功"，其余动作全部丢进任务队列异步执行，队列消费失败可以重试，不影响订单主状态。
# 队列消费者启动（示例） php cli.php queue:consume pay_success --tries=5 --sleep=2这个改动让支付回调的响应时间从平均 800ms 降到 60ms 以内，超时重发的概率显著下降。
3. 完整迁移实操：从旧版本升到 v1.1 的落地步骤
这一章按实际操作顺序写，你可以直接照着走。假设你已经拿到新版本代码包和增量 SQL 脚本。
3.1 环境准备与全量备份
升级前第一步永远是备份，但"备份"这两个字包含的东西比很多人想的多：
- 数据库全量导出，包含结构和数据，导出后立刻在一个临时库导入验证一次，确认备份文件是好的。
- 上传目录打包，商品图、用户头像、订单附件都在这里，量大但必须打。
- 配置文件单独复制一份，尤其是数据库连接、支付密钥、短信配置。
- 记录当前版本号和当前线上代码的提交标识，回滚时要用。
# 数据库备份示例 mysqldump -u root -p --single-transaction --routines \ --default-character-set=utf8mb4 shop_db > /backup/shop_db_$(date +%Y%m%d%H%M).sql # 校验备份文件是否完整（能看到结尾的 Dump completed 才算成功） tail -5 /backup/shop_db_202401010200.sql--single-transaction这个参数别省，它能在不锁表的情况下拿到一致性快照，对还在跑业务的生产库很关键。
环境上还要确认几件事：PHP 版本是否满足新代码要求、MySQL 版本是否支持新用到的语法、缓存服务是否已启动、磁盘剩余空间是否够放新代码和日志。这四项任何一项不满足，后面都会以奇怪的方式报错。
3.2 增量 SQL 的执行顺序
增量脚本不是随便跑一遍就行，顺序错了会出问题。我这次用的顺序是：加字段 → 加索引 → 建新表 → 数据回填 → 加约束。
先加字段是因为老代码不认识新字段，但新字段有默认值，不会影响老代码运行；先加索引再回填数据，能让回填过程用上索引；建新表放在中间是因为它不影响老表；数据回填放在最后一步之前，保证新表有数据；加约束放在最后，避免回填过程中因为数据不合规而中断。
-- 1. 加字段（保留默认值，老代码无感知） ALTER TABLE goods ADD COLUMN sku_enabled TINYINT NOT NULL DEFAULT 0 COMMENT '是否启用多规格'; ALTER TABLE orders ADD COLUMN promo_snapshot TEXT NULL COMMENT '促销快照'; -- 2. 加索引（注意大表要评估执行时间） ALTER TABLE orders ADD INDEX idx_status_created (status, created_at); -- 3. 建新表 CREATE TABLE goods_sku ( sku_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, goods_id BIGINT UNSIGNED NOT NULL, spec_hash CHAR(32) NOT NULL, price DECIMAL(10,2) NOT NULL DEFAULT 0.00, stock INT NOT NULL DEFAULT 0, PRIMARY KEY (sku_id), UNIQUE KEY uk_goods_spec (goods_id, spec_hash) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;数据回填建议写成脚本而不是纯 SQL，因为要把老的序列化字符串解析成规格组合，纯 SQL 处理起来很别扭。回填脚本要支持断点续跑——按商品 ID 分页，每 500 条提交一次，记录已处理的最大 ID，中断了从断点继续。
注意：大表加索引在生产库上可能锁表。如果订单表已经几十万行，先看能不能用在线 DDL 工具，或者挑低峰期执行，并提前准备好回滚语句。
3.3 代码替换与缓存清理
代码替换这一步，我的习惯是先切目录再切入口。把新代码解压到一个新目录，配置好，单独用一个测试域名跑通，再把正式域名的入口指过去。这样出问题时把入口指回来就行，比在原目录里覆盖安全得多。
替换完成后必须清理的东西有这几类，漏任何一类都会出现"改了没生效"的诡异现象：
| 清理对象 | 位置 | 不清的后果 |
|---|---|---|
| 模板编译缓存 | runtime 或 cache 目录 | 页面还是旧样式 |
| 数据缓存 | 缓存服务中的业务键 | 商品价格显示旧值 |
| 伪静态规则 | 站点配置文件 | 新路由 404 |
| 操作码缓存 | PHP 扩展缓存 | 新代码不生效 |
| 浏览器缓存 | 静态资源版本号 | 用户看到旧 JS |
# 清理模板与数据缓存目录 rm -rf ./runtime/cache/* rm -rf ./runtime/temp/* # 清理缓存服务中的业务键（按前缀批量删，示例） redis-cli --scan --pattern "shop:goods:*" | xargs -r redis-cli del最后一条要小心，--scan配合xargs在键很多的时候会分批执行，别用keys *，那玩意在大库上会直接把服务拖死。
3.4 灰度验证与回滚预案
上线不等于结束，上线后的两小时才是关键。我一般按这个顺序验证：
- 匿名浏览：首页、分类、商品详情、搜索，四个页面各看一遍，确认没有报错和白屏。
- 下单主链路：用测试账号真实下一单，走到支付前一步，检查金额、运费、优惠是否正确。
- 支付回调：用渠道提供的沙箱环境走一笔完整支付，确认订单状态正确迁移、库存正确扣减、优惠券正确核销。
- 后台操作：改价、发货、退款各做一次，确认状态机和日志正常。
- 定时任务：手动触发一次超时订单关闭任务，观察库存是否正确回补。
回滚预案要提前写清楚，不能等出事再想。我的预案包含三部分：入口指回旧目录、执行反向 SQL、恢复上传目录备份。反向 SQL 只回滚新增字段和新增表，老字段老数据一律不动，这样即使回滚也不丢新产生的订单。
4. 性能优化：把慢的地方一个个掐掉
功能升级做完，如果不做性能优化，用户感受到的往往是"新版本变慢了"。这一章讲三个最见效的方向。
4.1 慢查询定位与索引补齐
优化的第一步不是改代码，是找到慢在哪。开慢查询日志，把阈值设成 1 秒，跑一天，然后按出现次数排序。
-- 查看慢查询是否开启及日志位置 SHOW VARIABLES LIKE 'slow_query_log%'; SHOW VARIABLES LIKE 'long_query_time';我在这套系统上抓到的头号慢查询是商品列表的筛选。旧版的写法类似这样：
SELECT g.*, c.name AS cat_name, b.name AS brand_name FROM goods g LEFT JOIN category c ON c.id = g.cat_id LEFT JOIN brand b ON b.id = g.brand_id WHERE g.status = 1 AND g.cat_id IN (3, 7, 12, 25) ORDER BY g.sort DESC, g.id DESC LIMIT 20;问题出在两处：一是cat_id IN (...)在大类目下会扫大量行；二是ORDER BY sort DESC, id DESC没有对应索引，只能全量排序后再取 20 条。补上(status, cat_id, sort, id)的联合索引后，执行时间从 1.8 秒降到 40 毫秒。
联合索引的字段顺序有讲究，原则是等值条件在前，排序字段在后。status和cat_id是等值筛选，放前面；sort和id是排序，放后面。顺序反了索引就用不上。
4.2 页面渲染与模板缓存
这套系统用的是模板渲染，每个页面请求都要编译一次模板再拼接数据。旧版在商品详情页上做了十几条独立的数据库查询（商品、SKU、评价、推荐、店铺、运费模板……），一次请求打出去十几个 SQL，页面耗时直奔两秒。
v1.1 做了两件事。第一件是合并查询，把详情页需要的关联数据改成批量查询，用IN一次取回，然后在 PHP 里按 ID 组装。第二件是给不常变的部分加缓存：商品的基础信息、规格列表、店铺信息缓存 5 分钟，评价和销量这类允许有延迟的数据缓存 30 秒。
缓存键统一加版本前缀，格式是shop:v{版本号}:goods:{id}。好处是版本升级时只需改前缀常量，所有旧缓存自动失效，不用去遍历删除。
模板编译缓存也要确认开启，编译后的模板文件要落到可写目录，并且检查目录权限。有时候"页面改不动"就是因为编译目录不可写，系统一直用旧的编译结果。
4.3 图片与静态资源处理
电商系统的页面体积大头永远在图片上。这次做了三处调整：
- 商品列表图统一生成缩略图，按列表实际显示尺寸生成，不再直接输出原图。列表页从 3.2MB 降到 800KB 左右。
- 图片加懒加载，首屏之外的图片滚动到可视区域才请求，首屏渲染时间明显下降。
- 静态资源加版本号后缀，比如
style.css?v=1.1.0，配合长缓存策略，用户第二次访问基本不用重新下载。
缩略图生成放在商品上传时同步做，而不是访问时动态生成。动态生成看起来省事，但一旦遇到缓存穿透，几百个请求同时去生成同一张缩略图，磁盘 IO 直接打满。
实操心得：缩略图文件名带上尺寸，比如
goods_1024_400x400.jpg。好处是换尺寸时不会覆盖原文件，测试调整样式时也不用来回删缓存。
5. 安全与稳定性：上线前必须自查的部分
5.1 老商城系统最常见的几个薄弱点
做这类系统升级，安全这块不用追求什么高深方案，把几个高频问题堵住就能挡掉绝大部分风险。
SQL 注入。老代码里拼接 SQL 的地方一定存在。我的处理方法是在数据库访问层统一强制预处理，并加一条规则：代码里出现query("... $var ...")这种直接拼接的写法，一律视为需要整改。检查时可以直接搜关键词定位。
上传文件类型校验。商品图上传如果只校验扩展名，攻击者把可执行脚本改成.jpg后缀就能上传。必须同时校验扩展名白名单、文件真实类型、文件头内容，并且上传目录禁止解析执行。
# 上传目录禁止执行脚本（示例配置） <Directory "/data/www/shop/uploads"> php_flag engine off Options -ExecCGI -Indexes </Directory>后台权限越权。旧版的权限判断只做在菜单显示层，直接请求接口还是能操作。v1.1 把权限校验下沉到每个控制器方法的入口，统一拦截，并在日志里记录越权尝试。
敏感信息泄露。错误页不要输出堆栈和路径，接口返回统一包装，异常统一捕获。调试开关必须在上线前确认关闭。
5.2 日志与监控：出问题时靠什么定位
我把日志分了三类，各写各的文件，互不干扰：
| 日志类型 | 内容 | 保留周期 |
|---|---|---|
| 访问日志 | 请求路径、耗时、响应码 | 7 天 |
| 业务日志 | 下单、支付、退款关键节点 | 90 天 |
| 错误日志 | 异常堆栈、SQL 错误 | 30 天 |
业务日志的重点是带上下文。一条下单日志至少要有订单号、用户 ID、商品 SKU、金额、耗时。没有这些，客诉时只能瞎猜。
监控上我盯三个指标：接口平均响应时间、支付回调失败次数、定时任务执行是否按时。这三个指标任何一项异常，基本都能提前发现问题，不用等用户来投诉。
6. 常见问题速查与踩坑记录
6.1 典型问题排查表
| 现象 | 可能原因 | 排查动作 |
|---|---|---|
| 页面显示旧价格 | 数据缓存未清、模板缓存未编译 | 清缓存目录，核对缓存键前缀 |
| 下单提示库存不足但后台有货 | SKU 库存未同步、主表库存与 SKU 不一致 | 对比 goods 与 goods_sku 库存，跑一致性脚本 |
| 支付成功但订单仍待付款 | 回调地址未更新、验签失败、异步任务未启动 | 看回调日志，确认密钥和队列进程 |
| 优惠金额与预期不符 | 促销优先级顺序、门槛判断基准不同 | 调订单 promo_snapshot 复算 |
| 新版页面样式错乱 | 静态资源版本号未更新、浏览器缓存 | 强刷验证，检查版本号参数 |
| 后台列表翻页很慢 | 缺联合索引、深翻页 offset 过大 | 看慢日志，改游标分页 |
| 上传图片失败 | 目录权限、类型校验过严、磁盘满 | 查错误日志和磁盘使用率 |
关于深翻页，这里多说一句。LIMIT 20 OFFSET 100000这种写法，数据库要先扫过十万行再丢掉，越翻越慢。改成游标分页，用上一页最后一条的 ID 作为起点：WHERE id < ? ORDER BY id DESC LIMIT 20，性能稳定。
6.2 我踩过的几个坑，你可能也会遇到
第一个坑：时区。订单时间显示差了 8 小时，查了半天发现是数据库连接时区和 PHP 时区设置不一致。下单时间、支付时间、发货时间全受影响，对账时特别麻烦。解决办法是在数据库连接建立后立刻执行一次时区设置，并且写进基础连接类，不让各处自己设。
第二个坑：金额精度。早先用浮点数存金额，做几次乘法之后出现了0.30000000000000004这种结果。后来全部改成DECIMAL(10,2)存库，PHP 侧统一用整数分计算，展示时再除 100。改完之后对账再没出过问题。
第三个坑：定时任务重跑。订单超时关闭任务因为服务器重启被执行了两次，库存被补了两次，导致实际库存比系统记录多。这就是前面说的幂等标记的必要性。加上stock_returned判断之后，重跑也不会出问题。
第四个坑：模板里写业务逻辑。接手时发现运费计算被写在了模板的if判断里，改一次运费规则要动三个模板文件。这次全部挪回服务层，模板只接收算好的结果。改完之后，同一个规则只需要动一个地方。
第五个坑：忘记处理并发下单同一件最后一件库存。两个用户同时下单，都显示库存充足，结果一个成功一个超卖。这个必须靠数据库层的条件更新兜底，应用层的判断再严密也有时间窗口。
6.3 上线后的收尾清单
升级完成后的头几天，我会盯这几件事：错误日志的新增条数、慢查询是否还有新增、支付回调的成功率、订单量是否异常波动、客服反馈的问题类型。前三天每天看一次，一周后恢复正常节奏。
另外把这次升级过程中的反向 SQL、回滚步骤、验证记录整理成文档归档。下次再升级时，这份文档就是最好的起点，比任何口头交接都管用。
我个人在实际操作中的体会是：这类老商城系统的升级，技术难度往往不在写代码上，而在"改完之后怎么确认没改坏"。把影响范围列清楚、把每一步的验证方式想好、把回滚路径留出来，剩下的就是耐心地一项项跑。慢一点没关系，跑通了就是稳的。
