InnoCMS + InnoShop 双产品全景：定位、共享架构、协同场景、集成方案

帆连科技的 Inno 系列目前有两个产品：InnoCMS（企业 CMS）和 InnoShop（开源电商）。市面上常见的疑问是：「我应该选哪个？两个能一起用吗？是同一套代码还是分开的？」这篇文档把两个产品的定位边界、共享架构、协同场景一次讲清楚，给正在做技术选型的团队一张全景图。

核心定位：内容 vs 交易

两个产品解决的问题完全不同，但底层技术栈高度共享：

维度	InnoCMS	InnoShop
定位	企业官网 / 内容管理	电商交易平台
核心模型	文章、分类、单页、标签	产品、订单、会员、库存
典型访客行为	浏览、阅读、咨询留资	下单、支付、复购
后台重心	内容编辑、SEO、媒体管理	订单处理、库存、营销
支付/物流	不需要	核心模块（PayPal/Stripe/支付宝/顺丰/DHL...）
开源协议	OSL 3.0	OSL 3.0

简单一句话：InnoCMS 让访客"了解你"，InnoShop 让访客"买你的东西"。两个都是 Laravel 11 + PHP 8.2 + Blade + MySQL 技术栈，二次开发心智一致。

共享的底层架构

两个产品不是简单"两套代码"，而是共享 70%+ 的底层架构：

• innopacks 模块化：common（共享模型/中间件）、panel（后台框架）、front（前台框架）、install（安装向导）、plugin（插件系统）、restapi（Panel API）—— 两个产品用同一套模块边界
• 主题规范：Blade 模板 + SCSS 设计 token + THEME=<name> npm run build 独立编译。Aurora 主题同时跑在两个产品上
• Hook 系统：Action / Filter / Blade 三种 hook 类型完全一致（参见 插件系统详解），插件可以跨产品复用
• Panel API + ipanel CLI：40+ RESTful 端点 + Python/Go 双实现 CLI（参见 ipanel CLI 详解）
• 多语言：translation 表机制 + 10 种内置语言（中、英、日、韩、德、法、西、意、葡、俄）
• 媒体管理：本地 + 阿里云 OSS / 腾讯云 COS / 七牛 / S3 / R2 六种存储后端

这意味着：你的团队学会了其中一个，上手另一个只需要 1-2 天熟悉业务模型。不需要重新学一套技术栈。

协同场景：什么时候两个一起用

场景 1：品牌官网 + 独立商城（最常见）

典型客户画像：消费品牌（服饰、美妆、3C、家居），需要一个对外品牌官网讲品牌故事 + 一个独立站卖货。

• 官网 (brand.com)：用 InnoCMS，承载品牌故事、产品发布新闻、媒体中心、关于我们、招聘
• 商城 (shop.brand.com 或 brand.com/shop)：用 InnoShop，承载产品列表、下单、会员中心
• 共享：用户系统（一套账号在两个站通用）、设计风格（共享主题规范）、SEO 策略（互相引流）

场景 2：内容驱动 + 付费内容（教育、咨询、媒体）

典型客户画像：付费课程、行业研究报告、付费订阅内容。

• InnoCMS 处理免费内容：行业资讯、博客、SEO 流量入口
• InnoShop 处理付费：课程包、报告下载、订阅会员 —— 用虚拟商品 + 下载交付模式
• 同一个用户在博客注册后，可以直接购买付费内容，无需二次登录

场景 3：B2B 企业（线下为主 + 线上询盘 + 配件商城）

典型客户画像：工业设备、机械零件、电子元器件。

• InnoCMS 做主站：产品介绍、技术文档、案例库、白皮书下载
• InnoShop 做"配件/耗材"商城：消耗品可以直接下单，主设备走询盘
• 后台统一管理，订单和咨询数据在同一面板

不要把两个硬塞到一起的场景

• 纯内容站：博客、文档站、媒体门户 —— 用 InnoCMS 就够，硬上 InnoShop 是过度工程
• 纯交易站：dropshipping、虚拟商品、订阅服务 —— 用 InnoShop 就够，不需要文章/分类
• 预算极紧：维护两个产品需要更多服务器资源、更多二次开发工作量。如果预算只够选一个，先选跟核心业务匹配的

技术集成：怎么让两个站"互通"

方案 A：共享数据库（推荐）

两个 Inno 产品装在同一个数据库，表前缀不同（cms_ vs shop_），用户表通过插件同步。登录用 SSO（OAuth2 或简单 JWT）。这是性能最好、开发成本最低的方案。

方案 B：API 互通

两个站各自独立数据库，通过 Panel API 互相同步用户、订单、内容。适合：两个站部署在不同地区、不同服务器、有合规隔离要求。

方案 C：单点部署（企业版）

购买企业版的客户，我们提供整合部署：一个 Laravel 实例同时跑 InnoCMS + InnoShop 模块，路由前缀区分（/ 走 CMS、/shop 走电商）。这种方案性能略低（每次请求加载两套模块），但运维成本最低。

数据库与共享表

如果走方案 A，跨产品共享的表：

• admins —— 后台账号（两个后台用同一套登录）
• customers / users —— 前台用户（统一会员体系）
• locales —— 语言配置
• settings —— 系统设置（部分项）
• plugins —— 插件注册（插件可以跨产品激活）

各自独立的表：InnoCMS 的 articles/catalogs/pages/tags、InnoShop 的 products/orders/invoices/...。

主题共享：Aurora 模式

Aurora 主题是双产品共同的主题基座。同一个主题包可以：

• 跑在 InnoCMS 上展示文章列表、文章详情、单页
• 跑在 InnoShop 上展示产品列表、产品详情、购物车

实现方式：主题的 views/ 目录包含两套子模板（articles/ 和 products/）， Blade 模板用主题命名空间引用。运行时根据当前产品类型加载对应模板。这是为什么 Aurora 主题是 8000+ 行而不是 3000 行 —— 覆盖两个产品的所有页面。

迁移路径：从一个扩展到两个

已经用 InnoCMS 的客户，加 InnoShop 的步骤：

1. 新装一个 InnoShop 实例（同数据库、不同表前缀）
2. 配置 SSO 让两边账号通
3. 在 InnoShop 后台创建产品目录
4. 在 InnoCMS 文章里嵌入产品卡片（用 products.shortcode Blade hook）
5. 共享主题：把 Aurora 主题同时激活到两个站

反向同理：已经有 InnoShop 的客户，加 InnoCMS 做品牌内容。两个产品的设计就是为了这种渐进式扩展。

路线图：未来会更紧密

当前两个产品是"独立但兼容"。未来 12 个月我们重点做三件事让它们更紧密：

1. innopacks 拆包：把共享的 common/panel/plugin/restapi 拆成独立 Composer 包，两个产品用 composer 引用，避免代码冗余
2. 统一账号中心：内置 SSO 模块（基于 Laravel Sanctum），开箱即用跨产品登录
3. 内容 × 电商联动：文章内嵌产品卡片、订单自动触发邮件营销、内容页根据用户浏览历史推荐产品

选择 InnoCMS 或 InnoShop 不是"二选一"的零和决策，而是"按需扩展"的渐进路径。两个产品用同一套心智模型、同一套二次开发规范，让你的团队学习成本和长期维护成本都最小化。如果你正在评估，建议从核心业务（先有 CMS 还是先有电商）切入，未来再加另一个产品是顺理成章的扩展。