简介：Woocommerce 3.5.2 安装包面向使用 WordPress 搭建在线商店的开发者与站长，尤其适合需要稳定旧版本、排查兼容性问题的中初级用户。该版本在性能优化、WordPress 5.x 兼容、安全补丁、支付网关支持、税费计算与多语言等方面均有改进，可用于搭建商品管理、购物车、结账与订单处理等完整电商流程。压缩包共 1099 个文件，约 3.73MB，以 814 个 php 核心逻辑文件为主，辅以 142 个 js 交互脚本、36 个 css 与 20 个 scss 样式文件，以及 png、svg、gif 等图片资源和少量字体、语言包文件，结构完整，便于二次开发与主题定制。目前已有 439 人学习下载。通过该安装包，读者可获得可直接部署的插件源码，结合管理面板、报表统计与物流配送等模块，快速理解 Woocommerce 的目录组织与扩展方式，为店铺搭建、功能调试和版本升级提供参考。
1. 拿到 woocommerce3.5.2 安装包之后：一个老版本电商插件的复活现场
如果你手里正躺着一个woocommerce3.5.2的压缩包，大概率不是主动想用它，而是被某个老站点的兼容性逼到了墙角。我最近就碰到一个跑了七八年的内容站，主题和几个自定义短代码全绑死在 WooCommerce 3.x 的钩子签名上，升级到 8.x 直接白屏。这时候woocommerce3.5.2安装包就不是怀旧，而是让站点先活下来的止血包。它解决的核心问题很具体：在 PHP 7.0 到 7.2 的环境里，用一套没被新版重构过的商品、购物车、结算逻辑把交易链路重新拉起来。适合谁？适合维护存量老站、做本地复现、或者需要研究早期 WooCommerce 数据表结构的人。不适合新站，新站直接上当前稳定版，别给自己找事。
2. 安装包到手先别急着传：环境核对与目录结构拆解
2.1 为什么 3.5.2 对 PHP 版本这么挑
WooCommerce 3.5.2 是 2018 年底的产物，那个时间点 WordPress 主流还是 4.9 到 5.0，PHP 7.2 刚铺开。这个版本里大量用了create_function的残留写法、没有类型声明的数组回调，以及直接访问$wpdb->prefix拼 SQL 的习惯。放到 PHP 8.0 以上，create_function被移除，直接就是致命错误；放到 PHP 7.4，虽然能跑，但implode参数顺序反转的弃用警告会刷满日志。我一般会把环境锁在 PHP 7.2 加 WordPress 5.0 到 5.3 这个区间，MySQL 用 5.6 或 5.7，别上 8.0，因为 3.5.2 的建表语句里还有utf8mb4_unicode_ci和旧版datetime默认值混用的情况，MySQL 8.0 的严格模式会直接拒绝。
先做一次环境体检，把下面这段放进一个临时 php 文件里跑一下，看完就删：
<?php // 临时环境探针，检查 PHP 版本和关键扩展 echo 'PHP: ' . PHP_VERSION . "\n"; echo 'MySQLi: ' . (extension_loaded('mysqli') ? 'yes' : 'no') . "\n"; echo 'GD: ' . (extension_loaded('gd') ? 'yes' : 'no') . "\n"; echo 'cURL: ' . (extension_loaded('curl') ? 'yes' : 'no') . "\n"; echo 'memory_limit: ' . ini_get('memory_limit') . "\n"; echo 'max_execution_time: ' . ini_get('max_execution_time') . "\n";逻辑说明：WooCommerce 3.5.2 的商品图片缩略图依赖 GD，支付回调和运费计算依赖 cURL，订单导出和报表会吃内存。参数上，memory_limit建议不低于 256M，max_execution_time至少 120，否则批量更新商品库存时容易半路断掉。如果 GD 没开，商品列表里的占位图会全部裂开，这个坑我踩过，排查了半天以为是主题问题。
2.2 解压后先看这几个文件，别整包直接扔进去
拿到woocommerce3.5.2安装包，先本地解压，不要通过 WordPress 后台上传。后台上传有文件大小限制，而且一旦超时你会得到一个半残的插件目录，清理起来更麻烦。解压后重点看根目录的woocommerce.php、includes/class-woocommerce.php和includes/wc-core-functions.php。woocommerce.php里的版本号头信息决定了 WordPress 能不能识别它，class-woocommerce.php里定义了WC_VERSION常量，这个常量在后续很多主题判断里会用到。
目录结构上，assets放前端 CSS 和 JS，includes是核心逻辑，templates是所有可被主题覆盖的模板文件，i18n是语言包。我一般会先确认templates目录下有没有被当前主题覆盖过的同名文件，如果有，升级或替换插件时这些覆盖文件不会自动更新，会导致新旧逻辑混用。常见做法是先把主题里的woocommerce文件夹临时改名，让插件用自带模板跑一遍，确认基础功能正常后再逐个恢复覆盖。
2.3 手动安装的完整命令与权限设置
如果你有服务器 SSH 权限，用命令行安装比后台上传稳得多。假设 WordPress 根目录在/var/www/html，安装包在/tmp/woocommerce.3.5.2.zip：
# 进入插件目录 cd /var/www/html/wp-content/plugins # 解压安装包，注意 zip 内层可能还有一层目录 unzip -q /tmp/woocommerce.3.5.2.zip # 确认解压后的目录名，通常是 woocommerce ls -d woocommerce # 把属主改成 Web 服务运行用户，避免权限报错 chown -R www-data:www-data woocommerce # 目录 755，文件 644，这是 WordPress 最稳的权限组合 find woocommerce -type d -exec chmod 755 {} \; find woocommerce -type f -exec chmod 644 {} \;逻辑说明：unzip -q的-q是安静模式，避免刷屏。chown里的www-data要换成你实际 Web 服务的运行用户，有的环境是nginx或apache。权限设置这一步很多人跳过，结果后台激活插件时提示“无法创建目录”，其实就是文件属主不对。参数上，不要图省事给 777，那会带来安全隐患，755 和 644 足够。
激活之前，先到 WordPress 后台的插件列表里刷新一下，应该能看到 WooCommerce 3.5.2 出现在列表里。如果没出现，检查woocommerce.php文件头是否有完整的Plugin Name和Version注释。激活后，WooCommerce 会引导你跑安装向导，创建商品、购物车、结算、我的账户等基础页面。这一步别跳过，手动建页面容易漏掉短代码，比如结算页必须是[woocommerce_checkout]，少一个字母整个流程就断。
3. 让 3.5.2 在旧环境里真正跑起来：数据库、页面与短代码
3.1 数据表创建与 wp_options 里的关键项
WooCommerce 激活时会自动建表，3.5.2 一共会新增 8 张左右的自定义表，包括woocommerce_order_items、woocommerce_order_itemmeta、woocommerce_termmeta、woocommerce_downloadable_product_permissions等。如果你是从旧站迁移过来，数据库里可能已经有这些表，激活时它会检测并跳过创建。但有一种情况会翻车：旧表结构是 2.x 时代的，字段类型和 3.5.2 不匹配，比如order_itemmeta的meta_value字段在旧版是longtext，新版期望longtext但索引不同。这时候需要手动比对表结构。
我一般会先跑一条查询，看看关键表是否存在以及行数：
-- 检查 WooCommerce 核心表是否存在 SELECT table_name, table_rows FROM information_schema.tables WHERE table_schema = '你的数据库名' AND table_name LIKE 'wp_woocommerce%' ORDER BY table_name;逻辑说明：table_rows在 InnoDB 下是估算值，不用太精确，主要看表有没有缺失。如果wp_woocommerce_order_items不存在，说明激活时建表失败了，去wp-content/debug.log里找 SQL 错误。参数上，把你的数据库名和wp_前缀换成实际的。常见坑是数据库用户没有CREATE TABLE权限，激活时静默失败，后台却显示“插件已激活”，结果一下单就报错。
wp_options表里，3.5.2 会写入woocommerce_db_version这个选项，值是3.5.2。如果你从更高版本降级回来，这个值可能还是 8.x，导致插件认为数据库已经是最新，跳过必要的升级例程。这时候需要手动把它改回3.5.2，然后重新访问后台，让它跑一遍降级兼容逻辑。改之前先备份wp_options，这个表很敏感。
3.2 页面短代码与固定链接的联动
WooCommerce 3.5.2 依赖几个核心短代码：[woocommerce_cart]、[woocommerce_checkout]、[woocommerce_my_account]、[woocommerce_order_tracking]。安装向导会自动创建对应页面并插入短代码，但如果你是从旧站导入页面，短代码可能被编辑器转义成了 HTML 实体，比如[woocommerce_cart]变成[woocommerce_cart]。这时候页面会显示原始短代码文本，而不是购物车。解决办法是进编辑器，切到文本模式，把实体字符改回方括号。
固定链接也要注意。3.5.2 的端点（endpoint）比如order-received、order-pay、view-order是挂在“我的账户”页面下的。如果固定链接用的是“朴素”模式，这些端点会 404。我一般会把固定链接设为“文章名”或“自定义结构”，然后到 WooCommerce 设置里的“高级”标签页，确认“我的账户端点”没有冲突。改完固定链接后，记得保存一次，让 rewrite 规则刷新。
3.3 用 WP-CLI 批量检查订单与商品数据
如果你是在做数据迁移或本地复现，WP-CLI 比后台点来点去快得多。假设环境里已经装了 WP-CLI，下面这组命令可以快速摸清家底：
# 查看 WooCommerce 版本和数据库版本 wp plugin get woocommerce --field=version wp option get woocommerce_db_version # 统计商品数量，按状态分组 wp post list --post_type=product --post_status=any --format=count wp post list --post_type=product --post_status=publish --format=count # 列出最近 5 个订单的 ID 和状态 wp post list --post_type=shop_order --posts_per_page=5 --fields=ID,post_status,post_date # 检查是否有卡在 pending 的订单 wp post list --post_type=shop_order --post_status=wc-pending --format=count逻辑说明：wp post list的--post_type=shop_order在 3.5.2 里订单还是以自定义文章类型存储的，到 4.x 之后才逐步引入 HPOS 高性能订单存储。所以这个命令在 3.5.2 上完全适用。参数上，--format=count只输出数量，适合写进监控脚本。如果wc-pending数量异常大，说明支付回调没正常触发，去检查支付网关的异步通知地址是否可达。
3.4 主题兼容层：声明支持与模板覆盖
WooCommerce 3.5.2 会在前台检测当前主题有没有声明woocommerce支持。如果主题的functions.php里没有add_theme_support( 'woocommerce' );，商品列表页的样式会错乱，而且“添加到购物车”的 AJAX 可能失效。我一般会在子主题的functions.php里补上这几行：
// 在子主题中声明 WooCommerce 支持 add_action( 'after_setup_theme', function() { add_theme_support( 'woocommerce' ); // 3.5.2 支持的产品画廊缩放效果 add_theme_support( 'wc-product-gallery-zoom' ); add_theme_support( 'wc-product-gallery-lightbox' ); add_theme_support( 'wc-product-gallery-slider' ); });逻辑说明：after_setup_theme钩子确保在主题加载完成后声明，避免时机过早被覆盖。三个画廊支持是可选的，但如果主题没有声明，3.5.2 的商品详情页主图下面不会出现缩略图轮播。参数上，如果你不需要灯箱效果，可以去掉lightbox那行，减少一个前端脚本加载。
模板覆盖方面，3.5.2 的模板文件在templates目录下，主题可以通过在自身目录里建woocommerce文件夹来覆盖。但覆盖有风险：插件更新时模板可能变化，而你的覆盖文件不会变。我一般只覆盖必须改的，比如single-product/price.php或cart/cart-totals.php，并且会在覆盖文件头部注释里写清楚对应的插件版本号，方便日后比对。
4. 避坑与排查：3.5.2 最容易翻车的五个地方
4.1 后台激活成功但前台 500
现象：插件列表显示已激活，但访问商品页或购物车页直接白屏或 500。原因通常是 PHP 版本不兼容，3.5.2 里某个函数在 PHP 7.4 以上被弃用或移除，比如get_magic_quotes_gpc在 PHP 8.0 被移除。解决：把 PHP 版本降到 7.2，或者临时在wp-config.php里开启WP_DEBUG和WP_DEBUG_LOG，看wp-content/debug.log里具体是哪个文件哪一行报错。如果必须用高版本 PHP，只能逐个文件打补丁，不推荐。
4.2 结算页一直转圈，AJAX 请求 404
现象：点击“下单”按钮后一直转圈，浏览器控制台显示admin-ajax.php返回 404 或 0。原因通常是固定链接规则没刷新，或者服务器伪静态没配好。解决：到 WordPress 后台“设置-固定链接”里直接点“保存更改”，这会刷新 rewrite 规则。如果用的是 Nginx，确认try_files $uri $uri/ /index.php?$args;这行存在。另外检查admin-ajax.php的 URL 是否被安全插件拦截，有些防火墙会误判 WooCommerce 的 AJAX 请求。
4.3 商品图片上传后不显示缩略图
现象：后台上传商品图片成功，但前台商品列表里图片是破图或空白。原因通常是 GD 库没装，或者wp-content/uploads目录权限不对。解决：先跑第 2.1 节的环境探针确认 GD 已加载。如果 GD 正常，检查上传目录权限，确保 Web 用户可写。还有一个隐蔽原因：3.5.2 的图片缩略图尺寸是在激活时注册的，如果你中途改了主题的图片尺寸，需要重新生成缩略图，用wp media regenerate命令批量处理。
4.4 订单邮件收不到，SMTP 配置被忽略
现象：下单后客户和管理员都收不到订单通知邮件。原因：3.5.2 默认用 PHP 的mail()函数发信，很多服务器禁用了这个函数，或者邮件直接进了垃圾箱。解决：装一个 SMTP 插件，把发信方式改成 SMTP 认证。注意 3.5.2 时代有些 SMTP 插件版本较老，要选兼容 WordPress 5.0 的版本。配置完后用“测试邮件”功能验证，别等真实订单来了才发现收不到。
4.5 降级后数据库版本号不匹配导致循环提示
现象：从高版本降回 3.5.2 后，后台一直提示“数据库需要更新”，点更新又失败。原因：wp_options里的woocommerce_db_version还是高版本的值，而 3.5.2 的升级例程不认识这个版本号。解决：先备份数据库，然后手动把woocommerce_db_version改成3.5.2，同时检查wp_woocommerce_*表里有没有高版本新增的字段，如果有，需要手动删除或忽略。这个操作有风险，建议在本地先演练一遍。
5. 把 3.5.2 用出余热：本地复现、数据导出与迁移前验证
如果你只是临时用woocommerce3.5.2安装包救急，那到上一章就够了。但如果你需要长期维护这个老站，或者要把数据迁到新环境，有几个技巧能让这件事不那么痛苦。我一般会在本地用 Docker 搭一个一次性环境，把 3.5.2 跑起来，专门用来做数据导出和迁移前的字段映射验证。Docker 的好处是环境隔离，PHP 7.2 和 MySQL 5.7 用镜像固定住，不会污染宿主机。
# 启动一个 PHP 7.2 + MySQL 5.7 的临时环境 docker run -d --name wc352-env \ -p 8080:80 \ -e WORDPRESS_DB_HOST=db \ -e WORDPRESS_DB_USER=wc \ -e WORDPRESS_DB_PASSWORD=wcpass \ -e WORDPRESS_DB_NAME=wc352 \ wordpress:5.0-php7.2-apache # 另起一个 MySQL 5.7 容器 docker run -d --name wc352-db \ -e MYSQL_ROOT_PASSWORD=rootpass \ -e MYSQL_DATABASE=wc352 \ -e MYSQL_USER=wc \ -e MYSQL_PASSWORD=wcpass \ mysql:5.7逻辑说明：wordpress:5.0-php7.2-apache这个镜像组合是经过验证能跑 3.5.2 的。参数上，端口映射8080:80避免和宿主机已有服务冲突。数据库容器和 WordPress 容器通过 Docker 网络互联，WORDPRESS_DB_HOST填db需要先创建自定义网络，或者直接用--link，但--link已不推荐。更稳的做法是docker network create wcnet，然后两个容器都加入这个网络。
环境跑起来后，把woocommerce3.5.2安装包解压到wp-content/plugins，激活，导入生产库的脱敏数据。然后重点验证三件事：订单状态流转是否正常、优惠券计算是否准确、税率规则是否匹配。这三块在 3.5.2 里逻辑比较绕，尤其是含税和不含税切换时，wc_get_price_including_tax和wc_get_price_excluding_tax的调用时机不同，结果会差几分钱。迁移前一定要用真实订单数据跑一遍对账。
导出数据时，3.5.2 自带的导出工具在“WooCommerce-系统状态-工具-导出”里，可以导出订单 CSV。但那个导出器对自定义字段支持不好，如果订单里有自定义的order_itemmeta，需要自己写 SQL 查。我一般会直接查wp_woocommerce_order_items和wp_woocommerce_order_itemmeta联表，把关键字段拉出来：
-- 导出订单商品明细，包含自定义元数据 SELECT oi.order_id, oi.order_item_name, oi.order_item_type, oim.meta_key, oim.meta_value FROM wp_woocommerce_order_items oi LEFT JOIN wp_woocommerce_order_itemmeta oim ON oi.order_item_id = oim.order_item_id WHERE oi.order_item_type = 'line_item' ORDER BY oi.order_id DESC LIMIT 100;逻辑说明：order_item_type = 'line_item'过滤出商品行，排除运费和手续费行。meta_key里常见的有_qty、_line_total、_line_tax、_product_id、_variation_id。参数上，LIMIT 100先抽样看结构，确认无误后再去掉限制全量导出。如果meta_value里存的是序列化数组，导出后需要反序列化才能读，这个在迁移到新系统时尤其要注意，新版本 WooCommerce 可能已经改用 JSON 或独立表存储。
最后一个习惯：每次动 3.5.2 的数据库之前，先mysqldump一份完整备份，并且把备份文件拉到本地。老版本的升级和降级路径不像新版本那么平滑，一旦中途出错，没有后悔药。我见过一次因为直接改woocommerce_db_version导致订单表索引损坏的情况，最后只能从备份恢复。所以，备份不是可选项，是必选项。希望帮到你。
本文还有配套的精品资源，点击获取
