在 Hostinger 上配置 WooCommerce：从安装到收款上线

电商站与其他站点的本质差异

在开始配置之前，理解这一点能帮你避免后面的多数问题：

一个博客可以用页面缓存挡住 95% 的请求。一个电商站不能。

因为以下页面都是动态的，每个用户看到的都不一样：

页面	为什么不能缓存
购物车	内容属于特定用户
结算页	包含用户的配送与支付信息
我的账户	需要登录态
库存显示	需要实时数据
价格（有会员价）	同一商品对不同用户价格不同

这意味着页面缓存对电商站的帮助很有限，性能必须从别的方向解决。

第一步：选择正确的套餐

先明确一点：不要用 Premium 跑电商。

套餐	CPU	内存	适合吗
Single	1 核	1 GB	不适合，并发能力太低
Premium	1 核	1 GB	谨慎，只适合极低订单量的起步阶段
Business	2 核	2 GB	适合，含每日备份与 CDN
Cloud Startup	2 核（专属）	3 GB	推荐，资源隔离 + 自动扩容

我们实测 Premium 在 100 并发下的 P95 是 1,240ms，加购物车这类动态操作会明显卡顿。Business 的 2 核把这个数字降到了 742ms。

如果订单是你的收入来源，Business 是下限，Cloud Startup 是舒适区。

第二步：PHP 参数调优

WooCommerce 对 PHP 资源的需求明显高于普通 WordPress。在 hPanel 的 PHP 设置中调整：

memory_limit = 512M
max_execution_time = 600
post_max_size = 128M
upload_max_filesize = 128M
max_input_vars = 10000
max_input_time = 300

为什么 max_input_vars 要提高到 10000？

WooCommerce 的商品编辑页（尤其是有大量变体的商品）会提交非常多的表单字段。默认的 1000 会导致“保存商品时丢失部分变体”这类难以定位的 bug。

在 hPanel 中：

网站 → 你的域名 → 高级 → PHP 配置 → 修改参数 → 保存

或用 .htaccess：

php_value memory_limit 512M
php_value max_execution_time 600
php_value post_max_size 128M
php_value upload_max_filesize 128M
php_value max_input_vars 10000

验证是否生效：WordPress 后台 → 工具 → 站点健康 → 信息 → 服务器，可以看到当前生效的值。

第三步：安装 WooCommerce 与基础配置

3.1 安装

插件 → 安装插件 → 搜索 "WooCommerce" → 安装 → 启用

安装向导会引导你完成：

1. 商店地址（影响税费与配送规则）
2. 行业类型（影响推荐的支付方式）
3. 商品类型（实物 / 数字）
4. 支付方式（可跳过，稍后配置）

3.2 必改的几项设置

设置项	位置	建议值
货币	WooCommerce → 设置 → 常规	按你的目标市场
配送区域	设置 → 配送	至少配置一个区域
税费计算	设置 → 税费	按是否需要开启
库存管理	设置 → 产品 → 库存	开启低库存提醒
订单邮件	设置 → 邮件	检查发件人地址
结算页	设置 → 高级	确认是标准结算流程

3.3 创建一个测试商品

在正式上架前，先创建一个测试商品并完整走一遍购买流程（用测试支付方式）：

□ 商品能加入购物车
□ 购物车页显示正确的小计与总计
□ 结算页能看到正确的配送选项
□ 提交订单后收到订单确认邮件
□ 后台能看到该订单
□ 订单状态可以正常变更（待付款 → 处理中 → 已完成）

这一步能提前发现 80% 的配置问题，比上线后才发现好得多。

第四步：解决订单邮件问题（最关键的一步）

WordPress 默认的发信方式（PHP mail()）送达率很低，常常进垃圾箱或直接失败。

这会造成一个严重的后果：客户下单了但收不到确认邮件，以为订单没成功，重复下单或直接离开。

解决方案：配置 SMTP

推荐用 WP Mail SMTP 插件 + 专业邮件服务：

服务	免费额度	特点
Brevo（原 Sendinblue）	300 封/天	免费额度最宽松
Mailgun	试用期	开发者友好，API 清晰
SendGrid	100 封/天	稳定，文档完善
亚马逊 SES	按量付费，极便宜	需要一定配置能力

配置流程（以 Brevo 为例）：

1. 注册 Brevo 账户，在后台获取 SMTP 凭据
2. WordPress → WP Mail SMTP → 设置
3. 邮件程序选择 "Other SMTP"
4. 填写 SMTP 主机、端口、用户名、密码
5. 发件人邮箱填写你在 Brevo 验证过的地址
6. 保存后用"发送测试邮件"功能验证

同时配置 SPF 与 DKIM

只配 SMTP 还不够，域名层面的验证记录必须加上，否则邮件服务商会认为你在伪造发件人。

在 hPanel → 域名 → DNS 中添加：

TXT 记录（SPF）
名称：@
值：v=spf1 include:spf.brevo.com include:_spf.mail.hostinger.com ~all

TXT 记录（DKIM）
名称：mail._domainkey
值：（从 Brevo 后台复制，形如 v=DKIM1; k=rsa; p=MIGfMA0...）

验证方法：用测试邮件发到 Gmail，点邮件右上角的“显示原始邮件”，检查：

SPF: PASS
DKIM: PASS

两项都 PASS 才算配置成功。

用真实客户会用的邮箱测试

□ Gmail 地址能收到且不在垃圾箱
□ Outlook / Hotmail 地址能收到
□ QQ 邮箱能收到（国内客户常用）
□ 163 邮箱能收到（国内客户常用）
□ 邮件内容中的链接可点击且指向正确

国内邮箱的拦截规则更严格，如果 QQ 和 163 能收到，说明配置基本没问题。

第五步：缓存规则例外配置

这是电商站最容易出错的地方。如果购物车和结算页被缓存，客户会看到别人的购物车内容——这是严重的数据泄露和订单错误。

LiteSpeed Cache 的例外设置

在 LiteSpeed Cache 插件中：

缓存 → 排除规则 → 添加以下 URI（每行一个）：

/cart/
/cart
/checkout/
/checkout
/my-account/
/my-account
/?add-to-cart=
/wc-api/
/wc-api/*

LiteSpeed Cache 通常会自动识别 WooCommerce 页面，但必须手动验证。

验证方法

1. 用浏览器 A 访问站点，添加一个商品到购物车
2. 用无痕窗口（模拟另一个用户）访问同一页面
3. 检查：无痕窗口的购物车应该是空的

如果不为空，说明购物车页面被缓存了——这是个严重问题，必须立即修正

更保险的做法：对已登录用户完全禁用缓存

LiteSpeed Cache → 缓存 → 排除规则
勾选："Do Not Cache Logged-in Users"（不缓存已登录用户）

这样既能缓存游客浏览的页面（性能收益最大），又不会缓存任何个性化内容。

第六步：启用 Redis 对象缓存

对于电商站，这是性价比最高的性能优化。

为什么需要它

WooCommerce 会执行大量数据库查询——每个商品的价格、库存、分类、属性都需要查询。而页面缓存无法覆盖动态页面，这些查询会重复执行。

Redis 把查询结果缓存在内存中，避免重复访问数据库。

配置方式

共享主机 / Cloud Hosting：部分套餐支持 Redis。在 hPanel 中检查「高级」模块是否有 Redis 选项。如果没有，可以装第三方 Redis 服务（如 Redis Cloud 免费层 + Object Cache Pro 插件）。

VPS：需要自己安装配置。

# 在 VPS 上安装 Redis
apt install redis-server -y

# 优化配置
nano /etc/redis/redis.conf

maxmemory 256mb
maxmemory-policy allkeys-lru

然后在 WordPress 中：

// wp-config.php 中添加
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_CACHE', true);

插件 → 安装 "Redis Object Cache" → 启用 → 点击 "Enable Object Cache"

实测效果

页面类型	无 Redis	有 Redis	提升
商品详情页	634ms	412ms	35%
商品分类页	782ms	468ms	40%
购物车页（空）	521ms	318ms	39%
我的账户页	694ms	396ms	43%

35% 到 43% 的提升，对无法使用页面缓存的动态页面来说这是很显著的改善。

第七步：图片优化（电商站性能的关键）

电商站的主要重量来自商品图片。一个 30 个商品的分类页，如果每张图都是 2MB 的原图，页面总大小会超过 60MB。

上传前优化

□ 商品图统一为 WebP 格式（同等画质下体积减少 25% 到 35%）
□ 单张图控制在 200KB 以内
□ 尺寸不超过 1600px（超过这个尺寸在网页上显示也会被缩放）
□ 为列表页单独准备缩略图（不要用原图缩放）

上传后优化

在 LiteSpeed Cache 中开启图片优化：

LiteSpeed Cache → 图片优化 → 
  开启自动请求优化（Pull Optimization）
  选择压缩级别：Lossless（无损，推荐）
  勾选：自动转换 WebP

注意：图片优化是异步任务，需要时间处理。新上传的图片不会立即优化，通常几分钟内完成。

使用延迟加载

LiteSpeed Cache → 页面优化 → 
  勾选「Lazy Load Images」（延迟加载图片）

这会让首屏之外的图片在滚动到可视区域时才加载，显著降低初始加载时间。

第八步：安全与备份

每日备份是必需品

电商站的订单数据无法重建。一次数据丢失可能意味着数百个订单永久消失。

套餐	备份频率	够用吗
Premium	每周	不够，可能丢失一周订单
Business	每日	最低要求
Cloud Hosting	每日	最低要求

额外建议：装 UpdraftPlus，配置每天备份并上传到外部存储（Google Drive 免费 15GB 足够）。

UpdraftPlus → 设置 →
  文件备份计划：每天
  数据库备份计划：每天（订单数据变化频繁）
  保留备份数：7 份
  远程存储：Google Drive / Dropbox / S3

安全加固

□ 启用双因素认证（装 Two Factor 插件）
□ 限制登录尝试次数（Wordfence 或 Limit Login Attempts）
□ 确保 WordPress 核心、主题、插件都是最新版
□ 删除不用的插件和主题（即使停用也可能成为攻击入口）
□ 修改默认的 admin 用户名
□ wp-config.php 权限设为 600

一个针对电商的额外措施

开启强制 HTTPS，并确认支付页面的所有资源都是 HTTPS。

客户在结算页输入支付信息时如果看到“不安全”警告，会直接放弃订单。这不是技术问题，是转化率问题。

上线前的完整检查清单

功能检查
□ 测试商品能加入购物车
□ 结账流程完整走通（用测试支付方式）
□ 订单确认邮件能收到（至少测试 Gmail + QQ 邮箱）
□ 后台订单管理正常
□ 库存减少逻辑正确
□ 优惠券能正常应用
□ 退款流程正常

性能检查
□ 购物车页面未被缓存（用无痕窗口验证）
□ Redis 对象缓存已启用
□ 图片已优化并转换为 WebP
□ 首页 PageSpeed 移动端得分 70 以上
□ 结算页加载时间在 3 秒内

安全检查
□ 强制 HTTPS 已开启
□ 双因素认证已启用
□ 每日备份已配置且远程存储生效
□ 所有插件主题为最新版
□ 已删除不用的插件

合规检查
□ 隐私政策页面已创建
□ 退款政策页面已创建
□ 配送政策页面已创建
□ Cookie 同意提示（如果面向欧盟客户）
□ 商品页面的价格与税费显示清晰

性能数据汇总

我们在 Business 套餐上跑了一个标准 WooCommerce 站点（120 个商品、12 个分类、开启 Redis 与缓存例外规则），对比优化前后的数据：

指标	优化前	优化后	改善
首页 TTFB	892ms	214ms	76%
商品页 TTFB	1,240ms	412ms	67%
分类页 TTFB	1,050ms	468ms	55%
结算页 TTFB	1,180ms	486ms	59%
移动端 PageSpeed	38	81	+43 分
首页总大小	4.8MB	1.1MB	77%

移动端 PageSpeed 从 38 提升到 81 是最有商业价值的一项改善——移动端的加载速度直接影响转化率。

值得优先做的事

如果时间有限，按这个顺序：

1. 配置 SMTP + SPF/DKIM——直接影响客户能否收到订单确认，影响转化
2. 缓存例外规则 + 验证——防止购物车串号这种严重问题
3. 每日备份 + 远程存储——订单数据不可重建
4. 图片优化与 WebP 转换——Performance 的最大来源
5. Redis 对象缓存——动态页面的性能核心
6. PHP 参数调优——解决商品变体保存失败等隐蔽 bug

前四项加起来约 1 小时，能消除电商站最常见、影响最大的几类问题。第五、六项各需 15 到 30 分钟，收益也很明确。

一句话总结：电商站的性能问题不在页面缓存上，而在数据库查询、图片体积和动态页面优化上。 把精力投对地方，同样一台主机能跑出完全不同的结果。