一套程序管多个站，和每个站各装一套有什么区别
多站点管理是一套程序集中管多个站，还是每个站独立安装一套，两种做法怎么权衡要看四件事：站点之间共享什么、一次升级要做几遍、备份能不能按站恢复、数据隔离要求有多严。这两种路径不是新旧关系，而是耦合程度的取舍。
两种路径各自共享了什么
集中式的定义很清楚。WordPress 的高级管理文档把 Multisite 描述为在一次安装中创建并管理多个站点实例，各站点共享部分资源，例如主题与插件；数据库里各站点的内容有自己的表，只有用户表在实例之间共享。共享用户表意味着账号是一套，共享主题意味着改一处影响多站。独立安装反过来：程序文件、主题、数据库表都是各一套，代价是重复。
AnQiCMS 的多站点管理走的是站内集中管理的路子：在同一后台里维护多个独立站点，适合多品牌、多主题的场景。这里的”独立站点”指站点配置与内容空间分开，而程序本体与后台是一套，所以既保留了按站管理的边界，也把升级动作收敛成一次。
升级动作的次数差别
| 维度 | 一套程序管多个站 | 每站独立装一套 |
|---|---|---|
| 核心升级次数 | 一次，覆盖全部站点 | 与站点数量成正比 |
| 模板与主题改动 | 共用的部分要评估影响面 | 各站独立改，互不影响 |
| 账号与权限 | 统一一套，跨站复用 | 每站各管一套 |
| 故障影响范围 | 程序本体出问题波及多站 | 波及单站 |
| 备份与恢复粒度 | 要额外做按站切分 | 天然按站隔离 |
| 上线核对工作量 | 核对一次，回归多站表现 | 每站各核对一遍 |
次数差别在十几二十个站时最明显：集中式一次升级完成，独立式要排多个维护窗口；而风险差别也同时放大——同一次升级失败，集中式会让所有站点一起停。
数据隔离与备份粒度
集中式最容易被忽略的是恢复粒度。AnQiCMS 的备份与恢复覆盖数据与静态文件，多站点场景下要额外确认两件事：备份包是按站导出还是整体导出，恢复时能否只回滚单个站点。如果只能整体恢复，一个站点的误操作就要拿其他站点的可用性去换。独立安装天然按站隔离，但也容易出现”版本不一致”的长期债务，几个站各自停在不同的版本上，补丁跟进要排好几条线。
地址结构对抓取的影响
集中式常配合子目录或独立域名两种地址结构。无论选哪种，重定向与站点地图都要按站分别核对：每个站点有自己的域名参数与规则配置，共用一套程序不等于共用一套抓取入口。独立安装在这一点上没有优势，同样是每站各配一遍。
常见问题
品牌差异很大的一组站，适合集中管吗？ 先看模板与内容结构能否复用。结构差异大时，集中式的共用部分会变成一堆条件分支，此时按站独立反而更清楚。
先独立装、以后合并成集中管理可行吗？ 迁移成本主要在用户与内容表的合并，以及各站历史地址的重定向承接，越晚合并越贵。
判断该走哪条路，最实际的两个问题是什么？ 一个站出问题你能接受波及几个站；以及你有没有能力把多次升级维护成同一版本。