企业官网建设流程全解析

简介：本资源是一份面向计算机专业本科生及Web开发初学者的毕业设计文档，聚焦PHP+MySQL技术栈实现化妆品垂直电商网站，解决传统手工管理效率低、易出错等问题，适用于课程设计、毕设参考与B/S架构实战学习。压缩包仅含1个475KB的Word文档（.docx），完整呈现从需求分析、系统设计到功能实现的全流程，涵盖会员注册登录、购物车、订单处理、商品管理等核心模块，并详细说明B/S架构选型、Sublime Text开发环境配置、Navicat数据库操作及系统测试用例。内容结构规范，含摘要、目录、6大章节与参考文献，具备高校毕业论文标准格式与工程实践深度。目前已有39人学习下载，读者可直接复用其功能模块划分逻辑、数据库表设计思路、前后台管理流程图解及PHP代码实现要点，快速构建同类电商系统原型。

1. 为什么一个“化妆品销售网站”还要专门用 PHP 重做一遍？——不是为了炫技，而是解决库存同步慢、促销规则硬编码、移动端适配卡顿这三大业务痛点

某化妆品电商团队在迭代老系统时发现：原基于静态模板+少量 JS 的前台页面，每次上新一款防晒霜，运营要手动改 5 处 HTML、3 个 JS 变量、2 个 Excel 库存表；大促期间优惠券逻辑写死在前端，临时加个“满 299 减 30 且限前 100 名”，后端得停服 20 分钟发版；更麻烦的是，安卓低端机访问商品详情页平均加载 4.7 秒，跳失率比 iOS 高出 38%。他们最终选择用 PHP 从零重构，不是因为 PHP 多“古老”，恰恰相反——它在中小电商业务中仍具备不可替代的落地优势：无需额外容器编排即可快速部署到共享主机或轻量云；模板引擎（如 Twig）天然支持组件化拆分，让首页轮播图、SKU 选择器、购物车浮层能独立维护；更重要的是，PHP 的opcache+APCu组合能让促销规则计算耗时从 120ms 压到 8ms 以内。本文讲的，就是如何用现代 PHP 工程实践（非 Laravel 全家桶堆砌），把一个真实化妆品销售网站从需求文档变成可上线、可运维、可快速响应运营需求的系统。适合正在接手类似项目、需要兼顾开发效率与线上稳定性的 PHP 中级开发者。

2. 用 Composer 管理依赖 + MVC 分层结构：先搭骨架，再填血肉

2.1 为什么放弃 Laravel 而选 Slim + 自研核心？——三类场景下的取舍逻辑

很多开发者看到“化妆品销售网站”第一反应是 Laravel，但实际落地时我们做了三轮压测对比：

• 场景一：高并发秒杀页（如明星同款面膜限量抢购）
  Laravel 的中间件链在 1200 QPS 下平均响应 142ms；Slim 3.x + 原生 PDO 连接池 + Redis 缓存 SKU 库存，压到 2800 QPS 时仍稳定在 68ms。原因在于 Slim 的中间件是函数式调用，无 Eloquent ORM 的对象实例化开销。
• 场景二：后台商品管理页（含多图上传、规格矩阵、资质文件 PDF 上传）
  Laravel 的 Storage facade 在处理 200+ SKU 批量导入时内存峰值达 512MB；我们用 Slim 搭配自研的ProductImportService，通过fgetcsv()流式读取 + 分块插入（每 50 行 commit 一次），内存始终控制在 80MB 内。
• 场景三：SEO 友好型商品详情页（需服务端渲染动态标题/描述/Meta）
  Laravel 的 Blade 模板虽强，但 SEO 插件（如 spatie/laravel-seo）配置复杂；而 Slim 配合 Twig 的include和extends机制，我们仅用 3 个基础模板（base.twig,product-detail.twig,seo-meta.twig）就实现了所有页面的 Meta 动态注入，且首屏 HTML 含完整关键词。

提示：这不是贬低 Laravel，而是强调——当你的核心瓶颈在库存一致性、图片上传吞吐、SEO 渲染速度时，框架的“功能丰富度”反而会成为负担。Slim 的轻量本质，让你能把精力聚焦在业务逻辑本身。

2.2 初始化项目结构：5 分钟跑通第一个路由

我们不使用composer create-project，而是手动初始化以确保最小依赖：

mkdir cosmetic-shop && cd cosmetic-shop composer init -n --name="cosmetic/shop" --type="project" --license="MIT" composer require slim/slim:"4.12.*" twig/twig:"3.15.*" monolog/monolog:"3.7.*" predis/predis:"2.2.*"

关键点说明：

• slim/slim:4.12.*是当前最稳定的 LTS 版本，避免 5.x 的 PSR-18 强制依赖带来的 HTTP 客户端绑定问题；
• twig/twig:3.15.*锁定 3.x 系列，因 4.x 移除了Twig_Environment类，大量现有模板需重写；
• predis/predis:2.2.*用于 Redis 连接，版本 2.2 是最后一个支持 PHP 7.4 的稳定版（某高校实验室服务器仍运行 PHP 7.4，必须兼容）。

接着创建基础目录结构：

cosmetic-shop/ ├── public/ │ └── index.php # 入口文件，仅 12 行代码 ├── src/ │ ├── Core/ # 自研核心类：Router、DB、Cache │ ├── Controller/ # 控制器：ProductController、CartController │ ├── Model/ # 数据模型：Product、Category、Order │ └── View/ # Twig 模板：templates/ 目录 ├── config/ │ ├── database.php # 数据库配置（PDO DSN、用户名、密码） │ └── cache.php # Redis 配置（host、port、timeout） └── vendor/ # Composer 自动创建

public/index.php的最小实现（12 行）：

<?php use Psr\Http\Message\ResponseInterface as Response; use Psr\Http\Message\ServerRequestInterface as Request; use Slim\Factory\AppFactory; require __DIR__ . '/../vendor/autoload.php'; // 1. 创建 App 实例 $app = AppFactory::create(); // 2. 注册 Twig 视图 $loader = new \Twig\Loader\FilesystemLoader(__DIR__ . '/../src/View/templates'); $twig = new \Twig\Environment($loader, ['debug' => true]); $app->add(function ($request, $handler) use ($twig) { $request = $request->withAttribute('view', $twig); return $handler->handle($request); }); // 3. 定义首页路由 $app->get('/', function (Request $request, Response $response) { $view = $request->getAttribute('view'); $response->getBody()->write($view->render('home.twig', ['title' => '臻美美妆官方商城'])); return $response; }); $app->run();

逻辑说明：

• 第 1 步AppFactory::create()是 Slim 4 的标准入口，比手动 new App 更安全（自动注册 PSR-17 响应工厂）；
• 第 2 步通过中间件将$twig实例注入请求属性，后续所有控制器都能通过$request->getAttribute('view')获取，避免全局变量；
• 第 3 步路由中直接调用$view->render()，参数'home.twig'对应src/View/templates/home.twig，['title' => ...]是传递给模板的变量。

此时执行php -S localhost:8000 -t public，访问http://localhost:8000即可看到 “臻美美妆官方商城” 标题——这是整个网站的第一个可验证节点，也是后续所有功能的基石。

3. 商品模块：用 PDO 预处理防注入 + Redis 缓存降压，解决“爆款页面卡死”问题

3.1 商品列表页：分页查询的三个致命陷阱与修复方案

化妆品品类存在典型特征：同一品牌下有“美白”“抗老”“舒缓”多个子系列，每个系列下又有 SPF30/SPF50/SPF50+ 三种防晒值，导致 SKU 总数常超 10 万。直接SELECT * FROM products LIMIT 0,20会触发全表扫描，我们踩过三个坑：

陷阱一：OFFSET 越大越慢
当用户翻到第 500 页（OFFSET 9980），MySQL 执行计划显示Using filesort，响应时间飙升至 3.2 秒。
修复：改用游标分页（Cursor-based Pagination）。核心是记录上一页最后一条商品的id和created_at：

-- 第一页（获取最新 20 款） SELECT id, name, price, image_url FROM products WHERE status = 1 ORDER BY created_at DESC, id DESC LIMIT 20; -- 第二页（以上一页最后一条的 created_at 和 id 为边界） SELECT id, name, price, image_url FROM products WHERE status = 1 AND (created_at < '2024-05-20 10:30:00' OR (created_at = '2024-05-20 10:30:00' AND id < 12345)) ORDER BY created_at DESC, id DESC LIMIT 20;

注意：created_at必须建联合索引(status, created_at, id)，否则AND (created_at < ...)无法走索引。

陷阱二：WHERE 条件未走索引
运营要求按“功效”筛选（如effect = 'whitening'），但effect字段是 TEXT 类型，LIKE '%whitening%'导致全表扫描。
修复：新建products_effect关联表，用整数 ID 替代字符串：

CREATE TABLE products_effect ( product_id INT UNSIGNED NOT NULL, effect_id TINYINT UNSIGNED NOT NULL, -- 1=whitening, 2=anti-aging... PRIMARY KEY (product_id, effect_id), KEY idx_effect (effect_id) );

查询时改用JOIN：

SELECT p.id, p.name FROM products p JOIN products_effect pe ON p.id = pe.product_id WHERE p.status = 1 AND pe.effect_id = 1 ORDER BY p.created_at DESC LIMIT 20;

陷阱三：COUNT(*) 拖垮分页栏
传统分页需SELECT COUNT(*) FROM products WHERE status=1计算总页数，10 万数据下耗时 800ms。
修复：用 Redis 缓存总数，仅在商品上下架时更新：

// 商品上架时 $redis->incr('product:total:active'); // 商品下架时 $redis->decr('product:total:active'); // 列表页直接取缓存 $total = $redis->get('product:total:active') ?: 0; $pages = ceil($total / 20);

提示：缓存失效策略必须严格——我们用数据库触发器监听products.status变更，自动调用 Redis 命令，避免应用层漏更新。

3.2 商品详情页：Redis 缓存策略的三层设计（冷热分离 + 过期分级）

化妆品详情页包含 7 类数据：基础信息（名称/价格）、规格矩阵（容量/色号）、图文详情（HTML）、用户评价（分页）、相关推荐、资质证书（PDF URL）、SEO Meta。若全部塞进一个 Redis Key，单次更新需重建整个结构，且不同数据更新频率差异极大（如评价每分钟新增，而资质证书半年一换）。我们采用三层缓存：

关键代码实现（ProductController.php）：

public function show(Request $request, Response $response, array $args): Response { $productId = (int)$args['id']; // 1. 优先查基础信息缓存 $cacheKey = "product:detail:{$productId}"; $productData = $this->redis->get($cacheKey); if ($productData === false) { // 2. 缓存未命中，查数据库（预处理防注入） $stmt = $this->pdo->prepare(" SELECT id, name, price, stock, sku_matrix FROM products WHERE id = ? AND status = 1 "); $stmt->execute([$productId]); $productData = $stmt->fetch(PDO::FETCH_ASSOC); if (!$productData) { throw new HttpNotFoundException($request, '商品不存在'); } // 3. 写入缓存（JSON 序列化，2小时过期） $this->redis->setex($cacheKey, 7200, json_encode($productData)); } else { $productData = json_decode($productData, true); } // 4. 并行获取其他缓存（使用 pipeline 减少网络往返） $pipe = $this->redis->pipeline(); $pipe->get("product:html:{$productId}"); $pipe->get("product:review:{$productId}:1"); $results = $pipe->execute(); $htmlData = $results[0] ? json_decode($results[0], true) : []; $reviewData = $results[1] ? json_decode($results[1], true) : []; // 5. 渲染模板 $view = $request->getAttribute('view'); $response->getBody()->write($view->render('product-detail.twig', [ 'product' => $productData, 'html' => $htmlData, 'reviews' => $reviewData ])); return $response; }

参数说明：

• $this->redis->pipeline()是 Predis 的管道命令，将 2 次 GET 合并为 1 次 TCP 请求，实测降低 35% 延迟；
• setex($key, 7200, $value)中7200是秒数，必须明确写数字而非2*3600，避免 PHP 解析开销；
• json_encode()前确保$productData不含资源类型（如 PDOStatement），否则会报错。

4. 购物车与订单：用 Redis List + Lua 脚本保证原子性，终结“超卖”和“重复下单”

4.1 购物车：为什么不用 Session 存储？——从 3000 用户并发添加看性能断崖

初期我们用 PHP 默认 Session（文件存储）存购物车，当 3000 用户同时点击“加入购物车”按钮时，服务器 I/O 等待队列暴涨，平均响应时间从 120ms 跃升至 2.3 秒。根本原因是：Session 文件锁是进程级的，同一用户的多次请求会被串行化。改为 Redis 后，性能提升如下：

我们最终选择Redis List + Lua 脚本，因为：

• List 天然支持LPUSH/LPOP，购物车增删是典型的栈操作；
• Lua 脚本在 Redis 服务端原子执行，避免“查库存→减库存→写购物车”的竞态条件；
• 单个脚本可封装复杂逻辑（如限购 3 件、赠品自动加入）。

购物车添加 Lua 脚本（cart-add.lua）：

-- KEYS[1] = cart_key (e.g., "cart:1001") -- ARGV[1] = product_id, ARGV[2] = quantity, ARGV[3] = max_per_user (e.g., "3") -- 1. 检查当前用户已购该商品数量 local current_qty = 0 for i, v in ipairs(redis.call('LRANGE', KEYS[1], 0, -1)) do local item = cjson.decode(v) if item.product_id == ARGV[1] then current_qty = current_qty + item.quantity break end end -- 2. 检查是否超限 if current_qty + tonumber(ARGV[2]) > tonumber(ARGV[3]) then return {err = "超出购买限制", code = 400} end -- 3. 构建商品项 JSON local item_json = cjson.encode({ product_id = tonumber(ARGV[1]), quantity = tonumber(ARGV[2]), added_at = tonumber(ARGV[4]) -- 时间戳由 PHP 传入，避免 Redis 时钟不同步 }) -- 4. 添加到 List（去重：先 LREM 再 LPUSH） redis.call('LREM', KEYS[1], 0, item_json) redis.call('LPUSH', KEYS[1], item_json) return {ok = true, qty = current_qty + tonumber(ARGV[2])}

PHP 调用代码：

public function addToCart(Request $request, Response $response): Response { $data = $request->getParsedBody(); $userId = $request->getAttribute('user_id'); // 从 JWT 或 Session 获取 $cartKey = "cart:{$userId}"; // 生成唯一时间戳（微秒级，避免 Lua 内 time() 精度不足） $timestamp = round(microtime(true) * 1000000); // 执行 Lua 脚本 $result = $this->redis->eval( file_get_contents(__DIR__ . '/lua/cart-add.lua'), [$cartKey], [$data['product_id'], $data['quantity'], '3', $timestamp] ); if (isset($result['err'])) { return $response->withStatus(400)->withJson($result); } return $response->withJson(['message' => '添加成功', 'current_qty' => $result['qty']]); }

注意：Lua 脚本中cjson.encode()生成的 JSON 必须与 PHPjson_encode()兼容，因此 PHP 端传入的product_id和quantity必须是整数（用tonumber()转换），避免 Lua 解析失败。

4.2 订单创建：用 MySQL 事务 + Redis 分布式锁，双保险防重复提交

用户点击“立即购买”后，前端常因网络延迟多次触发请求，导致同一笔订单生成 3 次。我们采用“前端防抖 + 后端双锁”策略：

前端防抖（非本文重点，但必须做）：

let isSubmitting = false; document.getElementById('submit-order').addEventListener('click', () => { if (isSubmitting) return; isSubmitting = true; fetch('/api/orders', { method: 'POST' }).finally(() => { isSubmitting = false; document.getElementById('submit-order').disabled = false; }); });

后端双锁：

1. Redis 分布式锁：用SET key value NX PX 10000生成 10 秒锁，value 为唯一请求 ID（如order:lock:{$userId}:{$cartHash}）；
2. MySQL 唯一索引：在orders表建联合唯一索引UNIQUE KEY uk_user_cart (user_id, cart_hash)，cart_hash是购物车商品 ID+数量的 MD5。

订单创建核心逻辑：

public function createOrder(Request $request, Response $response): Response { $userId = $request->getAttribute('user_id'); $cartItems = $this->getCartItems($userId); // 从 Redis List 读取 // 1. 生成购物车哈希（防重复） $cartHash = md5(json_encode(array_map(function($item) { return ['id' => $item['product_id'], 'q' => $item['quantity']]; }, $cartItems))); // 2. 尝试获取 Redis 锁 $lockKey = "order:lock:{$userId}:{$cartHash}"; $lockValue = uniqid('', true); $isLocked = $this->redis->set($lockKey, $lockValue, ['NX', 'PX' => 10000]); if (!$isLocked) { return $response->withStatus(425)->withJson(['message' => '订单处理中，请勿重复提交']); } try { // 3. 开启 MySQL 事务 $this->pdo->beginTransaction(); // 4. 插入订单主表（唯一索引拦截重复） $stmt = $this->pdo->prepare(" INSERT INTO orders (user_id, cart_hash, total_amount, status) VALUES (?, ?, ?, 'pending') "); $stmt->execute([$userId, $cartHash, $this->calcTotal($cartItems)]); $orderId = $this->pdo->lastInsertId(); // 5. 扣减库存（预处理语句防注入） foreach ($cartItems as $item) { $stmt = $this->pdo->prepare(" UPDATE products SET stock = stock - ? WHERE id = ? AND stock >= ? "); $result = $stmt->execute([$item['quantity'], $item['product_id'], $item['quantity']]); if ($result === false || $stmt->rowCount() === 0) { throw new Exception("库存不足：商品 {$item['product_id']}"); } } // 6. 清空购物车 $this->redis->del("cart:{$userId}"); $this->pdo->commit(); return $response->withJson(['order_id' => $orderId, 'message' => '下单成功']); } catch (\Exception $e) { $this->pdo->rollback(); return $response->withStatus(400)->withJson(['message' => $e->getMessage()]); } finally { // 7. 释放 Redis 锁（Lua 脚本保证原子性） $this->redis->eval( "if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('DEL', KEYS[1]) else return 0 end", [$lockKey], [$lockValue] ); } }

关键点：

• cart_hash必须包含商品 ID 和数量，不能只用商品 ID（否则不同数量的订单会被判为重复）；
• SET ... NX PX中NX表示仅当 key 不存在时设置，PX 10000是毫秒过期，避免死锁；
• 释放锁必须用 Lua 脚本，因为“GET 判断 + DEL 删除”不是原子操作，可能被其他进程插队。

5. 避坑指南：生产环境踩过的 5 个血泪坑，每一条都让上线推迟了 2 天以上

5.1 现象：商品搜索页返回空结果，但数据库明明有匹配数据

原因：MySQL 全文索引（FULLTEXT）默认使用ft_min_word_len=4，而化妆品常用词如“SPF”“UV”“A醇”长度均小于 4，被全文索引直接忽略。
解决：修改 MySQL 配置my.cnf：

[mysqld] ft_min_word_len = 2 ft_stopword_file = ''

重启 MySQL 后，重建全文索引：

ALTER TABLE products DROP INDEX ft_name_desc; ALTER TABLE products ADD FULLTEXT(name, description) WITH PARSER ngram;

注意：ngram解析器对中文分词更友好，但需 MySQL 5.7.6+；若用旧版本，改用MATCH(name, description) AGAINST('SPF*' IN BOOLEAN MODE)。

5.2 现象：用户上传的资质证书 PDF 在某些安卓手机上无法预览

原因：PHP 的move_uploaded_file()保存文件后，未设置正确的 MIME Type。安卓 WebView 默认拒绝打开application/octet-stream类型的 PDF。
解决：上传后用finfo_file()重新检测并设置 Header：

$uploadPath = '/var/www/uploads/cert/' . uniqid() . '.pdf'; move_uploaded_file($_FILES['cert']['tmp_name'], $uploadPath); $finfo = finfo_open(FILEINFO_MIME_TYPE); $mimeType = finfo_file($finfo, $uploadPath); finfo_close($finfo); // 强制设为 application/pdf if ($mimeType !== 'application/pdf') { header('Content-Type: application/pdf'); readfile($uploadPath); exit; }

5.3 现象：促销活动页的倒计时在部分 iPhone 上快 5 分钟

原因：前端 JavaScriptnew Date()依赖设备本地时间，而用户手动修改了手机时间。
解决：所有倒计时从服务端获取基准时间戳：

// API 返回 return $response->withJson([ 'server_time' => time(), // Unix 时间戳 'activity_end' => strtotime('2024-06-30 23:59:59') ]);

前端用差值计算：

const serverTime = response.server_time * 1000; // 转毫秒 const now = new Date().getTime(); const offset = now - serverTime; // 设备时间偏移量 const countdown = response.activity_end * 1000 - now + offset;

5.4 现象：后台导出 Excel 报表时内存溢出（Allowed memory size of 134217728 bytes exhausted）

原因：用 PhpSpreadsheet 加载 10 万行数据到内存，对象实例化耗尽 128MB 限制。
解决：改用box/spout库，它采用流式写入，内存占用恒定在 3MB 内：

use Box\Spout\Writer\Common\Creator\WriterEntityFactory; $writer = WriterEntityFactory::createXLSXWriter(); $writer->openToFile('/tmp/sales-report.xlsx'); // 写入表头 $writer->addRow(WriterEntityFactory::createRowFromArray(['订单号', '商品名', '金额'])); // 流式写入数据（PDO 每次 fetch 1000 行） $stmt = $this->pdo->prepare("SELECT order_no, product_name, amount FROM sales WHERE date >= ?"); $stmt->execute([$startDate]); while ($rows = $stmt->fetchAll(PDO::FETCH_NUM, 1000)) { foreach ($rows as $row) { $writer->addRow(WriterEntityFactory::createRowFromArray($row)); } } $writer->close();

5.5 现象：Nginx + PHP-FPM 部署后，商品图片 URL 返回 404

原因：Nginx 配置中location ~ \.php$的root指向了public/，但图片实际存放在public/uploads/，而location /块未正确处理静态资源。
解决：在 Nginx 配置中显式声明图片路径：

location /uploads/ { alias /var/www/cosmetic-shop/public/uploads/; expires 1h; add_header Cache-Control "public, immutable"; }

提示：alias结尾的/必须与location的/匹配，否则路径拼接错误。

6. 进阶技巧：用 PHP 内置 Web Server + Xdebug 实现“改完代码立刻看到效果”的真·零配置调试

6.1 为什么不用 Docker？——小团队快速迭代的真实约束

某化妆品公司技术团队共 5 人，其中 2 人兼运营。他们没有专职 DevOps，服务器是阿里云轻量应用服务器（2核4G），装 Docker 会吃掉 300MB 内存，且每次docker-compose up启动要 40 秒。我们坚持用 PHP 内置 Web Server（php -S），配合 Xdebug 实现高效调试，关键在于三点突破：

突破一：内置 Server 支持路由重写
php -S默认不支持.htaccess，但可通过-t指定文档根，并用路由器脚本处理伪静态：

// router.php if (preg_match('/\.(?:png|jpg|jpeg|gif|css|js|ico|xml|txt|pdf|woff2|ttf)$/', $_SERVER["REQUEST_URI"])) { return false; // 静态资源直接返回 } // 否则交由 Slim 处理 require __DIR__ . '/public/index.php';

启动命令：

php -S localhost:8000 -t public router.php

突破二：Xdebug 3 配置极简到 3 行
在php.ini中只需：

zend_extension=xdebug.so xdebug.mode=debug xdebug.client_host=host.docker.internal ; macOS/Windows WSL 用 host.docker.internal，Linux 用宿主机 IP

注意：xdebug.client_host必须指向你的 IDE（PhpStorm/VS Code）所在机器，不是localhost（Docker 容器内localhost指自己）。

突破三：VS Code 调试配置一键复用
.vscode/launch.json：

{ "version": "0.2.0", "configurations": [ { "name": "Listen for Xdebug", "type": "php", "request": "launch", "port": 9003, "pathMappings": { "/var/www/cosmetic-shop": "${workspaceFolder}" } } ] }

启动调试后，在ProductController.php打断点，浏览器访问http://localhost:8000/products/123，VS Code 自动停在断点——整个过程无需重启服务、无需清理缓存、无需等待构建。

6.2 一个真实案例：如何 10 分钟定位并修复“购物车数量显示错乱”

某天运营反馈：“用户 A 的购物车显示 5 件，但结算时只有 3 件”。我们按以下步骤排查：

1. 确认现象：用 Postman 调GET /api/cart，返回{"items": [{"product_id": 101, "quantity": 2}, {"product_id": 102, "quantity": 3}]}，共 5 件；
2. 检查 Redis：redis-cli连上，执行LRANGE cart:1001 0 -1，发现两条 JSON：{"product_id":101,"quantity":2}和{"product_id":102,"quantity":3}，数据正确；
3. 开启 Xdebug：在CartController.php的getCart()方法首行打点，发现$this->redis->lRange()返回的数组中，第二条数据的quantity字段是字符串"3"而非整数3；
4. 溯源：查到addToCart()中json_encode()时，$data['quantity']是字符串（前端传quantity="3"），PHP 默认不转换类型；
5. 修复：在addToCart()中强制转整型：

$quantity = (int)$data['quantity']; // 原来是 $data['quantity']

6. 验证：刷新页面，购物车数量显示正常，结算一致。

整个过程 9 分 23 秒。这种“所见即所得”的调试体验，是 Docker+Xdebug 远达不到的——后者需反复docker-compose build、docker-compose up，一次重启 40 秒起步。

我带过的几个项目里，凡是坚持用php -S+ Xdebug 的团队，新人上手平均只要 1 天就能独立改 Bug；而用 Docker 的团队，光环境搭建就要 3 天。技术选型没有绝对优劣，只有是否贴合你的真实约束。希望帮到你。

本文还有配套的精品资源，点击获取