接手一个PHP电商项目，无论你是从零搭建还是维护老系统，最先撞上的硬骨头永远是高并发下的库存扣减。别在代码里直接写“查询当前库存，判断是否大于0，然后减1并更新”。在并发请求下，两个进程可能同时读到库存为1，然后都认为自己能下单，最终导致超卖。正确的做法是利用数据库的行锁或原子更新。最简单的实现是在更新语句上做文章：
UPDATE `products` SET `stock` = `stock` - 1 WHERE `id` = ? AND `stock` > 0;
执行这条SQL后，马上判断受影响的行数。如果返回0，说明库存不足或已被抢光，直接抛出异常回滚事务。这种“乐观锁”变种方案避免了显式锁带来的性能开销，能扛住绝大多数并发场景。如果流量再大，比如秒杀，就得把库存缓存到Redis中，利用Redis的单线程特性，通过Lua脚本原子性地完成“判断-扣减”操作，然后再异步同步回数据库。
订单号的生成规则必须具有业务含义不要图省事直接使用数据库自增ID作为订单号展示给用户。自增ID虽然唯一，但暴露了业务体量，且无序的纯数字在分库分表时会引发灾难。成熟的电商系统通常采用雪花算法或其变体。但在PHP中实现雪花算法需要注意时钟回拨问题。更务实的做法是采用“日期+毫秒时间戳+用户ID后几位+随机数”的混合策略。例如：2023121714302018230012345。这种格式天然支持按时间分表，查询效率极高，且具备一定的防篡改能力。在代码层面，务必封装一个全局唯一的订单号生成器类，并在其中加入机器节点标识，防止分布式部署时重复。
商品SKU模块的数据库设计远比想象中复杂很多开发者栽在SPU和SKU的关系处理上。不要用一张宽表把所有规格属性平铺开，那样后续扩展属性时会频繁修改表结构。标准的做法是建立三张核心表：商品主表存储SPU信息和通用字段；规格属性表存储颜色、尺寸等可选项；SKU表存储具体的规格组合、价格、库存和图片。关键在于SKU表里的规格参数，不要存JSON字符串去糊弄查询。如果你需要根据“红色、XL码”快速定位SKU，建议增加一张规格索引表，或者在SKU表中冗余一个经过排序的规格摘要字段，比如“颜色:红|尺寸:XL”，并建立联合索引。这样在商品详情页切换规格时，接口能毫秒级返回对应的库存和价格。
购物车不能只靠数据库硬扛未登录用户的购物车数据如果直接写入数据库，会产生海量幽灵数据，且难以清理。正确的分层设计是：未登录用户将购物车数据存储在客户端的Cookie或LocalStorage中，前端直接读取渲染，减轻服务端压力。登录用户则采用“数据库+Redis”双写模式。Redis负责高频的增删改查，数据库作为持久化兜底。当用户在结算页时，后端必须做一次购物车数据的最终校验，重新从数据库拉取最新价格和库存状态，因为加入购物车时的价格可能已经失效。这一步校验是防止薅羊毛的关键防线，必须验证商品上下架状态、价格浮动阈值以及库存是否满足。
支付回调的幂等性是资金安全的生命线处理支付宝或微信支付的异步通知时，最大的坑是重复通知。支付平台为了保证通知送达，可能会在短时间内发送多条内容完全相同的回调。你的代码必须在业务逻辑处理前加上分布式锁。通常以订单号作为唯一键，在处理逻辑的开头尝试获取锁，如果获取失败说明正在处理中，直接返回“success”给支付平台即可。更严谨的做法是建立一张支付流水表，将回调的原始报文完整存入，并用交易流水号建立唯一索引。所有状态变更都放在数据库事务中，先插入流水记录（利用唯一索引防重），再更新订单状态，最后提交事务。任何一步失败都要回滚，绝对不能出现钱收了订单却显示未支付的情况。
优惠券系统要警惕“幽灵券”和“重复使用”计算优惠券减免金额时，浮点数运算会引发精度丢失，导致财务对账不平。PHP中处理金额一律使用BC Math扩展，将元转换为分进行整型运算。在并发核销优惠券时，同样不能先查后改。必须使用原子更新操作，将优惠券状态从“未使用”改为“已锁定”，并记录锁定时间。如果下单失败，需要有一个定时任务去解锁那些超时未支付订单所占用的优惠券。另外，优惠券叠加规则不要写成满屏的if-else。建议抽象出一个“优惠计算器”接口，利用责任链模式或策略模式，依次计算满减、折扣、运费券，这样在运营提出新的促销逻辑时，代码改动最小。
海量订单数据必须实施冷热分离电商项目运行半年后，订单表会急剧膨胀，导致查询性能断崖式下跌。不要等到数据库CPU飙升到100%才考虑优化。项目初期就应该规划好分表策略。推荐按时间维度进行水平分表，比如按月分表。在PHP代码层，通过封装数据库路由中间件，根据订单创建时间自动路由到对应的物理表。对于用户端“我的订单”列表，绝不允许直接跨表查询。必须引入搜索引擎，将订单关键信息（商品名、订单号、物流单号）同步至Elasticsearch，列表页的复杂查询全部走ES，拿到主键ID后再回数据库取详情。对于历史冷数据，可以定期归档至专用的归档库，甚至直接导出文件存储。
后台权限管理不能只做简单的角色判断简单的“用户-角色-权限”模型在电商后台往往不够用。运营人员需要细粒度的控制，比如“只能查看自己负责分类下的订单”。这就要求权限系统必须支持数据权限。在设计上，RBAC模型负责菜单和按钮级的控制，而数据权限则需要通过拦截SQL语句来实现。可以在数据库查询层注入全局的过滤条件，根据当前登录用户的部门ID或角色标识，动态拼接WHERE条件。这种方案虽然对架构侵入性较强，但能有效避免在业务代码中到处写判断逻辑，防止因遗漏导致的数据越权泄露。
静态资源与动态页面的分离策略商品图片、JS、CSS等静态资源不要直接存放在项目服务器上，这会占用宝贵的带宽和IO资源。必须接入对象存储，并配置CDN加速。在PHP代码中，上传逻辑要将文件流直传到对象存储，数据库只保存文件的Key。页面展示时，通过封装好的辅助函数拼接CDN域名。特别注意图片的防盗链问题，可以在CDN层面配置Referer白名单。对于商品详情页这种读多写少的动态页面，一定要做静态化或缓存化处理。可以利用页面缓存技术，在商品数据更新时触发缓存重建，将完整的HTML片段缓存到Redis或文件系统中，Nginx直接读取返回，绕过PHP-FPM的解析过程，单机QPS能提升数十倍。
日志与监控是保障系统稳定的最后屏障电商业务逻辑复杂，线上排查问题不能只靠echo和var_dump。必须建立全链路追踪日志体系。在每个关键节点（下单、支付、发货）记录结构化日志，包含Trace ID、用户ID、订单ID和耗时。当出现故障时，通过Trace ID快速串联起整个调用链。对于PHP这种同步阻塞模型，慢接口监控尤为重要。可以封装一个中间件，记录每个API的响应时间，一旦超过阈值，立即将接口路径、请求参数和堆栈信息推送到企业微信或钉钉群。这样能在用户大规模投诉前，技术团队就已经开始介入修复了。
定时任务与消息队列的协同订单超时取消、结算对账这类任务绝对不能依赖Linux的Crontab直接调用PHP脚本。一旦脚本执行时间超过Cron的调度间隔，就会产生任务重叠，拖垮数据库。正确的架构是将Cron作为简单的触发器，只负责往消息队列里投递一个任务指令。真正的业务逻辑由常驻内存的消费者进程处理。PHP虽然不适合写常驻服务，但可以使用Workerman等扩展，或者干脆用Go、Java编写消费者，PHP只负责生产消息。在任务处理中，必须做好幂等性控制，因为消息队列可能会重复投递。处理订单超时取消时，先检查订单状态，如果是“已支付”则直接丢弃消息，避免误取消已付款订单。
