1. 项目概述：为什么TPShop部署不是“点几下就完事”的体力活

TPShop环境部署与数据库验证完整指南——这标题里藏着三个关键动作：“部署”“验证”“完整”。它不是教你怎么下载一个压缩包、解压、改个config.php就喊“搞定”的速成课。我带过十几支开发团队，从某高校电商实训实验室到某初创公司技术部，几乎每支队伍在第一次跑通TPShop时都卡在同一个地方：后台能打开，商品列表空白，订单提交报错，日志里满屏“SQLSTATE[HY000] [2002] Connection refused”。问题出在哪？不是PHP版本不对，也不是MySQL没启动，而是部署过程被当成了安装向导，而数据库验证被当成了“看看phpmyadmin能不能连上”这种表面功夫。

TPShop作为一套基于ThinkPHP框架的开源电商系统，它的运行依赖于三层耦合：Web服务层（Nginx/Apache）、脚本执行层（PHP及其扩展）、数据持久层（MySQL + 表结构 + 初始化数据）。这三者之间不是并列关系，而是存在严格的启动顺序、权限约束和状态依赖。比如，TPShop的install.php脚本在创建数据库表时，会调用think\migration\Migrator类执行迁移命令；而该类又强依赖pdo_mysql扩展是否启用、mysqli.default_socket路径是否指向正确的socket文件、以及MySQL用户是否拥有CREATE ROUTINE权限——这些细节，官方文档一笔带过，但实操中任何一个缺失，都会导致“页面白屏但无报错”这种最折磨人的状态。

所以这份指南的核心价值，不在于告诉你“该点哪个按钮”，而在于帮你建立一套可验证、可回溯、可复现的部署心智模型。它适合三类人：刚接触PHP电商系统的应届生（需要避开教科书里不会写的坑），负责交付的实施工程师（要确保客户服务器上一次跑通），以及想把TPShop当练手项目的自学开发者（得明白每个配置项背后的真实作用）。接下来的内容，全部来自我在6台不同配置服务器（CentOS 7/8、Ubuntu 20.04/22.04、阿里云ECS、腾讯云CVM、本地VirtualBox虚拟机、Mac M1芯片）上反复重装、抓包、断点调试的真实记录。没有理论堆砌，只有哪一步该敲什么命令、为什么这么敲、不这么敲会怎样。

2. 环境准备与方案选型：为什么拒绝一键脚本，坚持手动分步搭建

2.1 为什么不用Docker或宝塔面板？

先说结论：Docker镜像封装了太多黑盒逻辑，宝塔面板隐藏了关键路径和权限细节，两者都会让你在后续排查数据库连接超时、文件上传失败、Redis缓存穿透等问题时彻底迷失。我试过用某知名TPShop Docker镜像，在CentOS 7上部署后，前台商品图显示为红叉，查日志发现是/runtime目录权限为755而非777，而镜像内www-data用户UID与宿主机不一致，导致PHP进程无法写入。修复它需要进容器改/etc/passwd，再重启整个容器——这已经超出了“部署”的范畴，变成了“系统运维”。

宝塔同理。它自动生成的Nginx配置里，root指令指向/www/wwwroot/tpshop/public，看似正确，但TPShop的public/index.php中有一行define('ROOT_PATH', __DIR__ . '/../');，这个..向上跳转时，如果/www/wwwroot/tpshop目录本身权限是755，PHP-FPM以www用户身份运行，就会因“跨目录访问被禁”而报错。宝塔不会告诉你这个open_basedir限制在哪里配置，你得去翻/www/server/php/80/etc/php.ini里的open_basedir字段，再手动追加路径。这种“看似省事，实则埋雷”的方案，对学习者是灾难。

因此，本指南坚持纯手工分步搭建，每一步都明确说明：

• 执行命令的当前工作目录
• 命令预期输出的关键字符串
• 失败时最可能的原因及快速验证方式

这不是为了炫技，而是为了让你在任何一台新服务器上，都能靠自己还原出完整的运行环境。

2.2 操作系统与软件版本的硬性选择逻辑

TPShop官方文档写着“支持PHP 7.1+”，但实际测试中，PHP 8.0+会导致think\cache\driver\File类中的set方法因serialize()函数行为变更而静默失败，表现为登录态无法保持。MySQL方面，8.0默认启用caching_sha2_password认证插件，而TPShop的PDO连接字符串若未显式指定&charset=utf8mb4，就会因认证协议不匹配直接拒绝连接。

所以我们的组合是经过23次交叉验证后锁定的：

• 操作系统：CentOS 7.9（内核3.10.0-1160）或 Ubuntu 20.04.6 LTS
  理由：前者是企业级服务器最广泛使用的稳定版，后者是LTS中对PHP 7.4兼容性最好的版本。避免使用CentOS 8（已停止维护）或Ubuntu 22.04（PHP 8.1默认启用JIT编译，与TPShop部分扩展冲突）。
• Web服务器：Nginx 1.20.1
  理由：比1.18更稳定，比1.22少了对QUIC协议的冗余支持，减少配置复杂度。Apache虽可运行，但.htaccess重写规则在TPShop中易与public/.htaccess冲突，导致URL路由失效。
• PHP版本：7.4.33（非7.4.0，因后者存在openssl_encrypt函数内存泄漏Bug）
  理由：TPShop 4.1.x系列代码库大量使用@符号抑制错误，而PHP 8.0+将@操作符标记为Deprecated，导致大量Notice级警告阻塞JSON响应。
• MySQL版本：5.7.39（非8.0.x）
  理由：TPShop安装脚本中think\db\Connection类的getFields()方法，硬编码了SHOW COLUMNS FROMtable_name``语法，而MySQL 8.0对SHOW语句的权限检查更严格，普通用户需额外授予SELECT权限才能执行，否则安装过程卡在“正在创建数据表”不动。

提示：所有软件包均从官方源获取，拒绝第三方PPA或RPM Fusion仓库。例如Ubuntu下安装PHP 7.4，必须执行sudo apt install php7.4-cli php7.4-fpm php7.4-mysql php7.4-curl php7.4-gd php7.4-mbstring php7.4-xml php7.4-zip php7.4-opcache，缺一不可。少装php7.4-opcache，首页加载时间会从320ms飙升至1.8s——这是我在某电商促销活动前夜踩过的坑，凌晨三点紧急补装才保住流量入口。

2.3 目录结构设计：为什么/var/www/tpshop不能直接解压到/var/www/html

很多教程让你把TPShop源码解压到/var/www/html，然后通过http://server-ip/访问。这在单站点环境下看似可行，但会引发两个致命问题：

第一，/var/www/html通常是Apache默认DocumentRoot，而我们用的是Nginx。若Nginx配置中root /var/www/html;，那么访问http://server-ip/install.php时，Nginx会尝试执行/var/www/html/install.php，但TPShop的入口文件实际在/var/www/html/public/index.php。你得手动修改Nginx配置，把location /块里的try_files $uri $uri/ /index.php?$query_string;改成try_files $uri $uri/ /public/index.php?$query_string;——这违反了ThinkPHP的“public为Web根目录”设计哲学，后续升级极易出错。

第二，权限管理失控。/var/www/html目录通常属于root:root，而PHP-FPM进程以www-data（Ubuntu）或nginx（CentOS）用户运行。若直接解压，所有文件属主都是root，PHP进程无法写入/runtime和/public/uploads，导致日志无法生成、商品图无法上传。

因此，我们采用分离式目录结构：

/var/www/tpshop/ # 源码根目录，属主 root:root，权限 755 ├── application/ # 应用模块，含控制器、模型 ├── public/ # Web根目录，Nginx的root指向此处 │ ├── index.php # 入口文件 │ └── static/ # 静态资源 ├── runtime/ # 运行时目录，属主 www-data:www-data，权限 777 └── uploads/ # 上传目录，同上

这个结构的好处是：Nginx配置只需一行root /var/www/tpshop/public;，所有URL路由天然适配；runtime和uploads目录可单独授权，不影响源码安全；未来要部署多个TPShop实例（如测试站、预发站），只需复制/var/www/tpshop并改名，Nginx配置微调即可。

注意：runtime目录权限必须是777，不是755。因为TPShop的think\log\driver\File类在写日志时，会先mkdir(dirname($filename), 0777, true)，若父目录权限不足，mkdir会失败并抛出ErrorException。我曾因误设为755，在CentOS上看到mkdir(): Permission denied in /var/www/tpshop/thinkphp/library/think/log/driver/File.php on line 87，查了两小时才发现是/var/www/tpshop/runtime的父目录/var/www/tpshop权限问题。

3. 核心部署步骤详解：从解压到首页渲染的每一步验证点

3.1 源码获取与完整性校验：为什么SHA256比MD5更值得信赖

TPShop官网提供多个版本下载，但镜像站常有缓存延迟，导致下载的ZIP包损坏。我见过最诡异的一次：某公司运维从官网下载tpshop_v4.1.2.zip，解压后application/database.php文件末尾多出半行乱码，导致'hostname' => '127.0.0.1'变成'hostname' => '127.0.0.1' // 这里有不可见字符，PHP解析时直接报Parse error: syntax error, unexpected end of file。

因此，下载后必须做双重校验：

1. 文件大小比对：官网标注tpshop_v4.1.2.zip大小为28.7MB（29,999,104字节），用ls -lh tpshop_v4.1.2.zip确认。
2. SHA256哈希校验：官网提供SHA256值a1b2c3d4e5f6...（此处为示意），执行：

   sha256sum tpshop_v4.1.2.zip | cut -d' ' -f1

   输出必须完全一致。MD5已被证明存在碰撞漏洞，SHA256是当前通用标准。

校验通过后，解压到/var/www/：

sudo mkdir -p /var/www/tpshop sudo unzip tpshop_v4.1.2.zip -d /var/www/tpshop/ # 注意：必须用unzip，不能用tar -zxvf，因为官网提供的是ZIP格式

解压完成后，立即执行目录权限初始化：

# 设置源码目录为root只读 sudo chown -R root:root /var/www/tpshop sudo chmod -R 755 /var/www/tpshop # 创建并授权runtime和uploads目录 sudo mkdir -p /var/www/tpshop/runtime /var/www/tpshop/public/uploads sudo chown -R www-data:www-data /var/www/tpshop/runtime /var/www/tpshop/public/uploads sudo chmod -R 777 /var/www/tpshop/runtime /var/www/tpshop/public/uploads

实操心得：chmod -R 777看起来危险，但这是TPShop框架强制要求。其think\cache\driver\File类在生成缓存文件时，会调用file_put_contents($filename, $content, LOCK_EX)，若$filename所在目录无写权限，函数返回false且不抛异常，导致缓存永远不生效。我曾用755权限跑了一周，发现商品搜索响应时间从200ms涨到2.3s，最后用strace -p $(pgrep php-fpm) -e trace=write跟踪到write(7, "", 0) = 0（写入0字节），才定位到是/runtime/cache目录无写权限。

3.2 Nginx配置：location块里的try_files为什么必须带/index.php?$query_string

Nginx配置是TPShop能否正确路由的关键。常见错误是照搬ThinkPHP通用配置，写成：

location / { try_files $uri $uri/ /index.php; }

这会导致所有请求（包括/static/css/app.css）都被重写到/index.php，静态资源无法加载。

正确配置必须精确匹配TPShop的public目录结构：

server { listen 80; server_name localhost; root /var/www/tpshop/public; # 关键：root指向public目录 index index.php; location / { try_files $uri $uri/ /index.php?$query_string; # 关键：带$query_string } location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php7.4-fpm.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } location ~ /\.ht { deny all; } }

这里有两个核心点：

• root /var/www/tpshop/public：让Nginx知道/static/css/app.css对应物理路径/var/www/tpshop/public/static/css/app.css。
• try_files $uri $uri/ /index.php?$query_string：$query_string参数至关重要。TPShop的URL路由如/index/goods/index/id/123.html，会被Nginx重写为/index.php?/index/goods/index/id/123.html，而ThinkPHP的think\App::run()方法正是通过$_SERVER['QUERY_STRING']解析路由。若漏掉?$query_string，$_SERVER['QUERY_STRING']为空，路由解析失败，返回404。

验证方式：重启Nginx后，用curl -I http://localhost/，应返回HTTP/1.1 200 OK；用curl -I http://localhost/static/css/app.css，应返回HTTP/1.1 200 OK且Content-Type: text/css。若后者返回404，一定是root路径没指向public。

3.3 PHP-FPM配置：listen.owner与user不一致时的权限陷阱

PHP-FPM的www.conf配置中，user和group定义了子进程运行身份，listen.owner和listen.group定义了Unix socket文件的所有者。若两者不一致，Nginx无法与PHP-FPM通信。

在Ubuntu 20.04上，PHP 7.4-FPM默认配置为：

; /etc/php/7.4/fpm/pool.d/www.conf user = www-data group = www-data listen = /run/php/php7.4-fpm.sock listen.owner = www-data listen.group = www-data

这没问题。但在CentOS 7上，若你手动编译PHP，常会设成：

user = nginx group = nginx listen.owner = nginx listen.group = nginx

此时Nginx配置中的fastcgi_pass unix:/run/php/php7.4-fpm.sock;会失败，因为Nginx主进程以root运行，但worker进程以nginx用户运行，而socket文件属主是nginx:nginx，权限660，Nginx worker可以访问。

但问题来了：TPShop的runtime目录属主是www-data:www-data（我们在2.3节设的），而PHP-FPM子进程以nginx用户运行，无法写入/var/www/tpshop/runtime！结果就是日志不生成、缓存不命中、Session丢失。

解决方案只有一个：统一用户。在CentOS上，创建www-data用户并赋予权限：

sudo useradd -r -s /bin/false www-data sudo usermod -a -G www-data nginx sudo chown -R www-data:www-data /var/www/tpshop/runtime /var/www/tpshop/public/uploads

然后修改/etc/php-fpm.d/www.conf：

user = www-data group = www-data listen.owner = www-data listen.group = www-data

重启PHP-FPM：sudo systemctl restart php-fpm。

常见问题：执行sudo systemctl status php-fpm显示active (running)，但curl http://localhost/仍502 Bad Gateway。此时用sudo ss -tuln | grep 9000检查PHP-FPM是否监听TCP端口（默认不监听），或用sudo ls -l /run/php/php7.4-fpm.sock确认socket文件存在且权限为srw-rw----，属主www-data:www-data。若不存在，是PHP-FPM没启动成功，看sudo journalctl -u php-fpm -n 50 --no-pager找错误。

3.4 数据库初始化：mysql -u root -p < tpshop.sql为什么总是失败

TPShop安装包里的data/tpshop.sql不是标准SQL文件。它包含三类内容：

• CREATE DATABASE IF NOT EXISTS tpshop DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
• USE tpshop;
• 大量INSERT INTO语句，其中部分INSERT的VALUES字段包含NULL或空字符串，但目标表字段定义为NOT NULL DEFAULT ''。

直接mysql -u root -p < tpshop.sql会报错：

ERROR 1138 (22004) at line 123: Invalid use of NULL value

原因是MySQL 5.7默认开启STRICT_TRANS_TABLES模式，禁止向NOT NULL字段插入NULL。

正确做法是分步导入：

1. 创建数据库并指定字符集：

   mysql -u root -p -e "CREATE DATABASE tpshop DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"

2. 临时关闭严格模式，再导入：

   mysql -u root -p -e "SET GLOBAL sql_mode=(SELECT REPLACE(@@sql_mode,'STRICT_TRANS_TABLES',''));" mysql -u root -p tpshop < /var/www/tpshop/data/tpshop.sql

3. 导入后恢复严格模式（安全起见）：

   mysql -u root -p -e "SET GLOBAL sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';"

但更稳妥的方式是用TPShop自带的install.php。访问http://localhost/install.php，按向导输入数据库信息。install.php内部会自动处理STRICT_TRANS_TABLES兼容性，并在创建表时添加ENGINE=InnoDB DEFAULT CHARSET=utf8mb4，避免后续出现Incorrect string value错误。

实操心得：install.php向导中，“数据库地址”填127.0.0.1，不要填localhost。因为localhost在MySQL中会触发socket连接，而127.0.0.1走TCP连接，更稳定。若填localhost，在某些CentOS系统上会因/etc/hosts解析慢导致连接超时。

4. 数据库验证全流程：从连接测试到业务逻辑穿透的四层校验

4.1 第一层：基础连接验证（5秒级）

这是最快速的“心跳检测”。在服务器终端执行：

mysql -h 127.0.0.1 -u tpshop_user -p'tpshop_pass' -D tpshop -e "SELECT VERSION();"

预期输出：

+-----------+ | VERSION() | +-----------+ | 5.7.39 | +-----------+

若报错ERROR 1045 (28000): Access denied for user，说明数据库用户密码错误或权限不足；若报错ERROR 2003 (HY000): Can't connect to MySQL server，说明MySQL服务未启动或防火墙拦截。

注意：-h 127.0.0.1必须显式指定，不能省略。因为mysql -u user -p默认host为localhost，会走socket，而TPShop代码中'hostname' => '127.0.0.1'走TCP，两者认证方式不同。确保测试环境与运行环境一致。

4.2 第二层：表结构与数据完整性验证（30秒级）

TPShop核心业务表共47张，但关键验证只需5张：

• tpshop_config：存储网站名称、LOGO路径等全局配置
• tpshop_goods：商品主表，is_on_sale=1表示上架
• tpshop_users：用户表，is_lock=0表示未被锁定
• tpshop_order：订单表，order_status IN (0,1,2)表示待付款、待发货、已完成
• tpshop_region：地区表，id=1必须是“中国”

执行以下SQL，验证数据是否存在且合理：

mysql -h 127.0.0.1 -u tpshop_user -p'tpshop_pass' tpshop -e " SELECT COUNT(*) as config_count FROM tpshop_config WHERE name='site_name'; SELECT COUNT(*) as goods_count FROM tpshop_goods WHERE is_on_sale=1; SELECT COUNT(*) as users_count FROM tpshop_users WHERE is_lock=0; SELECT COUNT(*) as order_count FROM tpshop_order WHERE order_status IN (0,1,2); SELECT COUNT(*) as region_count FROM tpshop_region WHERE id=1; "

预期所有COUNT(*)结果均大于0。若config_count=0，说明install.php未完成配置写入，需重新运行安装向导；若goods_count=0，可能是data/tpshop.sql导入不全，需检查SQL文件末尾是否有-- End of dump字样。

4.3 第三层：应用层连接验证（2分钟级）

这是模拟TPShop代码的实际数据库调用。在/var/www/tpshop目录下创建test_db.php：

<?php require_once 'thinkphp/start.php'; // 测试数据库连接 try { $db = think\Db::connect(); $result = $db->query("SELECT VERSION() as ver"); echo "DB Version: " . $result[0]['ver'] . "\n"; // 测试读取配置 $config = $db->name('config')->where('name', 'site_name')->find(); echo "Site Name: " . ($config ? $config['value'] : 'NOT FOUND') . "\n"; // 测试写入（临时表） $db->execute("CREATE TEMPORARY TABLE test_temp (id INT)"); $db->execute("INSERT INTO test_temp VALUES (1)"); $count = $db->query("SELECT COUNT(*) as c FROM test_temp")[0]['c']; echo "Temp Table Count: " . $count . "\n"; } catch (Exception $e) { echo "DB Error: " . $e->getMessage() . "\n"; }

执行php test_db.php，预期输出：

DB Version: 5.7.39 Site Name: TPShop商城 Temp Table Count: 1

若报错SQLSTATE[HY000] [2002] No such file or directory，说明application/database.php中'hostname'填成了localhost，应改为127.0.0.1；若报错SQLSTATE[42000]: Syntax error or access rule violation，说明数据库用户缺少CREATE TEMPORARY TABLES权限，需执行：

GRANT CREATE TEMPORARY TABLES ON tpshop.* TO 'tpshop_user'@'localhost'; FLUSH PRIVILEGES;

4.4 第四层：业务逻辑穿透验证（5分钟级）

这是最终验收。手动模拟一个完整购物流程：

1. 访问http://localhost/，确认首页正常加载，商品列表有数据。
2. 点击任意商品进入详情页，URL形如http://localhost/goods-123.html，确认商品图、价格、库存显示正常。
3. 点击“加入购物车”，F12打开浏览器开发者工具，切换到Network标签，刷新页面，找到/index.php?m=Home&c=Cart&a=addCart请求，确认Response为{"status":1,"msg":"\u52a0\u5165\u8d2d\u7269\u8f66\u6210\u529f","result":1}（JSON中文转义）。
4. 访问http://localhost/Home/Cart/cartList，确认购物车页面显示该商品。
5. 提交订单，填写收货地址，支付方式选“货到付款”，提交后跳转到/Home/Order/orderConfirm，确认订单号生成。

这一步验证了从Web路由、控制器调用、模型查询、数据库写入、Session保持到前端渲染的全链路。若卡在第3步，addCart返回{"status":0,"msg":"\u7528\u6237\u672a\u767b\u5f55"}，说明Session未生效，检查/var/www/tpshop/runtime/session目录权限是否为777；若第5步订单号为空，检查tpshop_order表的order_sn字段是否设置了AUTO_INCREMENT，执行ALTER TABLE tpshop_order MODIFY order_sn VARCHAR(50) NOT NULL FIRST;修复。

排查技巧：当业务流程某一步失败，不要猜，直接查日志。TPShop日志在/var/www/tpshop/runtime/log/，按日期分文件。例如，20230901.log中搜索addCart，会看到类似：[2023-09-01 14:22:33] LOG.INFO: CartController->addCart start [] [][2023-09-01 14:22:33] LOG.ERROR: SQL Error: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'user_id' cannot be null [] []这说明addCart方法中$data['user_id']为空，需检查登录态验证逻辑。

5. 常见问题与实战排障：那些官方文档绝不会告诉你的细节

5.1 问题速查表：症状、原因、解决命令三列对照

5.2 “页面白屏但无错误”的终极排查法

这是TPShop部署中最令人抓狂的问题。Nginx错误日志（/var/log/nginx/error.log）和PHP错误日志（/var/log/php7.4-fpm.log）均为空，浏览器F12也看不到JS错误。

根本原因是：ThinkPHP的error_reporting被设为0，且display_errors=Off，所有错误被静默吞掉。

解决步骤：

1. 临时开启PHP错误显示：编辑/etc/php/7.4/fpm/php.ini，找到display_errors = Off，改为display_errors = On；找到error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT，确保未被注释。
2. 重启PHP-FPM：sudo systemctl restart php7.4-fpm。
3. 在浏览器访问http://localhost/，此时白屏会变成红色错误提示，如Fatal error: Uncaught Error: Class 'think\Validate' not found，说明thinkphp/library/think/Validate.php文件缺失或路径错误。
4. 检查/var/www/tpshop/thinkphp目录是否存在，权限是否为755，library/think下是否有Validate.php。

我的经验：90%的“白屏无错”问题，根源都在thinkphp目录。TPShop安装包有时会把thinkphp放在/var/www/tpshop/thinkphp，但public/index.php中require __DIR__ . '/../thinkphp/start.php';的..向上跳转后，实际路径是/var/www/tpshop/thinkphp/start.php。若你误把thinkphp解压到了/var/www/tpshop/application/thinkphp，就会导致require失败。用find /var/www/tpshop -name "start.php"确认路径。

5.3 Redis缓存启用后的“商品价格不更新”问题

TPShop支持Redis缓存，配置在application/database.php中：

'cache' => [ 'type' => 'redis', 'host' => '127.0.0.1', 'port' => 6379, 'password' => '', 'select' => 0, ],

启用后，修改商品价格，前台仍显示旧价。这是因为TPShop的GoodsLogic类中，getGoodsInfo()方法会先查Redis缓存goods_info_123，若存在则直接返回，不查数据库。

解决方法不是关Redis，而是主动清除缓存：

• 方式一：在后台“系统设置”→“数据备份”→“清空缓存”，点击“确定”。
• 方式二：命令行清除：

  redis-cli -h 127.0.0.1 -p 6379 KEYS "goods_info_*" | xargs redis-cli -h 127.0.0.1 -p 6379 DEL

• 方式三：在代码中，修改商品后调用cache('goods_info_'.$goods_id, null);。

注意：Redis的KEYS命令在生产环境慎用，会阻塞Redis。线上应改用SCAN命令：

redis-cli -h 127.0.0.1 -p 6379 --scan --pattern "goods_info_*" | xargs -r redis-cli -h 127.0.0.1 -p 6379 DEL

5.4 HTTPS部署后“微信支付回调失败”的证书链问题

当Nginx配置HTTPS后，微信支付回调URL（如https://shop.com/Home/Payment/weixinNotify）常返回cURL error 60: SSL certificate problem。这不是TPShop代码问题，而是Nginx的SSL证书链不完整。

解决方案：

1. 获取完整证书链：从证书颁发机构下载fullchain.pem（包含域名证书+中间证书），而非仅domain.crt。
2. Nginx配置中，ssl_certificate指向fullchain.pem，ssl_certificate_key指向domain.key：

   ssl_certificate /etc/ssl/fullchain.pem; ssl_certificate_key /etc/ssl/domain.key;

3. 重启Nginx：sudo systemctl restart nginx。

验证：用openssl s_client -connect shop.com:443 -servername shop.com 2>/dev/null | openssl x509 -noout -text | grep "CA Issuers"，应显示中间证书颁发者URL。

最后分享一个小技巧：TPShop的application/config.php