简介：这套源码包是一份可运行的网购商城系统，融合积分兑换、网店买卖交易和独立代理后台，面向需要快速部署电商平台的开发者、中小卖家及电商技术学习者。系统以PHP为后端核心，配合HTML/CSS/JS构建前端交互，附带了数据库、证书和图文搭建教程，支持商品管理、订单处理、用户积分等功能，能够从零落地一套完整的B2C商城。包内共2000个文件，压缩后约292.96MB，主要文件类型包括668个HTML页面、317个PHP逻辑文件、237个JS脚本和340个CSS样式，另有SQL备份、图片、配置文件等，目录结构清晰，便于按模块查找与二次开发。该源码的亮点在于购买商品后可选择直接发货或拆红包升级商品，同时独立代理后台支持多级分销管理，可有效增强营销灵活性和用户粘性。目前已有315人学习下载，适合具备PHP基础并希望研究电商系统架构、积分玩法或代理分销机制的读者。
1. 这套商城源码 zip 到手后，先想明白三件事
做电商系统，最容易被一句话误导：“有源码，解压就能用”。实际上这类网购商城系统源码包，能跑起来和能卖货之间隔着两件事：环境配平、业务规则梳理。尤其是带积分兑换的商城，它不只是多了一个积分页面，而是从注册、下单、支付到兑换核销全链路都塞进了一套规则，这块才是最值得花时间去读的部分。
以我经手这类源码包的经验，市面上流通的多数是 PHP 系方案（ThinkPHP、Laravel 或原生 CI），偶尔见到 Java 系和 Python 系。它们的目录结构、部署方式差别不小，但设计思路差不多：前台展示、后台管理、会员体系、支付模块、订单流转。拿到 zip 后的正确顺序，不是急着配 Nginx，而是先弄明白这套源码面对的人群——你是要自建商城卖货的小团队，还是拿来做课程设计的在校生，又或者是接外包想加速交付的开发者——决定了你要投入多少精力。
2. 把 .zip 商城源码跑起来：环境配平与最小部署步骤
2.1 先确认技术栈：打开压缩包看这三个位置
很多人拿到商城系统源码.zip，第一反应是直接解压到 Web 目录，然后访问域名，结果看到一片空白或被重定向到安装页面。这通常不是代码问题，而是没先判断项目是什么语言写的、需要哪些扩展。花三分钟看目录结构，比盲目调试两小时更有效率。
一个标准 PHP 商城源码包解压后，你会看到类似这样的结构：
# 解压后，定位到项目的根目录 find . -maxdepth 2 -type f | head -50逻辑说明：find配合maxdepth只看前两层文件，目的是快速识别项目规模。入口文件和配置文件是重点观察对象——如果有index.php、application/、config/目录，基本就是 PHP 系（ThinkPHP 或 Laravel）的项目；如果看到pom.xml或src/main/java，那是 Java 系；如果看到manage.py或requirements.txt，就是 Python 系（Django 或 Flask）。
参数说明：-maxdepth 2控制递归深度，避免整个目录刷屏；head -50只显示前 50 条结果，防止构建缓存目录占用输出。
我处理过的这类商城源码包，八成以上是 PHP 7 系以下的代码——不是 PHP 8 跑不了，而是很多老商城用了mysql_开头的旧函数或依赖GD扩展，换到高版本 PHP 后会出现致命错误。判断 PHP 版本是否匹配，最直接的办法是看入口文件：
// index.php 入口文件常见内容 <?php // 定义应用目录 define('APP_PATH', __DIR__ . '/../application/'); // 加载框架引导文件 require __DIR__ . '/../thinkphp/start.php';这里出现thinkphp的start.php，说明项目基于 ThinkPHP 3.2 或 5.0。ThinkPHP 3.2 最高支持到 PHP 7.0/7.1，5.0 支持 PHP 7.x，如果你的服务器默认装了 PHP 8.0 以上，大概率会报Cannot use "parent" when current class scope has no parent这类框架兼容性错误。所以，第一步的关键不是启动服务，而是确认技术栈版本。
2.2 本地环境准备：Linux 下最小组合的安装命令
部署这套系统，你需要的不是什么复杂架构，一台 2 核 4G 的云服务器或本地虚拟机就够了。PHP、MySQL、Nginx 是主力，Redis 看需求——商城系统通常用它做购物车和验证码缓存，先用可选项处理。
# 以 Ubuntu 20.04 为例，安装 PHP 7.4 和对应扩展 sudo apt update sudo apt install -y php7.4-fpm php7.4-mysql php7.4-gd php7.4-curl \ php7.4-mbstring php7.4-xml php7.4-zip php7.4-redis # 安装 Nginx 和 MySQL sudo apt install -y nginx mysql-server-5.7 # 启动服务 sudo systemctl enable --now nginx mysql php7.4-fpm逻辑说明：php7.4-*一系列扩展是多数商城源码的硬性依赖，特别是php7.4-curl（支付回调要用）和php7.4-gd（验证码和图片裁剪要用）。redis扩展不强求，但如果源码里写了配置项而你没装，Redis 连接失败会导致登录状态写入报错，这是新手最容易翻车的地方。
参数说明：MySQL 5.7 是保守选择，很多商城 SQL 文件带着DEFAULT CHARSET=utf8mb4和ENGINE=MyISAM，高版本 MySQL 8 对utf8mb4的索引长度限制更严格，容易导入报错。如果你用 MySQL 8，提前加innodb_large_prefix=ON能减少意外。
装完用php -v确认版本，再执行php -m | grep -iE "gd|curl|pdo"确认扩展都加载进来。这一步的目的是减少后续排查范围——环境问题必须在前，代码问题才能暴露出来。
2.3 解压、配 Nginx 伪静态、导入数据库：让首页先正常显示
环境就绪后，开始部署。把 zip 包解压到站点目录，这里要留意压缩包内部的路径，很多源码包把文件放在shop/或项目根目录之下，直接解压会多套一层目录，需要先解压到临时目录再移动。
# 创建站点目录并解压 mkdir -p /data/wwwroot/shop unzip -q shop_mall.zip -d /data/wwwroot/shop # 如果套了一层目录，解除嵌套 mv /data/wwwroot/shop/*/* /data/wwwroot/shop/ # 给 PHP-FPM 用的运行目录配权限 chown -R www-data:www-data /data/wwwroot/shop chmod -R 755 /data/wwwroot/shop逻辑说明：unzip -q的-q参数是安静模式，解压大量小文件时不会刷屏。chown确保运行用户有读写权限，特别是upload、runtime、data这几个目录，缺少写权限会直接导致图片上传失败、模板缓存生成不了。
参数说明：如果压缩包有密码，用unzip -P指定密码解压，但更安全的做法是先解压到本地确认内容，再上传到服务器。这一步涉及的是安全和信任问题，源码包里可能藏有后门文件，这个我在第 5 章会详细展开。
接下来配置 Nginx 站点。多数 PHP 商城走的是伪静态路径，访问index.php/Home/Index/index这类 URL。Nginx 里同样的请求路径，需要try_files配合pathinfo解析：
server { listen 80; server_name shop.example.com; root /data/wwwroot/shop/public; index index.php index.html; location / { # 如果文件或目录不存在，回退到入口文件 try_files $uri $uri/ /index.php?s=$uri&$args; } location ~ \.php$ { include fastcgi_params; fastcgi_pass unix:/run/php/php7.4-fpm.sock; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } }逻辑说明：try_files的顺序是从$uri真实文件开始找，找不到就尝试$uri/目录，再不行就交给index.php处理，这是 ThinkPHP 和 Laravel 两种框架通用的回退策略。fastcgi_pass用的是 socket 通信，比 TCP 方式更稳定，排除了端口占用的问题。
参数说明：server_name要与你的域名或本地 host 对应。root指向的项目目录，我写的是public——如果你的源码是根目录直接放模板和静态资源，就把 root 指到shop根路径。
最后导入数据库。找到源码包里的.sql文件，用命令行导入：
# 创建数据库并导入 mysql -uroot -p -e "CREATE DATABASE shop_mall DEFAULT CHARSET utf8mb4;" mysql -uroot -p shop_mall < shop_mall.sql # 导入完成后确认表数量 mysql -uroot -p -e "USE shop_mall; SHOW TABLES;" | wc -l逻辑说明：<重定向导入是最直接的方式，比用 phpMyAdmin 导入大文件安全。.sql文件超过 50MB 时，phpMyAdmin 经常超时，命令行不受这个限制。确认表数量的目的是判断导入是否完整——比如一套完整商城至少要有 50 张表，如果只有十几张，说明 SQL 文件执行到一半就断了。
参数说明：数据库字符集统一用utf8mb4，这能兼容商品名称里的 emoji 和生僻字。如果你用 MySQL 5.7，需要确认my.cnf里innodb_large_prefix是开启的，否则带前缀索引的表会导入失败。
数据库导完，改项目配置。PHP 源码的连接配置通常在application/database.php或.env文件里：
return [ 'hostname' => '127.0.0.1', 'database' => 'shop_mall', 'username' => 'shop_user', 'password' => '改成你自己的强密码', 'hostport' => '3306', 'charset' => 'utf8mb4', ];以上是最小部署的全部步骤。做完这四件事，首页应该能打开了。但整套系统的核心——积分兑换——还只是停留在数据库表层面，下一章进入正题。
3. 积分兑换的实现机制：从三张表到一笔兑换订单
3.1 积分相关的表结构：总表、流水表和商品表
很多商城源码把积分功能做成了装饰品：用户注册送积分、商品详情页显示积分价格，但真正兑换时要么没扣库存，要么积分扣了商品没发。要搞清一套商城源码的积分体系健不健壮，先看它的数据库表设计。通常一个能用的积分商城至少有这三张表：
-- 会员积分总表：记录每个用户当前可用积分 CREATE TABLE `member_points` ( `id` int(11) NOT NULL AUTO_INCREMENT, `user_id` int(11) NOT NULL COMMENT '会员ID，关联会员表', `points` int(11) NOT NULL DEFAULT 0 COMMENT '当前可用积分', `total_points` int(11) NOT NULL DEFAULT 0 COMMENT '累计获得积分（不因消费减少）', `frozen_points` int(11) NOT NULL DEFAULT 0 COMMENT '冻结积分：订单未完成前暂扣', `updated_at` int(11) NOT NULL DEFAULT 0, PRIMARY KEY (`id`), UNIQUE KEY `user_id` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='会员积分总表'; -- 积分流水表：每一笔变动的记录 CREATE TABLE `points_log` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `user_id` int(11) NOT NULL, `change_points` int(11) NOT NULL COMMENT '正数增加，负数扣减', `type` tinyint(1) NOT NULL DEFAULT 0 COMMENT '1注册赠送 2购物返还 3积分兑换扣减 4后台调整', `order_sn` varchar(32) DEFAULT '' COMMENT '关联的订单号，没有则为空', `remark` varchar(255) DEFAULT '' COMMENT '备注：哪笔订单、哪个商品', `created_at` int(11) NOT NULL, PRIMARY KEY (`id`), KEY `user_id` (`user_id`), KEY `order_sn` (`order_sn`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='积分流水表'; -- 积分兑换商品表 CREATE TABLE `points_goods` ( `id` int(11) NOT NULL AUTO_INCREMENT, `goods_name` varchar(255) NOT NULL COMMENT '商品名称', `goods_thumb` varchar(255) NOT NULL COMMENT '商品缩略图', `points_price` int(11) NOT NULL COMMENT '兑换所需积分', `stock` int(11) NOT NULL DEFAULT 0 COMMENT '库存', `status` tinyint(1) NOT NULL DEFAULT 1 COMMENT '1上架 2下架', `exchange_limit` int(11) NOT NULL DEFAULT 1 COMMENT '每人限兑数量', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='积分商品表';逻辑说明：三张表的设计逻辑是，member_points管总数，points_log管历史，points_goods管商品。其中最关键的是member_points里单独拆出frozen_points——订单支付前先冻结积分，订单完成后才真正扣掉，订单退款时解冻返还。这个字段的存在，直接决定了商城能否处理“兑换后申请退款”的场景。
如果源码里没有frozen_points字段，说明它的积分兑换是即时扣减，遇到退款你就得手动补积分，这是一处典型的设计短板。我经手过的源码里有一半是这样的，可以用但不好用。
3.2 一笔积分兑换订单的完整流转：代码怎么走
表结构清楚后，看兑换的下单逻辑。以典型的 PHP 商城模块为例，积分商城的兑换接口通常长这样：
public function doExchange($userId, $goodsId) { // 开启事务，保证积分扣减、库存扣减、发单是原子操作 Db::startTrans(); try { // 1. 查积分商品，锁定该行（加悲观锁避免超卖） $goods = Db::name('points_goods') ->where('id', $goodsId) ->lock(true) ->find(); if ($goods['status'] != 1 || $goods['stock'] <= 0) { throw new \Exception('商品已下架或库存不足'); } // 2. 查用户积分 $member = Db::name('member_points') ->where('user_id', $userId) ->lock(true) ->find(); if ($member['points'] < $goods['points_price']) { throw new \Exception('积分不足，当前积分：' . $member['points']); } // 3. 扣用户积分（一次性更新语句，并发安全） Db::name('member_points') ->where('user_id', $userId) ->setDec('points', $goods['points_price']); // 4. 减库存 Db::name('points_goods') ->where('id', $goodsId) ->setDec('stock', 1); // 5. 生成积分兑换订单 $orderSn = $this->generateOrderSn($userId); Db::name('points_order')->insert([ 'order_sn' => $orderSn, 'user_id' => $userId, 'goods_id' => $goodsId, 'points' => $goods['points_price'], 'status' => 0, // 0 待发货 'add_time' => time(), ]); // 6. 写积分流水 Db::name('points_log')->insert([ 'user_id' => $userId, 'change_points' => -$goods['points_price'], 'type' => 3, // 积分兑换扣减 'order_sn' => $orderSn, 'remark' => '兑换商品：' . $goods['goods_name'], 'created_at' => time(), ]); Db::commit(); return json(['code' => 0, 'msg' => '兑换成功']); } catch (\Exception $e) { Db::rollback(); return json(['code' => 1, 'msg' => $e->getMessage()]); } }逻辑说明：这段代码的核心就一句话——把“扣积分、减库存、发订单、写流水”这四步放在一个数据库事务里，任意一步失败，全部回滚。lock(true)是加悲观锁，它的作用是防止两个请求同时看到库存为 1，然后都通过校验，最后把库存扣成负数。
参数说明：setDec是 ThinkPHP 的字段自减方法，生成的 SQL 是UPDATE member_points SET points = points - 1 WHERE user_id = ?，这条 SQL 本身是原子操作，不会出现“先读后写”的并发问题。frozen_points在这个流程里没有被用到——如果你的商城要求订单完成后才扣积分，第 3 步应该改成先冻结而不是直接扣。
这一段代码是积分商城的“心脏”。拿到任何一套商城源码，第一件事就看它的下单函数有没有事务、有没有锁。没有事务的，说明并发场景下会翻车——后台有 3 个人同时抢同一个积分商品，库存就变负数了。
3.3 后台积分配置：五档规则调参参考
积分兑换不只是写代码，后台的积分配置决定了运营玩法。我整理了一套常见参数，可以直接对照源码里的后台设置项来检查：
| 配置项 | 典型值 | 作用 | 代码注意点 |
|---|---|---|---|
| 注册赠送积分 | 50 | 拉新用户 | 在注册成功回调里调用积分入账函数 |
| 消费积分比例 | 1 元 = 1 积分 | 激励复购 | 订单完成回调里按实付金额计算 |
| 每日签到积分 | 前 3 天递增 | 提升日活 | 缓存当天的签到记录，防重复签到 |
| 兑换物流费 | 积分 + 运费 | 控制补贴成本 | 运费字段独立于积分价格，单独计算 |
| 积分有效期 | 12 个月 | 防止积分通胀 | 用 schedule 定时清理过期积分 |
这几个参数在后台界面通常能找到对应输入框。如果你的源码只有积分功能但没开放这些配置入口，那意味着开发时把它写死了，这个后面要改起来比较费劲，我在第 6 章会讲怎么改。
4. 上线前必须改的配置：支付、短信、物流与安全
4.1 支付接口接入：以支付宝和微信扫码支付为例
商城源码跑起来以后，最迫切的事情是接支付。绝大多数源码支持支付宝和微信支付，但默认配置是测试模式。以支付宝当面付（扫码支付）为例，找到支付配置文件或统一配置入口：
// application/extra/alipay.php return [ 'app_id' => '2021003122600000', // 支付宝开放平台应用 ID 'merchant_private_key' => 'MIIEvQIBADANB...', // 应用私钥 'alipay_public_key' => 'MIIBIjANBgkqhkiG...', // 支付宝公钥 'notify_url' => 'https://shop.example.com/index.php/Home/Pay/notify', 'return_url' => 'https://shop.example.com/index.php/Home/Pay/return', 'charset' => 'utf-8', 'sign_type' => 'RSA2', 'gateway_url' => 'https://openapi.alipay.com/gateway.do', ];逻辑说明：支付配置里最容易漏的是notify_url（异步回调地址）。支付宝会在这个 URL 上以 POST 方式推送支付结果，你的商城系统要在这个接口里完成“验签 → 更新订单状态 → 返回 success”三步。很多商城源码的支付回调只有更新订单状态，缺了验签，存在别人伪造回调把订单改成已支付的逻辑漏洞。
参数说明：RSA2是必选的签名方式，旧代码里写的RSA会在支付宝侧报签名错误。return_url是支付成功后跳回前台页面的地址，notify_url才是真正决定订单状态的地方。这里有个细节，支付宝会持续回调最多 24 小时，直到你的接口返回success，所以接口里任何异常情况都要主动返回fail而不是什么都不处理。
微信支付那边的逻辑类似，需要注意的是微信支付 API v3 需要证书文件（apiclient_cert.pem和apiclient_key.pem），要把证书路径配置到源码指定的目录。我在部署时遇到过源码把证书放在Public/cert/下，但忘记给 www-data 用户读权限的情况，导致支付下单时报“证书不可读”。
4.2 短信验证码与物流接口：各自申请账号
商城源码的短信服务一般都走阿里云短信或腾讯云短信，不需要在代码里大改，只需要在后台配置里填入AccessKeyId、AccessKeySecret和签名模板。这块要注意的是，很多源码的短信配置项是独立的，和支付配置不在同一个文件里，容易漏配。
物流接口同理，快递鸟或快递 100 的接口配置，通常只需要把后台的express_app_id和express_app_key填好，前端物流查询页面就能工作。如果源码本身不带物流查询模块，那依赖于你的版本，这部分功能用第三方 iframe 嵌入也能实现，不一定要动源码。优先级上，支付和短信必须赶在上线前配好，物流接口可以后续再补。
4.3 安全配置：目录权限、后台入口和备份
安全这块没处理好，前面部署全白费。最常见的风险是源码包里的运行目录权限过宽，任何文件都能被 php-fpm 解析执行。我给一个保守的权限方案：
# 可写目录：upload、runtime、data，这些目录需要上传图片和生成缓存 chmod -R 755 /data/wwwroot/shop/upload chmod -R 755 /data/wwwroot/shop/runtime chmod -R 755 /data/wwwroot/shop/data # 源码目录：只读权限，防止被写入木马 chmod -R 644 /data/wwwroot/shop/application chmod -R 644 /data/wwwroot/shop/thinkphp # 禁止通过 Web 访问敏感目录 # 在 Nginx server 块里加一条： # location ~ ^/(application|thinkphp|vendor)/ { deny all; }逻辑说明：PHP 应用在运行时需要写缓存和日志，所以runtime目录必须可写；upload是用户上传头像和商品图的地方，必须可写。而application和thinkphp下的源码文件在运行期不会被修改，只读就够了——不给 Web 用户写权限，就能堵住“通过上传漏洞写入后门”这条常见攻击路径。
参数说明：644表示文件所有者可读写、同组用户和只读其他人只读，755多一个“其他人可进入目录”的权限。这里的核心是分区设置，不要图省事对整个站点chmod -R 777，那等于把整个商城源码的命门交给攻击者。
后台入口要改。很多商城源码的后台路径是固定的/index.php/Admin或/admin，扫描器一上来就会先探测这两个路径。改法有两种——改路由配置，或者在 Nginx 里加访问控制：
# 限制后台访问 IP，非白名单一律 403 location /admin { allow 112.65.12.34; deny all; }数据库备份不能省，因为商城数据一旦丢了，那不是重装一遍能解决的，用户订单、积分流水、商品记录全部没了。设置一个每日备份：
# 每日凌晨 2 点执行 0 2 * * * mysqldump -uroot -p你的密码 shop_mall | gzip > /backup/shop_$(date +%F).sql.gz # 保留最近 30 天备份 find /backup -name "*.sql.gz" -mtime +30 -delete定时任务做好后，配合systemctl status mysql定期检查，这套商城就具备最基本的可用性了。
5. 部署这类商城系统的 6 个常见坑：现象、原因与解法
5.1 解压后首页白屏且无任何报错
- 现象：访问首页返回空白，查看浏览器开发者工具有 500 状态码，但 Nginx 错误日志里什么都没记录。
- 原因：PHP 报错被屏蔽了。很多发货源码自带“生产环境配置”，把
display_errors关了，一旦有一个未定义函数或扩展缺失，直接白屏。第二次遇到这种问题是因为用的 PHP 8.0，而源码声明依赖PHP >= 5.6。 - 解决：先打开报错开关，把
display_errors = On临时改上，同时查看.env或config.php里的调试模式设置。确认报错内容后再针对性处理——扩展缺失就装，版本不兼容就换 PHP。
5.2 SQL 文件导入中途失败
- 现象：
mysql < shop.sql执行到一半报ERROR 2006: MySQL server has gone away，表只建了十几张，有的表里数据完整，有的表是空的。 - 原因：
max_allowed_packet默认值是 16MB，源码包里的 SQL 文件通常包含商品描述、日志等大量数据，单条 INSERT 语句可能超过这个限制。 - 解决：在
my.cnf里加大限制，重启 MySQL 后再导一次。注意先检查数据库是否已有残留表，有就执行DROP DATABASE重建干净的库，否则重复导会主键冲突。
5.3 登录验证码图片显示红叉
- 现象：验证码区域加载不出图片，控制台报
Failed to load resource，其他页面正常。 - 原因：源码用的是 GD2 库生成验证码，但服务器 PHP 环境没有安装或启用
php-gd扩展。 - 解决：安装扩展后重启 php-fpm。另外有时是验证码图片路径写了绝对地址，域名解析不到本机，检查配置里的
__SITE_URL__或模板里的静态资源路径占位符。
5.4 积分兑换提示库存不足，后台修改库存也不行
- 现象：商城兑换商品每次都提示“库存不足”，后台明明把库存改成 999 了，前台依旧报错。
- 原因：源码里的库存字段有两种——
goods_stock和points_goods.stock。积分兑换读的是后者的字段，后台商品编辑更新的是前者的字段，两者不是同一张表。 - 解决：直接改数据库的
points_goods表，或者重新编辑一次积分商品并保存。遇到这种问题，说明这套源码是“后加的积分商城”，积分商品和普通商品是隔离的，运营时要注意两套库存各管各的。
5.5 商品图片上传成功但前台不显示
- 现象：后台能上传图片，返回路径正常，前台
<img>标签地址也能访问，但页面上一片空白。 - 原因：图片路径被套了两层，比如上传保存到
/Public/upload/，但模板拼接时用了__PUBLIC__常量，解析成了/Public/，导致最终地址变成/Public/Public/upload/...，文件名对不上。 - 解决：检查入口文件里的
__PUBLIC__定义，和上传目录的实际位置是否一致。不确定就打开图片地址逐级访问，看哪一层 404，改对应配置即可。
5.6 登录状态莫名其妙丢失
- 现象：用户登录后跳转首页就掉线，用手机访问正常情况下互联网络登录失败。
- 原因：Session 配置的
cookie_domain和实际域名不匹配，或者是 PHP 默认 session 目录写权限不够。 - 解决：先把 cookie_domain 改成你的裸域名（不带 www 的 domain），再确认
/var/lib/php/sessions目录可写。如果源码配置了 Redis 做 session，确认redis扩展已加载且服务在运行。
6. 把公版商城源码变成能卖货的站点：模板改造与扩展方向
6.1 模板机制：不动核心代码，只换界面
商城源码能否改造成“能卖的网站”，关键看模板是不是独立目录。多数 PHP 商城模板放在Application/Home/View/，每个控制器对应一个子目录，文件是.html后缀。改首页最直接的方式，是找到View/Index/index.html，修改里面的 HTML 结构。
商城的模板通常会用到循环标签，这个语法和原生 PHP 略有区别：
// View/Index/index.html 里的商品列表区块 <volist name="goods_list" id="vo"> <div class="goods-item"> <a href="{:url('goods/detail', ['id'=>$vo['id']])}"> <img src="{$vo.goods_thumb}" alt="{$vo.goods_name}"> </a> <p class="price">￥{$vo.shop_price}</p> <p class="name">{$vo.goods_name}</p> </div> </volist>逻辑说明：<volist>是 ThinkPHP 模板引擎的循环标签，name是控制器传给模板的变量名，id是循环体内的当前项变量名。{:url()}是动态路由函数，它会把goods/detail?id=5之类的地址自动转成伪静态格式。改模板时要注意，如果源码用的原生 PHP 写法，那就是<?php foreach($goods_list as $vo): ?>，识别方式很简单——看模板文件的扩展名和首行标签。
参数说明：{$vo.shop_price}里的两对大括号是模板变量输出格式，中间是数组访问的简洁写法。改模板最忌讳直接改核心文件而不改模板，比如想改商品价格显示格式，应该去改模板里的输出格式。
6.2 批量导入商品：备货阶段的救命脚本
新建商城最耗时的事情是录入商品资料——几十上百个商品，一个个在后台上传太慢了。写个批量导入脚本，直接读 Excel 或 CSV 数据表，插入数据库即可：
import pymysql import csv # 连接数据库 conn = pymysql.connect(host='127.0.0.1', user='root', password='yourpass', database='shop_mall', charset='utf8mb4') cursor = conn.cursor() with open('goods.csv', 'r', encoding='utf-8-sig') as f: reader = csv.DictReader(f) for row in reader: sql = """INSERT INTO goods (goods_name, shop_price, market_price, goods_number, goods_desc) VALUES (%s, %s, %s, %s, %s)""" # 这里的价格要转成分单位的整数，很多商城字段是 DECIMAL，直接用会有精度问题 cursor.execute(sql, ( row['名称'], int(float(row['售价']) * 100), int(float(row['原价']) * 100), int(row['库存']), row['描述'] )) conn.commit()逻辑说明：Python 脚本适合做一次性数据迁移，比在 PHP 里塞一个导入接口更直接。这里关键点是“把元转成分存储”——很多商城源码的price字段用 DECIMAL(10,2)，看起来是元，单位是元——但如果你的数据源里带小数，直接写入会丢精度，先乘 100 再整数化最稳妥。
参数说明：encoding='utf-8-sig'是为了去除 Excel 导出的 CSV 里的 BOM 头，不加这个的话第一列字段名前面会多一个不可见字符，导致第一行数据插入失败。运行结束后检查插入结果，还剩多少商品没录，心中有数。
6.3 积分玩法扩展方向：签到、邀请与直播场景
公版源码的积分功能基本停留在“消费得积分、积分兑商品”这两件事上。把它变成能持续运营的体系，常见扩展方向有三个：
第一个方向是签到得积分。每次签到加 1 点，连续签到天数达到 3/7/15 天时额外赠送。实现上需要一张签到记录表或直接在points_log里加type=5的记录，每天只允许插入一条签到记录即可。
第二个方向是邀请注册。老用户邀请新用户注册并完成首单，双方各得一定积分。这个需要埋一个邀请码逻辑，最简单的方式是在用户表加一个invite_code字段，注册时读取 URL 参数拼接的邀请码，注册成功后在事务里同时给邀请人加积分。
第三个方向是直播带货场景的积分抵扣。让直播间的商品支持部分积分抵扣现金，比例后台可调。这个本质上和积分兑换不同——兑换是纯积分换商品，抵扣是“现金 + 积分”混合支付，需要改造支付下单的订单金额计算逻辑。
我的习惯是，拿到任何一套商城源码，先读支付回调和积分下单这两个核心函数，前者决定了钱的去向，后者决定了玩法的上限。源码这个方向坚持读下去，你会慢慢形成“看目录就能估量出一套系统靠不靠谱”的判断力，再遇到带积分的商城项目，心里就不慌了。希望这篇笔记能帮你在部署这套商城源码的路上少走一些弯路。
本文还有配套的精品资源，点击获取
