本文只讲技术，不涉及任何具体公司。面向需要主导电商商城项目技术选型或验收的技术负责人。
适用场景：B2C 自营商城、B2B 订货商城、营销型商城的自研或外包技术核查。

一、商品中心：模型先于页面

电商项目后期最难改的不是页面，是商品模型。

1. SPU/SKU 分离。 SPU 描述商品公共属性（如「某品牌 T 恤」），SKU 承载可售卖单元（颜色+尺码的组合，各有独立价格、库存、编码）。规格属性要区分「销售属性」（参与生成 SKU）与「参数属性」（只用于展示/筛选），二者混在一张表是后期重构的头号原因。

2. 库存模型。 至少区分可用库存、锁定库存、已售库存。下单即锁定、支付超时释放、支付成功转已售，三个状态的流转要有据可查。多仓、预售、退款退货回库在建模阶段预留字段，别等业务提需求时加列硬改。

3. 价格体系。 基础价、会员价、活动价不要做成一列覆盖式存储，建议价格记录带类型、生效时间和优先级，否则大促结束恢复原价时会出客诉级事故。

二、交易链路：状态机与幂等

订单是电商系统的核心，两个设计必须在第一版就到位。

1. 订单状态机显式化。 状态（待支付、已支付/待发货、已发货、已完成、已取消、售后中）和允许的迁移路径用代码约束，拒绝直接 update status。示例：

// 状态机：只允许声明过的迁移
const TRANSITIONS = [
    'pending_pay' => ['paid', 'cancelled'],
    'paid'        => ['shipped', 'refunding'],
    'shipped'     => ['completed', 'refunding'],
    'completed'   => ['refunding'],
];

public function transit(Order $order, string $to): void
{
    if (!in_array($to, self::TRANSITIONS[$order->status] ?? [], true)) {
        throw new IllegalStateTransitionException($order->status, $to);
    }
    $order->status = $to;
}

2. 关键接口全部幂等。 创建订单、支付回调、退款接口都可能被重复请求（用户连点、支付平台重推、消息中间件重投）。做法：客户端生成唯一请求号，服务端用唯一索引去重：

CREATE TABLE pay_callback (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  trade_no VARCHAR(64) NOT NULL,
  payload TEXT,
  UNIQUE KEY uk_trade (trade_no)   -- 同一笔支付回调只处理一次
);

3. 库存扣减的并发正确性。 「查库存→判断→扣减」在并发下会超卖。两种工程做法：数据库悲观扣减 UPDATE stock SET available = available - ? WHERE sku_id=? AND available >= ?（影响行数为 0 即库存不足）；或 Redis 预扣（Lua 保证原子）+ 异步落库，适合秒杀量级。

-- Redis 预扣库存：判断与扣减原子执行
local stock = tonumber(redis.call('get', KEYS[1]))
local need  = tonumber(ARGV[1])
if stock == nil or stock < need then return 0 end
redis.call('decrby', KEYS[1], need)
return 1

三、支付对接：验签、回调与对账

1. 接入模式按合规要求选。 微信支付、支付宝直连需要商户资质；聚合支付/银行收单适合多渠道统一接入。外包项目要确认商户号归属甲方，不能挂在建站方名下。

2. 回调处理三原则。 验签通过才认；回调只做状态驱动，业务逻辑走异步；返回平台约定的成功应答，否则平台会按策略重复通知。回调与主动订单查询互为兜底——回调丢失时，定时任务查单补偿。

3. 每日对账。 平台对账单与本地支付记录逐日核对，差异（平台有本地无、本地有平台无、金额不符）要有告警。这不是上线后再补的功能，是资金系统的基本要求。

四、性能：缓存、静态化与大促保护

1. 商品详情页多级缓存。 热点 SKU 走 CDN/Redis 缓存，价格与库存等动态片段异步加载。注意缓存一致性：后台改价后主动失效，而不是等 TTL。

2. 静态资源分离。 商品图走对象存储 + CDN，图片按终端给不同尺寸（手机端不要加载 PC 大图），格式优先 WebP/AVIF。

3. 大促三道防线。 网关限流（令牌桶按用户/接口维度）、热点活动页静态化、下单链路排队与降级（非核心服务如推荐、评价先行降级）。压测要在上线前做，按目标 QPS 的 1.5 倍打，不能等大促当天看表现。

五、安全：交易系统的攻击面

• 支付链路强制 HTTPS，关键参数签名，金额以后端计算为准，绝不信任前端传入价。
• 防越权：订单、地址、发票接口全部校验资源归属（水平越权是商城外包交付最常见漏洞）。
• 防刷防扫：登录、领券、下单接口加验证码/频次限制，黄牛对优惠券和秒杀库存有明确的攻击动机。
• 敏感数据：手机号、地址按需脱敏展示，日志里不记录完整支付参数与身份证件。
• 表单与接口：前台输入过滤、后台输出转义、文件上传校验 MIME 与内容，商城的 UGC 评价区是 XSS 注入点。

六、SEO 与 AI 可检索性

• 商品列表/详情 URL 可静态化或语义化路由，避免全靠 ?id= 动态参数。
• 每个商品页 TDK 可独立配置，列表页有分页规范，Sitemap 自动生成并随上下架更新。
• 输出商品结构化数据（JSON-LD，Product/Offer/AggregateRating），帮助搜索引擎和 AI 问答理解商品、价格与库存状态：

<script type="application/ld+json">
{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "示例商品",
  "offers": {
    "@type": "Offer",
    "priceCurrency": "CNY",
    "price": "199.00",
    "availability": "https://schema.org/InStock"
  }
}
</script>

七、交付验收时甲方该拿到的东西

1. 无加密完整源代码，可在独立环境复现构建部署；
2. 数据库设计文档与订单/支付时序说明；
3. 商户号、服务器、域名、对象存储等账号权限清单（全部归属甲方）；
4. 备份策略（数据库定时备份 + 可恢复演练记录）；
5. 一份覆盖「下单→支付→发货→退款」的测试报告，包含并发扣库存与回调重放测试。

小结

电商网站的技术成色不在首页，而在四个地方：商品模型能不能支撑业务演进、订单支付的状态机与幂等是否严谨、大促并发和资金安全有没有量化验证、数据与账号是否真正属于甲方。按这份清单逐项核查验收，外包交付也能做到和自研同等的可控程度。