简介TigShop开源商城系统是一套基于SpringBoot3与TP8后端框架结合Vue3、TypeScript、Uniapp、Vite、Nuxt3及Element Plus等前端技术的现代电商平台源码面向具备Java/Vue基础的中高级开发者可用于快速搭建企业级商城或作为微服务架构学习参考解决后台服务、跨端应用及SEO优化等综合需求。资源包共2000个文件以Vue组件634个、JavaScript脚本598个、Markdown文档405个和CSS样式303个为主另含HTML页面、JSON配置、SQL数据库脚本及docx说明文档压缩包约105.23MB涵盖前后端完整代码、样式与部署文档。目前已有252人学习下载。包内附带的文档从安装配置到开发部署均给出指导包括系统构建方法、功能模块介绍、接口说明等源码目录结构清晰便于按模块检索开发者可根据实际业务进行二次开发与定制从而节省从零搭建电商系统的时间与成本。系统整体采用前后端分离架构Uniapp可支撑跨平台小程序与AppNuxt3兼顾服务端渲染与SEO适合多端统一交付场景。1. TigShop 是什么双后端加四前端的开源商城组合看到“TigShop开源商城系统”这个标题时别把它理解成又一个单体 CRUD 项目。把 zip 解开后你会发现这套系统真正的构成是两套后端框架加四类前端工程SpringBoot3 负责管理端 API 和核心业务TP8ThinkPHP 8负责 C 端商城接口、支付回调与登录鉴权前端则是 Vue3 TypeScript Vite 的 PC 管理端、Nuxt3 的 SSR 商城页面、uniapp 的 H5/小程序/App 多端壳以及 ElementPlus 撑起来的管理界面。它解决的问题不是“怎么写商城”而是“多端商城怎么低成本起步”——你不需要从零拼装前后端分离、双后端协作和多端适配直接用这套已经跑通的组合改业务即可。适合三类人要快速交付中小型电商项目的开发者、想研究 SpringBoot3 与 TP8 协作边界的后端学习者、以及需要同时覆盖 PC 和移动端的管理者。下面按落地顺序拆开讲。2. 技术栈拆解SpringBoot3 与 TP8 各管哪一头2.1 双后端为什么同时存在管理端 Java、C 端 PHP 的职责边界先回答一个最容易被追问的问题为什么一套商城系统里要放两个后端直接用 SpringBoot3 或 TP8 一个框架做完不是更省事答案是职责边界。商城系统里有两类完全不同性质的工作一类是商品录入、订单管理、用户权限、财务报表这类内部操作特征是事务强、聚合查询多、权限模型复杂另一类是面向 C 端的商品列表、购物车、下单、支付回调特征是并发高、逻辑变化快、部署环境轻。TigShop 的做法正是按这个边界切分的——SpringBoot3 管理端 API 负责后台业务C 端 API 则交给 TP8靠近 Nginx 和 PHP-FPM 部署天然适合低配云主机上的中小项目。我一般判断一套双后端架构值不值得采用就看两个问题。第一团队的现有语言栈能不能覆盖两边如果只有 Java 背景补 TP8 的学习成本会吃掉一部分效率红利如果只有 PHP 背景管理端从 Java 重写又得不偿失。第二两个后端之间是否存在明确的接口协议而不是互相直连数据库TigShop 这种方案里管理端维护商品和订单数据TP8 通过 HTTP 接口或共享数据库读数据边界必须靠约定和文档锁死。这里给你一张边界表方便导入新同事时直接讲职责域SpringBoot3 管理端TP8 C 端商品维护创建、上下架、库存设置读取商品详情、检索订单处理审核、发货、售后状态维护创建订单、支付回调、订单查询用户管理后台管理员权限、会员列表微信/账号登录、地址管理支付退款审核、流水查询发起支付、回调验签营销优惠券发放配置优惠券核销计算选型逻辑上还要注意一个版本问题SpringBoot3 强制要求 JDK17 和 Jakarta EE 命名空间旧项目里的javax.*包名在这个版本里直接编译不过。这不是 TigShop 的 bug而是 SpringBoot3 的硬门槛后面第 3 章会专门说环境怎么配。2.2 前端四件套的分工Vue3、Nuxt3、uniapp、ElementPlus 各负责哪一端前端四个技术名词容易把人吓住实际拆开之后并不复杂。PC 管理端和 PC 商城端主体都是 Vue3 TypeScript Vite其中管理端 UI 组件用的是 ElementPlus这是国内后台管理系统最常见的组合PC 商城端因为有搜索引擎收录需求所以 TigShop 采用了 Nuxt3 来做服务端渲染SSRNuxt3 本身是基于 Vue3 Vite 生态的开发体验和普通 Vue3 项目几乎一致uniapp 则负责小程序、H5 和 App 三端复用逻辑层与视图层统一用 Vue 语法编写。具体到每个端的定位端技术用途关键注意点管理后台Vue3 TS Vite ElementPlus商品、订单、会员、营销管理纯 SPA不需要 SEOPC 商城Nuxt3 Vue3 TS面向搜索引擎的商品页、文章页SSR 页面才有 SEO 价值移动端uniapp Vue3微信小程序、支付宝小程序、H5、App一套代码多处编译后端接口SpringBoot3 / TP8业务 API两端需统一 token 鉴权这里最容易翻车的地方是“一份代码四个端”的错觉。uniapp 确实能编出四个端但每个端都有自己的配置差异小程序的 request 域名必须备案且加入白名单App 端要处理原生支付 SDKH5 端要考虑跨域。所以前端四件套的分工本质上不是技术选型问题而是“哪一端优先”的问题。我的习惯是把 management-web管理端先跑通因为商品数据录入依赖它然后再跑 uniapp 的 H5 端验证接口最后再编译到小程序因为小程序的排错链路最长。2.3 业务模块怎么切商品、订单、用户、支付、营销五个域的归属商城的业务模型看起来很散实际上逃不出五个核心域商品、订单、用户、支付、营销。TigShop 的模块设计也是围绕这五个域展开的。商品域管 SPU/SKU、分类、品牌、库存订单域管下单、状态流转、售后用户域管会员等级、地址、登录凭证支付域管支付单、回调通知、退款营销域管优惠券、秒杀、拼团。后端代码里两个框架各自实现的模块清单如下SpringBoot3 管理端系统管理管理员、角色、菜单、商品管理SPU/SKU、分类、品牌、订单管理列表、发货、售后、会员管理列表、等级、营销配置优惠券模板、活动配置。TP8 C 端用户登录微信、手机号、首页与商品检索、购物车、订单创建、支付发起、回调处理、优惠券核销。这样的切分有一个明确原则写操作要收敛到单一后端避免两端同时改同一份数据。比如库存扣减如果管理端改库存、C 端下单也改库存就会出现并发覆盖。正确的做法是 C 端下单走 TP8 的库存扣减接口管理端手动调整库存走 SpringBoot3 的接口两端操作同一张 sku_stock 表时通过 SQL 行锁保证安全具体写法在第 4 章讲。模块看完了下一章就是怎么把项目真正跑起来。3. 跑通 TigShop 的最小落地路径从解压 zip 到三端可访问3.1 环境准备JDK17、MySQL8、Redis、Node18、Composer2 的版本匹配拿到 zip 解压后先别急着导入 IDE 和npm install第一步是检查本机环境。以我踩过的坑来说九成启动失败都不是代码问题而是版本不匹配。TigShop 的后端是 SpringBoot3最低要求 JDK17TP8 是 PHP 8.x 项目要求 Composer 2.x前端 Vue3 Vite 工程建议 Node 18 及以上数据库用 MySQL 8.0.xRedis 建议 6.x 或 7.x。打开终端逐个确认java -version # 期望看到 17 或更高版本 # 如果显示 1.8.0_x说明是 JDK8SpringBoot3 无法启动 node -v # 期望 v18.0.0 或更高Vite 6 以下版本对 Node 版本较敏感 php -v # 期望 PHP 8.1 ~ 8.3 composer -V # 期望 Composer 2.x1.x 在安装 TP8 依赖时会解析失败 mysql --version # 期望 8.0.x5.7 在某些排序规则下导入 SQL 会报错配置数据库时建议新建独立的库和专用账号不要直接用 root 跑业务。SQL 脚本导入时如果报Error 1067或字符集错误通常和 MySQL 版本对utf8mb4_0900_ai_ci排序规则的支持有关解决办法在避坑章节专门讲。Redis 需要确认密码策略如果本地 Redis 没设密码后端的spring.data.redis.password和 TP8 的.env里都要留空否则会连接失败。3.2 启动后端先 SpringBoot3 管理端 API再 TP8 商城 API后端启动顺序我的建议是固定的先 MySQL、Redis再 SpringBoot3 管理端最后 TP8 C 端。原因是 TP8 的部分接口比如用户 token 校验会调用管理端的能力反过来虽然没有强依赖但日志排错时按这个顺序会清晰很多。先看 SpringBoot3 管理端。用 IDE 打开tig-admin目录常见命名找到src/main/resources/application.yml需要调整的关键配置就三处数据源、Redis、服务端口。改完之后直接跑cd tig-admin mvn spring-boot:run # 或者用 IDE 直接运行 Application 主类application.yml里的关键参数如下server: port: 8080 spring: datasource: url: jdbc:mysql://127.0.0.1:3306/tigshop?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: tigshop password: your_password data: redis: host: 127.0.0.1 port: 6379 password: your_redis_password启动成功的标志是控制台出现Started Application且没有异常堆栈。如果启动一半报UnsupportedClassVersionError确认 JDK 版本如果报连接超时优先检查 MySQL 和 Redis 是否真的启动了。接着看 TP8 商城端。tig-mall目录常见命名下先安装依赖再修改.env配置数据库和 Redis最后用内置服务器启动cd tig-mall composer install cp .env.example .env # 编辑 .env填入数据库、Redis 配置 php think run -H 0.0.0.0 -p 8000.env里最容易漏的是APP_URL和FRONTEND_URL。TP8 生成支付回调地址和跳转链接时会拼接这个值如果留成默认 localhost后面支付回调验签阶段就会出现 URL 不匹配问题。启动成功的标志是访问http://127.0.0.1:8000能看到接口响应或欢迎页在浏览器直接测一下http://127.0.0.1:8000/index.php/api/index这类入口即可。3.3 启动前端管理端、PC 商城、uniapp 三步并行准备三个前端项目我习惯分开启动因为它们端口不一样且相互之间没有顺序依赖。先看管理端目录通常是tig-ui-admin或web-admin执行cd tig-ui-admin npm install npm run dev # 默认端口 3000 或 5173看 package.json scripts 配置Vite 启动后终端会显示Local: http://localhost:3000浏览器能打开登录页就说明管理端构建没问题。这里有个经验npm install时如果报ELIFECYCLE或 node-gyp 错误优先检查 Node 版本Vite 4/5 在 Node 16 以下会安装失败。PC 商城端是 Nuxt3 工程目录常见为tig-ui-mall或web-nuxt命令几乎一样cd tig-ui-mall npm install npm run dev # Nuxt3 默认端口 3000如果和管理端冲突改 nuxt.config.ts 里的 portuniapp 的目录一般是tig-uniapp它是完整的 HBuilderX 工程可以直接导入 HBuilderX也可以用命令行方式启动到某个平台。常见做法是先用 HBuilderX 导入项目然后运行到微信开发者工具或浏览器HBuilderX - 文件 - 导入 - 从本地目录导入 选中 uniapp 端目录 运行 - 运行到浏览器 - 选择 Chrome验证 H5 端 运行 - 运行到小程序模拟器 - 微信开发者工具uniapp 第一次运行到微信开发者工具时需要在工具里配置 AppID测试号也可以否则编译成功但预览空白。3.4 联调配置改哪几个文件让三端彼此找到环境全起来后下一步是解决“谁去找谁”的问题。前端要访问后端 API这里有一个最常见的坑直接用 axios 请求http://127.0.0.1:8080浏览器会报跨域uniapp 跑 H5 也一样小程序则不跨域但要求域名白名单。给 Vite 工程配置代理是开发环境最省事的方式管理端vite.config.ts里加export default defineConfig({ server: { port: 3000, proxy: { /api: { target: http://127.0.0.1:8080, changeOrigin: true, rewrite: (path) path.replace(/^\/api/, ) } } } })TP8 C 端的请求路径如果是http://127.0.0.1:8000/api/...就要在 TP8 侧处理跨域。常见做法是写一个全局中间件给响应加上Access-Control-Allow-Origin: *同时处理 OPTIONS 预检请求。uniapp 的 H5 端可以走 Vite 代理但小程序不行——小程序里必须把请求地址指向真实域名所以.env或config.js里的BASE_URL要单独设置。联调阶段我建议你按这个顺序验证1. 浏览器打开管理端登录页能登录 SpringBoot3 管理端前端 OK 2. 访问 TP8 的首页接口/api/index能返回商品数据 TP8 uniapp H5 的数据链路 OK 3. 用 uniapp 编译到微信开发者工具能拉取商品列表 小程序端配置 OK联调完成后项目就算跑起来了但跑起来只是开始真正要改业务代码时最值得先读的是商品、订单、支付这三块核心代码下一章带着你走一遍。4. 核心业务代码走读SKU 库存、订单状态机与支付回调验签4.1 商品域SPU/SKU 表结构与库存扣减的原子写法商城最核心的模型是商品。TigShop 里的商品表按常见的 SPU/SKU 模型设计SPU 是“什么商品”比如一件 T 恤SKU 是“哪个规格”比如 T 恤-黑色-L 码。对应的表关系是spu_goods一张sku_goods按规格展开sku_stock单独存库存。为什么要单独拆一张库存表因为库存是高频并发的修改点拆出来方便锁行避免和商品基础信息的大表竞争。下单扣库存是最容易做错的地方。错误的写法是先查询库存再判断够不够再 UPDATE——这个顺序在并发下必超卖。正确写法是“条件更新”把判断条件放进 UPDATE 语句里靠数据库行锁和受影响行数保证原子性。Java 管理端里对应的 Mapper 可以这样写Mapper public interface SkuStockMapper { // 原子扣减只有扣减后不为负数时才更新成功 Update(UPDATE sku_stock SET stock stock - #{num} WHERE sku_id #{skuId} AND stock #{num}) int deductStock(Param(skuId) Long skuId, Param(num) Integer num); }这段代码的逻辑说明UPDATE ... WHERE stock #{num}的意思是“只有当前库存不小于本次购买数量时才扣减”如果条件不满足MySQL 会返回影响行数为 0代码里通过判断int result deductStock(...); if (result 0) throw new StockNotEnoughException();即可。相比先查询再计算的写法它把“检查”和“扣减”合并成一步并发下同一行数据会被行锁串行处理这是库存不超卖的关键。参数说明skuId是具体的规格 IDnum是本次扣减数量建议在调用前对num做一次 0校验防止负数导致库存反向增加。回滚补偿也很重要。如果订单支付超时关闭后需要恢复库存用同样的条件更新反向操作UPDATE sku_stock SET stock stock #{num} WHERE sku_id #{skuId}注意恢复库存不需要库存上限判断因为原本就是从这行扣出去的直接加回即可。4.2 订单域状态机流转与超时未支付订单的关闭订单状态是商城代码里最需要纪律的地方因为它是“一路流转”的数据一旦乱改对账和售后都会崩。TigShop 的订单状态流转是一个标准状态机当前状态触发动作目标状态待支付用户支付成功回调已验签已支付待支付超时未支付定时任务关闭已关闭已支付后台发货已发货已发货用户确认收货 / 超时自动确认已完成已支付用户申请售后并通过退款/已退款实现上有一个点值得注意订单状态的更新语句必须带“当前状态”条件比如关闭订单的 SQL 要写成UPDATE orders SET status 4 WHERE order_no #{orderNo} AND status 0这里的status 0是防呆条件。因为用户可能在超时前的一瞬间支付成功如果定时任务无脑把订单从待支付改成已关闭就会把一笔已支付订单关掉。SpringBoot3 里对应的定时任务可以这样写Scheduled(fixedDelay 30000) // 每 30 秒扫一次避免 60 秒多轮叠加 public void closeExpiredOrders() { // 只扫描创建时间早于当前时间 30 分钟的待支付订单分页避免扫描全表 ListOrder expiredOrders orderMapper.selectTimeoutOrders(OrderStatus.WAIT_PAY, 200); for (Order order : expiredOrders) { // 二次校验支付流水支付成功则跳过 if (payRecordMapper.existsPaid(order.getOrderNo())) { continue; } // 条件更新只有状态还是待支付时才关闭 int rows orderMapper.closeOrderIfUnpaid(order.getId(), OrderStatus.WAIT_PAY, OrderStatus.CLOSED); if (rows 0) { // 恢复库存、返还优惠券 } } }这段代码有两个关键参数fixedDelay 30000表示上一次执行结束后隔 30 秒再执行避免任务小区间内叠加selectTimeoutOrders分页取 200 条是防止一次性把大表全部捞出。另外定时任务里加一道existsPaid检查是双保险因为这个场景里状态条件已经能挡住并发但支付流水可能先落库、订单状态还没更新加一道流水检查能避免误关。TP8 侧的移动端订单查询只是读取不参与状态流转所以订单状态机整体收敛在管理端这一侧数据库表也是同一张C 端只改status字段的展示文案。4.3 支付域TP8 回调验签、金额二次校验与幂等处理支付回调是商城系统里最容易出“黑匣子”问题的地方。TP8 的 C 端负责接收支付平台的异步通知处理顺序必须是先验签再查单再幂等更新。用一个 PHP 示例说明核心逻辑?php namespace app\api\controller; use think\facade\Log; use app\common\service\PayService; class PayNotifyController { public function wechatNotify() { $raw file_get_contents(php://input); Log::info(支付回调原始报文 . $raw); // 出问题时这是唯一可靠的排查入口 $data json_decode($raw, true); // 第一步验签防止伪造通知 if (!PayService::verifySign($data)) { return FAIL; } // 第二步金额二次校验防止回调里的金额被篡改 $order (new OrderModel())-where(order_no, $data[out_trade_no])-find(); if (!$order || $order-total_fee ! $data[total_fee]) { return FAIL; } // 第三步幂等更新同一条通知重复到达时只处理一次 $updated (new OrderModel()) -where(order_no, $order-order_no) -where(status, 0) // 待支付才更新 -update([status 1, paid_at time()]); return $updated 0 ? SUCCESS : FAIL; } }这段代码的关键点有三个。第一是验签顺序“先验签再改状态”是铁律验签失败直接返回FAIL支付平台会认为没送达继续重试如果验签放在改状态之后攻击者伪造通知会直接打穿业务。第二是金额校验必须拿订单表里的total_fee和回调里的total_fee做相等比较单位统一为分别拿“元”去比较。第三是幂等更新where(status, 0)保证了同一笔订单即使回调重复到达也只有第一次会更新成功后续返回SUCCESS但实际不会改状态。日志是支付排错的唯一抓手。项目里生产环境经常出现用户说“我付了钱但订单没变已支付”如果回调日志里找不到原始报文排查就只能靠猜。我见过太多次这种情况最后定位到的原因要么是回调地址没配置成外网可访问要么是验签时拿到的证书内容里混入了 Windows 换行符。这些细节统一放在避坑章节里讲。5. TigShop 落地避坑多端配置不一致等 5 个高频问题5.1 H5 能跑小程序白屏请求地址写死导致的环境错位现象uniapp 端在浏览器里运行一切正常商品列表、登录都能用编译到微信开发者工具后页面能打开但所有请求都fail控制台报“不在以下 request 合法域名列表中”或者“网络异常”。原因代码里把请求 baseURL 写死成了http://localhost:8000或http://127.0.0.1:8000。H5 跑在浏览器里能访问本机小程序跑在开发者工具里也能碰本机但真机预览时手机访问不到开发机而且正式环境小程序的 request 域名必须是备案过的 HTTPS 域名。解决把 baseURL 拆成环境变量H5和APP-PLUS用本地地址MP-WEIXIN用正式域名同时在小程序后台的“开发设置-服务器域名”里把 request 合法域名加上。开发阶段如果非要真机调试可以用局域网 IP如http://192.168.1.100:8000并关闭小程序的域名校验但这条路只适合调试。5.2 SQL 导入报 Error 1067字符集与排序规则不匹配现象执行数据库脚本时建表中途报ERROR 1067 (42000): Invalid default value for update_time或者字符集相关的1273错误。原因脚本里部分字段的默认值、时间戳定义依赖 MySQL 8.0 的较新特性比如utf8mb4_0900_ai_ci排序规则如果本地 MySQL 是 8.0.30 以下版本且sql_mode包含NO_ZERO_DATE就会拒绝这类建表语句。解决把脚本里用到的DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_0900_ai_ci全局替换成DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_general_ci同时检查sql_mode把NO_ZERO_DATE、STRICT_TRANS_TABLES去掉后再导入。两条命令分别是# 查看当前 sql_mode SELECT sql_mode; # 临时调整重启后失效生产环境建议改 my.cnf SET GLOBAL sql_mode ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION;5.3 支付回调验签失败证书换行符与“手写验签”现象支付回调在本地测试通过部署到 Linux 服务器后验签一直失败日志里没有任何业务异常就是返回FAIL。原因有两类。第一类是证书文件里混入了 Windows 风格的\r\n换行符PHP 的openssl_verify对密钥内容里的\r非常敏感第二类是项目代码里没有用官方 SDK 的验签方法而是自己拼字符串做签名比较拼接顺序和官方规则不一致。解决在服务器上先把证书里的\r全部去掉再喂给验签函数或者干脆改用官方 SDK 的verifyNotification之类方法别手写同时确认验签用的公钥是“平台公钥”而不是“商户公钥”或“API v3 密钥”。常踩的细节是商家平台里导出的公钥末尾有换行base64_decode时也要注意原始数据去空白。5.4 TP8 接口在 Nginx 下 404伪静态规则没配现象本地php think run访问http://127.0.0.1:8000/api/index正常部署到 Nginx 后同样的路径返回 404。原因TP8 的路由依赖入口文件index.php分发Nginx 默认配置不会把/api/index重写到index.php请求落到了静态文件解析上找不到对应文件就 404。解决Nginx 的 server 块里配置 ThinkPHP 伪静态规则location / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s$1 last; } } location ~ \.php$ { include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass 127.0.0.1:9000; }配置后执行nginx -t检查语法再nginx -s reload。如果用了pathinfo模式还需要额外设置fastcgi_split_path_info和PATH_INFO变量这里不展开。判断问题时先访问http://域名/index.php/api/index能通就是重写规则的事。5.5 并发下单库存变负数扣减 SQL 少了库存条件现象压测或促销时后台商品库存出现负数订单却正常生成了。原因库存扣减 SQL 写成了UPDATE sku_stock SET stock stock - 1 WHERE sku_id ...少了AND stock 1这个条件。没有库存条件时即使库存已经是 0UPDATE 仍会把库存扣成 -1且影响行数仍然是 1程序判断“受影响行数为 1 就代表扣减成功”于是订单照常创建。解决按第 4.1 节的写法把条件更新补上同时在服务层对扣减结果做判断影响行数为 0 就抛异常并回滚整个下单事务。如果不想改 SQL也可以用乐观锁版本号方案在sku_stock表加version字段每次更新时SET stock stock - 1, version version 1 WHERE sku_id ? AND version #{version}版本不匹配就重试。两者选一即可我更推荐条件更新因为少一次查询、代码更直观。6. 进阶使用从模板商城到可复用的多端脚手架6.1 换成自己的小程序appid、域名与支付参数三处联动把 uniapp 端改成自己的商城小程序不是改一个 appid 就完事。要联动改三处第一处是manifest.json里的mp-weixin配置appid换成自己的第二处是请求工具里的BASE_URL从本地地址改成正式服务器地址且域名必须备案且加入小程序后台白名单第三处是微信支付参数——TP8 C 端.env里的mch_id、api_v3_key、cert_path都要换成你自己的商户号配置。这三处只要漏改一处就会出现“页面能看但下不了单”或“能下单但支付报错”的怪问题。我的建议是把BASE_URL和支付参数集中放到一个config.js里统一管理别散落在十几个文件里。6.2 Nuxt3 的 SEO 取舍哪些页面该 SSR哪些该 SPANuxt3 给 PC 商城带来了服务端渲染但没必要整站都 SSR。商品详情页、品牌页、文章页这类被搜索引擎收录的页面用 SSR收益最高购物车、结算、个人中心这类需要登录态的页面用 SPA 模式反而更简单减少服务端渲染的鉴权复杂度。TigShop 的 Nuxt3 工程里默认把商城首页和商品详情做成了 SSR这部分我建议保留。改配置时注意用了 SSR 的页面里不要直接操作window对象Nuxt3 服务端没有 window内存访问要放onMounted里。6.3 二次开发的边界先跑通全程再动业务最后说一点二次开发的血泪经验。拿到这套系统后最常见的错误是打开后台觉得 UI 不够好看先花两周重写样式然后发现页面布局要跟着业务调整又改组件最后才想起来要跑通下单流程结果发现支付回调的证书路径都还没配。我的习惯是任何商城项目第一步一定先把“商品录入 → 用户注册登录 → 加入购物车 → 下单 → 支付哪怕用模拟支付→ 发货 → 确认收货”这条全链路走通再回去改 UI 和业务。因为只有全链路通了你才知道哪些改动会破坏流程哪些是安全的局部修改。TigShop 这套组合给我最大的启发不是某个技术点而是“多端商城可以有这么清晰的起点”——把两后端、四前端当成自己的脚手架而不是当成必须整体照搬的模板。希望帮到你。本文还有配套的精品资源点击获取