1. 先搞清楚同城创业系统到底在解决什么生意很多朋友看到PHPMySQL组合开发的无限多开同城创业源码系统这个标题第一反应往往是同城网站不是早就满地都是了吗但你真的在本地市场跑过几轮之后会发现这套组合的生命力比想象中强得多。它解决的不是做个网站的问题而是怎么用最轻的代价把同城本地生意的一次次复制出去的问题。下面我从业务模型开始拆再一步步落到架构、表结构、部署和那些不踩一次就记不住的坑上。1.1 同城平台的核心收入模型一个能持续运营的同城平台本质上是做本地流量聚合 服务撮合钱主要从四块来商家入驻年费这是最稳定的现金流。本地商家要曝光、要订单平台按月或按年收服务费。信息置顶与推广费招聘、房产、二手、拼团这些分类信息里置顶、加急、首页推荐都是收费项。订单抽佣与技术服务费同城外卖、预约服务、到店团购这类交易闭环平台抽取一定比例。广告位与冠名费首页轮播、商家推荐位、板块冠名本质上是在卖流量。这里面有个关键认知同城平台的商品不是标准化的实物而是本地化服务信息撮合。这就决定了它的技术栈不需要多花哨PHPMySQL这套组合完全扛得住中小体量的业务前提是业务逻辑和数据边界设计得足够清楚。1.2 多开需求是怎么冒出来的无限多开这词听起来有点野但它背后的需求非常现实。我做过的项目里多开需求基本来自三类人第一种本地创业者。先在自己的城市跑通一个站验证模式之后复制到邻市。每个城市要有独立域名、独立商家库、独立订单不能互相串数据。第二种做区域加盟或城市合伙人的操盘手。总公司提供统一技术平台每个城市合伙人拿到的是一个独立站点自己管理自己的商家和订单。第三种专门做建站交付的服务商。一个客户一套站客户之间互不可见。这套源码对他们来说就是生产工具开一个站收一份钱。这三种场景凑到一起就形成了一个硬性要求加站点不能靠改代码、改配置文件来硬编而要通过后台添加站点记录、绑定域名、刷新缓存来完成。站点的数量理论上可以无限扩展这也就是无限多开的实际含义。1.3 一套源码撑起多个城市站的业务约束无限多开四个字听上去像堆服务器就能解决实际上真正的约束都在业务层。我总结下来至少有四条域名隔离每个站通过域名访问系统必须在入口处识别当前访问的是哪个站点。数据隔离站点A的商家、商品、订单、用户绝不能出现在站点B的列表和搜索里。配置隔离轮播图、公告、客服电话、支付参数、配送规则每个城市都必须能独立配置。权限隔离后台管理员登录后只能管理自己所属站点的内容不能跨站操作。这四条有一条没做到多开就是一句空话。后面我会讲怎么用一套PHP代码和一个MySQL库优雅地把这些约束落到位而不是开一个站就部署一套完整系统。2. 多开架构不难难在隔离与复用2.1 三种常见多开姿势与取舍我在实际开发过程中见过三种多开方案各有各的适用场景先摆个表对比一下方案数据隔离强度版本升级与维护适用场景独立目录部署物理完全隔离很麻烦每个目录都要更新代码一次性交付给客户客户后续不依赖你升级独立数据库物理隔离中等代码统一但运维要维护多套库单站数据量很大或客户有硬性数据隔离要求共享库 site_id 字段逻辑隔离方便一套代码一个库加站就是插一条记录中小站点、快速复制裂变、自营矩阵我的建议很直白除非客户有明确的合规要求必须独立数据库否则起步阶段一律选共享库 site_id方案。原因有三个第一升级代码只动一次第二加站点只需要在后台添加一条域名记录第三备份和统计都方便一个库搞定所有站点。等某个站点数据量真的大到影响全库性能了再单独拆出去也不迟。2.2 域名绑定跑通站点识别共享库方案的第一道关卡就是让系统知道现在访问的是哪个站。原理其实很简单PHP入口文件读取 HTTP_HOST去站点表里查到对应记录然后把站点ID绑定到全局。// index.php 入口最前面 $host strtolower(trim($_SERVER[HTTP_HOST] ?? )); $stmt $pdo-prepare(SELECT id, city_name, status FROM sites WHERE domain ? LIMIT 1); $stmt-execute([$host]); $site $stmt-fetch(PDO::FETCH_ASSOC); if (!$site || $site[status] ! 1) { http_response_code(404); exit(该站点不存在或已关闭); } define(SITE_ID, (int) $site[id]); define(SITE_CITY, $site[city_name]);这段代码是整个多开体系的基石后续所有查询、缓存、上传路径都必须依赖 SITE_ID 这个常量。如果以后要支持泛域名比如某一城市的二级域名指向统一入口需要再处理一层通配域名匹配的逻辑但核心思想不变站点和域名是一一对应的。这里有一个容易被忽略的细节站点表里的 domain 字段必须建唯一索引而且入库前要做统一的 trim 和 strtolower。否则同一域名的大小写混着进库查不到站点就白屏了。2.3 配置文件的站点级配置策略很多二次开发的人习惯每个站点写一份 config.php比如 config_site_1.php、config_site_2.php。这套路在小规模时能用站点一多就会变成噩梦。因为你会发现同一个配置改一处要执行几十次文件同步漏一个站点线上就直接出故障。正确做法是把站点级配置搬到数据库表里入口识别出 SITE_ID 之后把该站点的所有配置项拉出来封装成全局配置数组// 这里假设 $pdo 已经初始化且 SITE_ID 已定义 $cfgStmt $pdo-prepare(SELECT config_key, config_value FROM site_configs WHERE site_id ?); $cfgStmt-execute([SITE_ID]); $siteConfig []; foreach ($cfgStmt-fetchAll(PDO::FETCH_ASSOC) as $row) { $siteConfig[$row[config_key]] $row[config_value]; } define(SITE_NAME, $siteConfig[site_name] ?? 同城生活); define(SITE_PHONE, $siteConfig[service_phone] ?? );那些全站通用的东西比如数据库连接信息、底层公共配置才适合放在固定配置文件里。站点级的东西全部走配置表这样后台只需要做一个站点设置页面就能管理任意数量站点的个性化配置。配置数据量不大但每次访问都要查一次表所以务必对这组配置做缓存后面第五章会专门讲缓存键设计。3. 数据库设计多开系统的表结构与隔离方案3.1 共享库前缀 vs 独立数据库继续深化共享库 site_id这条路。你要理解一个关键点不是所有表都需要按站点隔离。数据库表可以分为两类一类是全局共享表一类是站点隔离表。全局共享表包括sites 站点表、site_configs 站点配置表、管理员账号表如果允许一个管理员管理多站。这些表的共同特点是跨站存在或用于系统运行本身。站点隔离表包括users 用户表、merchants 商家表、products 商品表、orders 订单表、categories 分类表、banners 轮播表。只要你做的是多城市独立运营这些数据就必须按 site_id 隔离。这里有一个常见的坑有些人为了省事在用户表里不加 site_id觉得反正手机号是唯一的。结果用户在城市A注册的账号跑到城市B也能登录还能看到B站的商家和订单。如果业务设计是一账号通用所有城市那没问题但大多数同城创业项目要求的是城市独立运营用户数据必须跟着站点走。所以我建议在最开始就明确users 表也要带 site_id 字段登录时根据当前站点的 SITE_ID 去查。3.2 核心表的字段与索引设计直接给出一份能落到实际项目的核心表结构我把关键索引也一并列出来CREATE TABLE sites ( id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT, domain VARCHAR(190) NOT NULL, city_name VARCHAR(50) NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT 1启用 0关闭, remark VARCHAR(255) DEFAULT , created_at DATETIME NOT NULL, UNIQUE KEY uniq_domain (domain) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE site_configs ( id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT, site_id INT UNSIGNED NOT NULL, config_key VARCHAR(100) NOT NULL, config_value TEXT, UNIQUE KEY uniq_site_key (site_id, config_key) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE merchants ( id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT, site_id INT UNSIGNED NOT NULL, user_id INT UNSIGNED NOT NULL, shop_name VARCHAR(100) NOT NULL, category_id INT UNSIGNED NOT NULL DEFAULT 0, lng DECIMAL(10,6) NOT NULL DEFAULT 0, lat DECIMAL(10,6) NOT NULL DEFAULT 0, audit_status TINYINT NOT NULL DEFAULT 0 COMMENT 0待审 1通过 2驳回, status TINYINT NOT NULL DEFAULT 1, created_at DATETIME NOT NULL, KEY idx_site_audit (site_id, audit_status), KEY idx_site_cat (site_id, category_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE products ( id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT, site_id INT UNSIGNED NOT NULL, merchant_id INT UNSIGNED NOT NULL, title VARCHAR(150) NOT NULL, price DECIMAL(10,2) NOT NULL DEFAULT 0, stock INT UNSIGNED NOT NULL DEFAULT 0, status TINYINT NOT NULL DEFAULT 1, created_at DATETIME NOT NULL, KEY idx_site_status (site_id, status), KEY idx_site_merchant (site_id, merchant_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE orders ( id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, site_id INT UNSIGNED NOT NULL, user_id INT UNSIGNED NOT NULL, merchant_id INT UNSIGNED NOT NULL, pay_status TINYINT NOT NULL DEFAULT 0 COMMENT 0未支付 1已支付 2已退款, delivery_type TINYINT NOT NULL DEFAULT 1 COMMENT 1配送 2自提, total_amount DECIMAL(10,2) NOT NULL DEFAULT 0, created_at DATETIME NOT NULL, UNIQUE KEY uniq_order_no (order_no), KEY idx_site_created (site_id, created_at), KEY idx_site_user (site_id, user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;有几个字段设计的细节值得展开经纬度用DECIMAL(10,6)而不是FLOAT。FLOAT的精度在高纬度地区会出现几十米的偏差做配送范围判断时会出错。order_no必须带站点标识。我的习惯是日期YYYYMMDD 站点ID 6位随机数这样订单号天然能反推所属站点即使回调地址里没带站点参数也能查回来。核心查询索引全部是(site_id, 另一个常用条件)的联合索引。因为多开系统所有业务查询的第一条件是站点索引开头必须是 site_id 才能让数据库最大程度缩小扫描范围。3.3 查询代码与缓存隔离实操表设计好了代码层面要注意三条铁律所有业务查询必须显式带上 site_id 条件哪怕你心里知道这个表的数据都不跨站。缓存 key 必须带站点前缀。缓存失效时只能清当前站点的键。先看查询代码这是最常见的错误示范// 错误写法忘了带站点条件 $stmt $pdo-query(SELECT * FROM products WHERE status 1 ORDER BY id DESC LIMIT 10);这条 SQL 一旦跑起来所有站点的商品会混在一起展示线上事故分分钟出现。正确写法是这样$stmt $pdo-prepare(SELECT id, title, price FROM products WHERE site_id ? AND status 1 ORDER BY id DESC LIMIT 10); $stmt-execute([SITE_ID]); $list $stmt-fetchAll(PDO::FETCH_ASSOC);缓存方面以 Redis 为例// 缓存 key 统一加站点前缀 $cacheKey site_ . SITE_ID . :home:banner; $banners $redis-get($cacheKey); if ($banners false) { // 查库并写入缓存 $redis-setex($cacheKey, 300, json_encode($bannerList)); }很多新手做多开系统时缓存 key 写的是home:banner结果站点A更新了轮播图把站点B的缓存也清了或者站点B读到的始终是站点A的内容。所有缓存操作都带上 SITE_ID 前缀这个习惯要从第一行代码开始养成。4. 同城业务核心功能入驻、上架、下单、配送4.1 商家入驻审核链路同城平台的商家入驻不能做成简单的填个表单就能开店至少要有一条审核链路否则平台很快就会被虚假和违规商家污染。完整的链路应该是商家端提交入驻申请内容包括营业执照照片、门头照、法人身份证、主营类目、门店地址。后台生成一条待审核记录状态为audit_status0。运营人员初审查看资料完整性资料不全则驳回并注明原因。运营人员复审在后台地图上定位门店坐标录入配送范围和起送价。审核通过后系统自动创建商家记录并给申请用户发送站内信和短信通知。这里要注意权限隔离后台管理员登录时也要带着 site_id 的归属判断。我见过一个项目管理后台是全局一套任何一个管理员都能看到所有站点的商家和订单最后因为误操作把站点A的商品批量下架站B的商家也莫名其妙停了。管理权限必须做到站点可见范围。4.2 商品与分类的站点级关联商品和分类都是高度站点化的数据。分类表建议设计成站点内自建树而不是全局一个分类树。因为不同城市的消费偏好不一样站点A可能是餐饮美容为主站点B可能更偏家政维修强行走同一个分类树会让每个站点看起来都像模板站。// 获取当前站点的分类树 function getCategoryTree($pdo, $siteId) { $stmt $pdo-prepare(SELECT id, parent_id, name, sort FROM categories WHERE site_id ? ORDER BY sort DESC, id ASC); $stmt-execute([$siteId]); $rows $stmt-fetchAll(PDO::FETCH_ASSOC); // 递归组装树形结构的代码省略思路和通用树形组装没有区别 return $tree; }在商品模块里真正容易被忽略的不是增删改查而是上下架状态变更和库存扣减的并发控制。PHP 默认没有线程安全的锁同一件商品被两个用户同时下单时库存字段的更新要用原子操作// 扣库存必须用条件更新防止超卖 $sql UPDATE products SET stock stock - 1 WHERE id ? AND site_id ? AND stock 0; $stmt $pdo-prepare($sql); $stmt-execute([$productId, SITE_ID]); if ($stmt-rowCount() 0) { // 库存不足或商品不存在 }这种写法避免了先 SELECT 再 UPDATE 带来的竞态问题。4.3 订单流程与支付回调的多站点识别订单模块是整个系统里最容易出安全问题的环节因为牵扯到钱。我的建议是支付回调地址直接带站点标识比如// 支付回调路由/payment/notify/{site_id}/{order_no}这样回调程序一进来就知道是哪家站点的单。但要注意依赖 URL 上的站点参数还不够回调程序里仍然要根据 order_no 去订单表里反查一遍确认订单确实属于该站点。否则攻击者把回调地址里的 site_id 换掉就可能导致站点A的订单支付成功状态被写到站点B的订单上。完整的回调处理逻辑大概是$siteId (int) $request-param(site_id); $orderNo $request-param(order_no); // 反查订单确认订单确实属于该站点 $stmt $pdo-prepare(SELECT id, total_amount, pay_status FROM orders WHERE order_no ? AND site_id ? LIMIT 1); $stmt-execute([$orderNo, $siteId]); $order $stmt-fetch(PDO::FETCH_ASSOC); if (!$order) { // 订单不存在或站点不匹配直接记录日志并返回失败 return false; } if ($order[pay_status] 1) { // 已支付直接返回成功避免重复处理 return true; } // 校验金额与回调金额一致后更新支付状态这里有个极易踩的坑很多开发者只校验订单存在就更新状态完全没看金额是否一致。正规的支付回调会带实付金额必须在回调程序里比对金额不一致直接拒绝。吃过亏的都明白这一步不做后续对账和对骂都少不了。4.4 同城配送费与配送范围计算同城业务绕不开配送而配送绕不开两个计算范围判断和运费计算。配送范围最简单的方式是圆形半径即商家设置一个圆心和半径用户下单时计算下单地址和商家的距离超出半径就提示无法配送。球面距离公式可以直接用在代码里function distance($lat1, $lng1, $lat2, $lng2) { $rad M_PI / 180.0; $dLat ($lat2 - $lat1) * $rad; $dLng ($lng2 - $lng1) * $rad; $a sin($dLat / 2) * sin($dLat / 2) cos($lat1 * $rad) * cos($lat2 * $rad) * sin($dLng / 2) * sin($dLng / 2); return 6371 * 2 * atan2(sqrt($a), sqrt(1 - $a)); // 单位公里 }如果某些商家想画不规则的多边形配送区域那就用射线法判断点是否在多边形内原理是从用户位置点发射一条水平射线统计与多边形边的交点数奇数则在内部偶数则在外部。这个算法在 PHP 里实现起来也就十几行网上有大量现成实现关键是别用矩形近似糊弄过去否则用户在实际超出区域的地方也能下单后续纠纷全落到客服头上。配送费的计算建议做成阶梯式起步价覆盖基础公里数超出部分按每公里加价另外可以按订单金额满减配送费。这些规则都放进 site_configs 表里让每个站点独立设置。5. 部署上线前的工程细节5.1 环境要求与伪静态配置技术栈推荐 PHP 7.4 以上建议 8.0 或 8.1、MySQL 5.7 以上、Nginx、Redis 用于缓存。PHP 8 在性能和语法糖上比 7 好很多特别是对函数参数和数组操作有提升长期维护更舒服。多站点统一入口的 Nginx 配置其实只需要一个 server 块就能承接所有已绑定到这个服务器的域名server { listen 80; server_name _; root /data/wwwroot/app/public; location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { include fastcgi_params; fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } }server_name _;表示默认接管所有未单独配置的域名。PHP 入口文件通过读取HTTP_HOST来识别具体站点所以不需要为每一个站点写一份 Nginx 配置。如果你的站点量很大担心同一个 PHP-FPM 进程池扛不住可以按域名前缀拆分进程池但对中小体量来说这个单入口方案足够稳定。5.2 多站点部署与附件目录划分多开系统的附件管理是非常容易被忽略的一环。如果所有站点上传的图片都堆在同一个/uploads目录不出一个月你就会被命名冲突和权限混乱折腾疯。建议附件目录按站点分目录存放/uploads/site_1/merchant/12/xxx.jpg /uploads/site_2/merchant/35/xxx.jpg这样有几个直接好处不同站点的图片物理隔离删除站点时能直接清理对应目录。每个站点的访问权限可以单独控制避免跨站引用图片。后续要迁往对象存储时可以直接把site_1目录整体迁移到对应 bucket 前缀下面。如果从一开始就打算使用对象存储建议 key 这样设计site_{site_id}/merchant/{merchant_id}/{文件名}。有这个前缀以后按站点清理、统计、迁移都很顺手。5.3 性能优化索引、缓存、读写分离时机多开系统的性能瓶颈往往不在 PHP 代码本身而在数据库查询。首页、商家列表、商品详情这些高频读、低频写的接口优先考虑全量缓存。我的基线建议是首页数据缓存 5 分钟商家列表缓存 2 分钟商品详情缓存 5 分钟订单数据实时查库。这样即使站点数量翻倍数据库压力也不会线性上涨。在 SQL 层面强制所有查询带上site_id条件并确保索引命中这个前面已经强调过。另一个容易被忽视的点是分页查询不要用LIMIT 100000, 20数据量大时这种写法会越翻越慢。可以改成基于上次 ID 的翻页方式// 用 last_id 代替 offset $sql SELECT id, title, price FROM products WHERE site_id ? AND status 1 AND id ? ORDER BY id DESC LIMIT 20;至于读写分离和拆库我的判断标准是单库连接数持续告警、慢查询日志里开始出现 3 秒以上的订单查询、QPS 稳定超过 2000 以上才需要考虑用主从复制或独立数据库。过早引入读写分离只会让代码复杂度和事务一致性维护成本陡增。6. 我在实际交付中被反复问到的坑6.1 共享表与隔离表混用的教训早期我做过一个项目图省事把站点配置也直接写进业务表没有独立出 site_configs 表。结果每次加一个站点要拷贝一堆配置过去新站点漏了某项配置就直接白屏或者报错。后来痛定思痛把站点表、站点配置表独立出来才彻底解决了这个问题。更深的教训是users 表的共享策略必须在一开始就想清楚。如果你做的是一账号可以登录任意城市站的业务users 就不应该有 site_id但如果你做的是各城市独立用户体系users 就必须带 site_id并且唯一索引要建(site_id, mobile)而不是只建(mobile)。这两种选择没有绝对对错但千万别上线了再改用户数据的迁移会让你想哭。6.2 回调地址不带站点标识的惨案这个坑我印象太深了。某次交付一个多城市外卖平台因为支付回调地址写的是通用入口/payment/notify.php没有带 site_id上线后出现了一个诡异现象站点A的用户支付成功后站点B的订单也变成了已支付。排查到最后发现回调程序根据 order_no 去查订单表时根本没有加 site_id 条件而两个站点的订单号生成规则里随机数部分恰好碰撞了。从那以后我把订单号生成规则固定为日期站点ID随机数并且回调程序强制反查(order_no, site_id)两个条件。这两个改动彻底解决了问题。顺便提醒一句回调程序里必须做幂等处理同一笔订单的支付回调可能会被重复发送收到已支付的状态就直接返回成功不要反复写库。6.3 备份和迁移的真实现场多开系统上线一段时间后最头疼的是备份和单站迁移。共享库方案下如果你用mysqldump全库导出数据文件会随着站点数量增长变得越来越大。更好的做法是按站点导出业务表数据# 导出某个站点的商家表数据 mysqldump -u用户名 -p密码 dbname merchants --wheresite_id12 site_12_merchants.sql # 导出某个站点的订单表数据 mysqldump -u用户名 -p密码 dbname orders --wheresite_id12 site_12_orders.sql结构表则只需要导出一次恢复时先导结构再按站点批量导数据。这个方案有两个前提第一业务表必须都有 site_id 字段第二跨站关联数据要处理好比如某商家还关联着商品表、分类表都要同步导出。另外备份不是拷一份文件就完事了。我强烈建议每隔一段时间做一次恢复演练把备份文件恢复到一台临时数据库上验证关键表行数和最新订单时间。真等到服务器硬盘损坏那天才发现备份文件是坏的那种绝望不值得体验。收个尾说说我对这套系统的总体感受。PHPMySQL 的组合在很多人眼里已经不够新潮但用在同城创业这类业务上它反而显得恰到好处开发效率高、部署成本低、维护门槛低配合多开设计能让一个创业项目用最小成本快速铺开多座城市。真正决定成败的地方全藏在业务边界和数据隔离的设计里。先把域名识别、站点隔离、回调校验、备份恢复这几件事做扎实后面不管是一城一站的精细运营还是十几个站点同时滚动推广你都能稳得住。 
长河君 · 2026/10/13 5:12:08 · 阅读 1.2k PHP+MySQL多开同城系统：架构设计与数据隔离实战
1. 先搞清楚同城创业系统到底在解决什么生意很多朋友看到PHPMySQL组合开发的无限多开同城创业源码系统这个标题第一反应往往是同城网站不是早就满地都是了吗但你真的在本地市场跑过几轮之后会发现这套组合的生命力比想象中强得多。它解决的不是做个网站的问题而是怎么用最轻的代价把同城本地生意的一次次复制出去的问题。下面我从业务模型开始拆再一步步落到架构、表结构、部署和那些不踩一次就记不住的坑上。1.1 同城平台的核心收入模型一个能持续运营的同城平台本质上是做本地流量聚合 服务撮合钱主要从四块来商家入驻年费这是最稳定的现金流。本地商家要曝光、要订单平台按月或按年收服务费。信息置顶与推广费招聘、房产、二手、拼团这些分类信息里置顶、加急、首页推荐都是收费项。订单抽佣与技术服务费同城外卖、预约服务、到店团购这类交易闭环平台抽取一定比例。广告位与冠名费首页轮播、商家推荐位、板块冠名本质上是在卖流量。这里面有个关键认知同城平台的商品不是标准化的实物而是本地化服务信息撮合。这就决定了它的技术栈不需要多花哨PHPMySQL这套组合完全扛得住中小体量的业务前提是业务逻辑和数据边界设计得足够清楚。1.2 多开需求是怎么冒出来的无限多开这词听起来有点野但它背后的需求非常现实。我做过的项目里多开需求基本来自三类人第一种本地创业者。先在自己的城市跑通一个站验证模式之后复制到邻市。每个城市要有独立域名、独立商家库、独立订单不能互相串数据。第二种做区域加盟或城市合伙人的操盘手。总公司提供统一技术平台每个城市合伙人拿到的是一个独立站点自己管理自己的商家和订单。第三种专门做建站交付的服务商。一个客户一套站客户之间互不可见。这套源码对他们来说就是生产工具开一个站收一份钱。这三种场景凑到一起就形成了一个硬性要求加站点不能靠改代码、改配置文件来硬编而要通过后台添加站点记录、绑定域名、刷新缓存来完成。站点的数量理论上可以无限扩展这也就是无限多开的实际含义。1.3 一套源码撑起多个城市站的业务约束无限多开四个字听上去像堆服务器就能解决实际上真正的约束都在业务层。我总结下来至少有四条域名隔离每个站通过域名访问系统必须在入口处识别当前访问的是哪个站点。数据隔离站点A的商家、商品、订单、用户绝不能出现在站点B的列表和搜索里。配置隔离轮播图、公告、客服电话、支付参数、配送规则每个城市都必须能独立配置。权限隔离后台管理员登录后只能管理自己所属站点的内容不能跨站操作。这四条有一条没做到多开就是一句空话。后面我会讲怎么用一套PHP代码和一个MySQL库优雅地把这些约束落到位而不是开一个站就部署一套完整系统。2. 多开架构不难难在隔离与复用2.1 三种常见多开姿势与取舍我在实际开发过程中见过三种多开方案各有各的适用场景先摆个表对比一下方案数据隔离强度版本升级与维护适用场景独立目录部署物理完全隔离很麻烦每个目录都要更新代码一次性交付给客户客户后续不依赖你升级独立数据库物理隔离中等代码统一但运维要维护多套库单站数据量很大或客户有硬性数据隔离要求共享库 site_id 字段逻辑隔离方便一套代码一个库加站就是插一条记录中小站点、快速复制裂变、自营矩阵我的建议很直白除非客户有明确的合规要求必须独立数据库否则起步阶段一律选共享库 site_id方案。原因有三个第一升级代码只动一次第二加站点只需要在后台添加一条域名记录第三备份和统计都方便一个库搞定所有站点。等某个站点数据量真的大到影响全库性能了再单独拆出去也不迟。2.2 域名绑定跑通站点识别共享库方案的第一道关卡就是让系统知道现在访问的是哪个站。原理其实很简单PHP入口文件读取 HTTP_HOST去站点表里查到对应记录然后把站点ID绑定到全局。// index.php 入口最前面 $host strtolower(trim($_SERVER[HTTP_HOST] ?? )); $stmt $pdo-prepare(SELECT id, city_name, status FROM sites WHERE domain ? LIMIT 1); $stmt-execute([$host]); $site $stmt-fetch(PDO::FETCH_ASSOC); if (!$site || $site[status] ! 1) { http_response_code(404); exit(该站点不存在或已关闭); } define(SITE_ID, (int) $site[id]); define(SITE_CITY, $site[city_name]);这段代码是整个多开体系的基石后续所有查询、缓存、上传路径都必须依赖 SITE_ID 这个常量。如果以后要支持泛域名比如某一城市的二级域名指向统一入口需要再处理一层通配域名匹配的逻辑但核心思想不变站点和域名是一一对应的。这里有一个容易被忽略的细节站点表里的 domain 字段必须建唯一索引而且入库前要做统一的 trim 和 strtolower。否则同一域名的大小写混着进库查不到站点就白屏了。2.3 配置文件的站点级配置策略很多二次开发的人习惯每个站点写一份 config.php比如 config_site_1.php、config_site_2.php。这套路在小规模时能用站点一多就会变成噩梦。因为你会发现同一个配置改一处要执行几十次文件同步漏一个站点线上就直接出故障。正确做法是把站点级配置搬到数据库表里入口识别出 SITE_ID 之后把该站点的所有配置项拉出来封装成全局配置数组// 这里假设 $pdo 已经初始化且 SITE_ID 已定义 $cfgStmt $pdo-prepare(SELECT config_key, config_value FROM site_configs WHERE site_id ?); $cfgStmt-execute([SITE_ID]); $siteConfig []; foreach ($cfgStmt-fetchAll(PDO::FETCH_ASSOC) as $row) { $siteConfig[$row[config_key]] $row[config_value]; } define(SITE_NAME, $siteConfig[site_name] ?? 同城生活); define(SITE_PHONE, $siteConfig[service_phone] ?? );那些全站通用的东西比如数据库连接信息、底层公共配置才适合放在固定配置文件里。站点级的东西全部走配置表这样后台只需要做一个站点设置页面就能管理任意数量站点的个性化配置。配置数据量不大但每次访问都要查一次表所以务必对这组配置做缓存后面第五章会专门讲缓存键设计。3. 数据库设计多开系统的表结构与隔离方案3.1 共享库前缀 vs 独立数据库继续深化共享库 site_id这条路。你要理解一个关键点不是所有表都需要按站点隔离。数据库表可以分为两类一类是全局共享表一类是站点隔离表。全局共享表包括sites 站点表、site_configs 站点配置表、管理员账号表如果允许一个管理员管理多站。这些表的共同特点是跨站存在或用于系统运行本身。站点隔离表包括users 用户表、merchants 商家表、products 商品表、orders 订单表、categories 分类表、banners 轮播表。只要你做的是多城市独立运营这些数据就必须按 site_id 隔离。这里有一个常见的坑有些人为了省事在用户表里不加 site_id觉得反正手机号是唯一的。结果用户在城市A注册的账号跑到城市B也能登录还能看到B站的商家和订单。如果业务设计是一账号通用所有城市那没问题但大多数同城创业项目要求的是城市独立运营用户数据必须跟着站点走。所以我建议在最开始就明确users 表也要带 site_id 字段登录时根据当前站点的 SITE_ID 去查。3.2 核心表的字段与索引设计直接给出一份能落到实际项目的核心表结构我把关键索引也一并列出来CREATE TABLE sites ( id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT, domain VARCHAR(190) NOT NULL, city_name VARCHAR(50) NOT NULL, status TINYINT NOT NULL DEFAULT 1 COMMENT 1启用 0关闭, remark VARCHAR(255) DEFAULT , created_at DATETIME NOT NULL, UNIQUE KEY uniq_domain (domain) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE site_configs ( id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT, site_id INT UNSIGNED NOT NULL, config_key VARCHAR(100) NOT NULL, config_value TEXT, UNIQUE KEY uniq_site_key (site_id, config_key) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE merchants ( id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT, site_id INT UNSIGNED NOT NULL, user_id INT UNSIGNED NOT NULL, shop_name VARCHAR(100) NOT NULL, category_id INT UNSIGNED NOT NULL DEFAULT 0, lng DECIMAL(10,6) NOT NULL DEFAULT 0, lat DECIMAL(10,6) NOT NULL DEFAULT 0, audit_status TINYINT NOT NULL DEFAULT 0 COMMENT 0待审 1通过 2驳回, status TINYINT NOT NULL DEFAULT 1, created_at DATETIME NOT NULL, KEY idx_site_audit (site_id, audit_status), KEY idx_site_cat (site_id, category_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE products ( id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT, site_id INT UNSIGNED NOT NULL, merchant_id INT UNSIGNED NOT NULL, title VARCHAR(150) NOT NULL, price DECIMAL(10,2) NOT NULL DEFAULT 0, stock INT UNSIGNED NOT NULL DEFAULT 0, status TINYINT NOT NULL DEFAULT 1, created_at DATETIME NOT NULL, KEY idx_site_status (site_id, status), KEY idx_site_merchant (site_id, merchant_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE orders ( id INT UNSIGNED PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, site_id INT UNSIGNED NOT NULL, user_id INT UNSIGNED NOT NULL, merchant_id INT UNSIGNED NOT NULL, pay_status TINYINT NOT NULL DEFAULT 0 COMMENT 0未支付 1已支付 2已退款, delivery_type TINYINT NOT NULL DEFAULT 1 COMMENT 1配送 2自提, total_amount DECIMAL(10,2) NOT NULL DEFAULT 0, created_at DATETIME NOT NULL, UNIQUE KEY uniq_order_no (order_no), KEY idx_site_created (site_id, created_at), KEY idx_site_user (site_id, user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;有几个字段设计的细节值得展开经纬度用DECIMAL(10,6)而不是FLOAT。FLOAT的精度在高纬度地区会出现几十米的偏差做配送范围判断时会出错。order_no必须带站点标识。我的习惯是日期YYYYMMDD 站点ID 6位随机数这样订单号天然能反推所属站点即使回调地址里没带站点参数也能查回来。核心查询索引全部是(site_id, 另一个常用条件)的联合索引。因为多开系统所有业务查询的第一条件是站点索引开头必须是 site_id 才能让数据库最大程度缩小扫描范围。3.3 查询代码与缓存隔离实操表设计好了代码层面要注意三条铁律所有业务查询必须显式带上 site_id 条件哪怕你心里知道这个表的数据都不跨站。缓存 key 必须带站点前缀。缓存失效时只能清当前站点的键。先看查询代码这是最常见的错误示范// 错误写法忘了带站点条件 $stmt $pdo-query(SELECT * FROM products WHERE status 1 ORDER BY id DESC LIMIT 10);这条 SQL 一旦跑起来所有站点的商品会混在一起展示线上事故分分钟出现。正确写法是这样$stmt $pdo-prepare(SELECT id, title, price FROM products WHERE site_id ? AND status 1 ORDER BY id DESC LIMIT 10); $stmt-execute([SITE_ID]); $list $stmt-fetchAll(PDO::FETCH_ASSOC);缓存方面以 Redis 为例// 缓存 key 统一加站点前缀 $cacheKey site_ . SITE_ID . :home:banner; $banners $redis-get($cacheKey); if ($banners false) { // 查库并写入缓存 $redis-setex($cacheKey, 300, json_encode($bannerList)); }很多新手做多开系统时缓存 key 写的是home:banner结果站点A更新了轮播图把站点B的缓存也清了或者站点B读到的始终是站点A的内容。所有缓存操作都带上 SITE_ID 前缀这个习惯要从第一行代码开始养成。4. 同城业务核心功能入驻、上架、下单、配送4.1 商家入驻审核链路同城平台的商家入驻不能做成简单的填个表单就能开店至少要有一条审核链路否则平台很快就会被虚假和违规商家污染。完整的链路应该是商家端提交入驻申请内容包括营业执照照片、门头照、法人身份证、主营类目、门店地址。后台生成一条待审核记录状态为audit_status0。运营人员初审查看资料完整性资料不全则驳回并注明原因。运营人员复审在后台地图上定位门店坐标录入配送范围和起送价。审核通过后系统自动创建商家记录并给申请用户发送站内信和短信通知。这里要注意权限隔离后台管理员登录时也要带着 site_id 的归属判断。我见过一个项目管理后台是全局一套任何一个管理员都能看到所有站点的商家和订单最后因为误操作把站点A的商品批量下架站B的商家也莫名其妙停了。管理权限必须做到站点可见范围。4.2 商品与分类的站点级关联商品和分类都是高度站点化的数据。分类表建议设计成站点内自建树而不是全局一个分类树。因为不同城市的消费偏好不一样站点A可能是餐饮美容为主站点B可能更偏家政维修强行走同一个分类树会让每个站点看起来都像模板站。// 获取当前站点的分类树 function getCategoryTree($pdo, $siteId) { $stmt $pdo-prepare(SELECT id, parent_id, name, sort FROM categories WHERE site_id ? ORDER BY sort DESC, id ASC); $stmt-execute([$siteId]); $rows $stmt-fetchAll(PDO::FETCH_ASSOC); // 递归组装树形结构的代码省略思路和通用树形组装没有区别 return $tree; }在商品模块里真正容易被忽略的不是增删改查而是上下架状态变更和库存扣减的并发控制。PHP 默认没有线程安全的锁同一件商品被两个用户同时下单时库存字段的更新要用原子操作// 扣库存必须用条件更新防止超卖 $sql UPDATE products SET stock stock - 1 WHERE id ? AND site_id ? AND stock 0; $stmt $pdo-prepare($sql); $stmt-execute([$productId, SITE_ID]); if ($stmt-rowCount() 0) { // 库存不足或商品不存在 }这种写法避免了先 SELECT 再 UPDATE 带来的竞态问题。4.3 订单流程与支付回调的多站点识别订单模块是整个系统里最容易出安全问题的环节因为牵扯到钱。我的建议是支付回调地址直接带站点标识比如// 支付回调路由/payment/notify/{site_id}/{order_no}这样回调程序一进来就知道是哪家站点的单。但要注意依赖 URL 上的站点参数还不够回调程序里仍然要根据 order_no 去订单表里反查一遍确认订单确实属于该站点。否则攻击者把回调地址里的 site_id 换掉就可能导致站点A的订单支付成功状态被写到站点B的订单上。完整的回调处理逻辑大概是$siteId (int) $request-param(site_id); $orderNo $request-param(order_no); // 反查订单确认订单确实属于该站点 $stmt $pdo-prepare(SELECT id, total_amount, pay_status FROM orders WHERE order_no ? AND site_id ? LIMIT 1); $stmt-execute([$orderNo, $siteId]); $order $stmt-fetch(PDO::FETCH_ASSOC); if (!$order) { // 订单不存在或站点不匹配直接记录日志并返回失败 return false; } if ($order[pay_status] 1) { // 已支付直接返回成功避免重复处理 return true; } // 校验金额与回调金额一致后更新支付状态这里有个极易踩的坑很多开发者只校验订单存在就更新状态完全没看金额是否一致。正规的支付回调会带实付金额必须在回调程序里比对金额不一致直接拒绝。吃过亏的都明白这一步不做后续对账和对骂都少不了。4.4 同城配送费与配送范围计算同城业务绕不开配送而配送绕不开两个计算范围判断和运费计算。配送范围最简单的方式是圆形半径即商家设置一个圆心和半径用户下单时计算下单地址和商家的距离超出半径就提示无法配送。球面距离公式可以直接用在代码里function distance($lat1, $lng1, $lat2, $lng2) { $rad M_PI / 180.0; $dLat ($lat2 - $lat1) * $rad; $dLng ($lng2 - $lng1) * $rad; $a sin($dLat / 2) * sin($dLat / 2) cos($lat1 * $rad) * cos($lat2 * $rad) * sin($dLng / 2) * sin($dLng / 2); return 6371 * 2 * atan2(sqrt($a), sqrt(1 - $a)); // 单位公里 }如果某些商家想画不规则的多边形配送区域那就用射线法判断点是否在多边形内原理是从用户位置点发射一条水平射线统计与多边形边的交点数奇数则在内部偶数则在外部。这个算法在 PHP 里实现起来也就十几行网上有大量现成实现关键是别用矩形近似糊弄过去否则用户在实际超出区域的地方也能下单后续纠纷全落到客服头上。配送费的计算建议做成阶梯式起步价覆盖基础公里数超出部分按每公里加价另外可以按订单金额满减配送费。这些规则都放进 site_configs 表里让每个站点独立设置。5. 部署上线前的工程细节5.1 环境要求与伪静态配置技术栈推荐 PHP 7.4 以上建议 8.0 或 8.1、MySQL 5.7 以上、Nginx、Redis 用于缓存。PHP 8 在性能和语法糖上比 7 好很多特别是对函数参数和数组操作有提升长期维护更舒服。多站点统一入口的 Nginx 配置其实只需要一个 server 块就能承接所有已绑定到这个服务器的域名server { listen 80; server_name _; root /data/wwwroot/app/public; location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { include fastcgi_params; fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } }server_name _;表示默认接管所有未单独配置的域名。PHP 入口文件通过读取HTTP_HOST来识别具体站点所以不需要为每一个站点写一份 Nginx 配置。如果你的站点量很大担心同一个 PHP-FPM 进程池扛不住可以按域名前缀拆分进程池但对中小体量来说这个单入口方案足够稳定。5.2 多站点部署与附件目录划分多开系统的附件管理是非常容易被忽略的一环。如果所有站点上传的图片都堆在同一个/uploads目录不出一个月你就会被命名冲突和权限混乱折腾疯。建议附件目录按站点分目录存放/uploads/site_1/merchant/12/xxx.jpg /uploads/site_2/merchant/35/xxx.jpg这样有几个直接好处不同站点的图片物理隔离删除站点时能直接清理对应目录。每个站点的访问权限可以单独控制避免跨站引用图片。后续要迁往对象存储时可以直接把site_1目录整体迁移到对应 bucket 前缀下面。如果从一开始就打算使用对象存储建议 key 这样设计site_{site_id}/merchant/{merchant_id}/{文件名}。有这个前缀以后按站点清理、统计、迁移都很顺手。5.3 性能优化索引、缓存、读写分离时机多开系统的性能瓶颈往往不在 PHP 代码本身而在数据库查询。首页、商家列表、商品详情这些高频读、低频写的接口优先考虑全量缓存。我的基线建议是首页数据缓存 5 分钟商家列表缓存 2 分钟商品详情缓存 5 分钟订单数据实时查库。这样即使站点数量翻倍数据库压力也不会线性上涨。在 SQL 层面强制所有查询带上site_id条件并确保索引命中这个前面已经强调过。另一个容易被忽视的点是分页查询不要用LIMIT 100000, 20数据量大时这种写法会越翻越慢。可以改成基于上次 ID 的翻页方式// 用 last_id 代替 offset $sql SELECT id, title, price FROM products WHERE site_id ? AND status 1 AND id ? ORDER BY id DESC LIMIT 20;至于读写分离和拆库我的判断标准是单库连接数持续告警、慢查询日志里开始出现 3 秒以上的订单查询、QPS 稳定超过 2000 以上才需要考虑用主从复制或独立数据库。过早引入读写分离只会让代码复杂度和事务一致性维护成本陡增。6. 我在实际交付中被反复问到的坑6.1 共享表与隔离表混用的教训早期我做过一个项目图省事把站点配置也直接写进业务表没有独立出 site_configs 表。结果每次加一个站点要拷贝一堆配置过去新站点漏了某项配置就直接白屏或者报错。后来痛定思痛把站点表、站点配置表独立出来才彻底解决了这个问题。更深的教训是users 表的共享策略必须在一开始就想清楚。如果你做的是一账号可以登录任意城市站的业务users 就不应该有 site_id但如果你做的是各城市独立用户体系users 就必须带 site_id并且唯一索引要建(site_id, mobile)而不是只建(mobile)。这两种选择没有绝对对错但千万别上线了再改用户数据的迁移会让你想哭。6.2 回调地址不带站点标识的惨案这个坑我印象太深了。某次交付一个多城市外卖平台因为支付回调地址写的是通用入口/payment/notify.php没有带 site_id上线后出现了一个诡异现象站点A的用户支付成功后站点B的订单也变成了已支付。排查到最后发现回调程序根据 order_no 去查订单表时根本没有加 site_id 条件而两个站点的订单号生成规则里随机数部分恰好碰撞了。从那以后我把订单号生成规则固定为日期站点ID随机数并且回调程序强制反查(order_no, site_id)两个条件。这两个改动彻底解决了问题。顺便提醒一句回调程序里必须做幂等处理同一笔订单的支付回调可能会被重复发送收到已支付的状态就直接返回成功不要反复写库。6.3 备份和迁移的真实现场多开系统上线一段时间后最头疼的是备份和单站迁移。共享库方案下如果你用mysqldump全库导出数据文件会随着站点数量增长变得越来越大。更好的做法是按站点导出业务表数据# 导出某个站点的商家表数据 mysqldump -u用户名 -p密码 dbname merchants --wheresite_id12 site_12_merchants.sql # 导出某个站点的订单表数据 mysqldump -u用户名 -p密码 dbname orders --wheresite_id12 site_12_orders.sql结构表则只需要导出一次恢复时先导结构再按站点批量导数据。这个方案有两个前提第一业务表必须都有 site_id 字段第二跨站关联数据要处理好比如某商家还关联着商品表、分类表都要同步导出。另外备份不是拷一份文件就完事了。我强烈建议每隔一段时间做一次恢复演练把备份文件恢复到一台临时数据库上验证关键表行数和最新订单时间。真等到服务器硬盘损坏那天才发现备份文件是坏的那种绝望不值得体验。收个尾说说我对这套系统的总体感受。PHPMySQL 的组合在很多人眼里已经不够新潮但用在同城创业这类业务上它反而显得恰到好处开发效率高、部署成本低、维护门槛低配合多开设计能让一个创业项目用最小成本快速铺开多座城市。真正决定成败的地方全藏在业务边界和数据隔离的设计里。先把域名识别、站点隔离、回调校验、备份恢复这几件事做扎实后面不管是一城一站的精细运营还是十几个站点同时滚动推广你都能稳得住。