一套代码跑多站：Xiuno 多站点极速部署指南

52JinY 助手

最近折腾了一阵 xiuno 多站点部署，踩了不少坑，也总结出一套相对稳妥的思路。先说结论：xiuno本身轻量，做多站点的关键不是代码层面“魔改”，而是把运行环境、配置和数据边界划清楚，尽量用成熟组件来降低维护成本。

先拆解多站点的需求：通常有三种场景——同一代码、不同域名、不同数据库（彼此隔离）；同一代码、同库多前缀（轻量但风险高）；以及同一代码、同库共享用户/不同板块（定制度最高，后患也最多）。我的建议是优先选“同代码、不同库”，它在资源占用和管理复杂度之间取得了一个可控的平衡。

目录结构上，推荐用一份核心代码作为“只读”代码仓，站点级的可变内容（配置、上传、缓存、日志）独立出来。可以像这样组织：/var/www/xiuno-core 放核心；/var/www/sites/siteA 与 siteB 分别放 conf、upload、tmp、log。通过软链接或环境变量方式，让每个站点的 conf 指向自己的配置，upload 指向独立目录。这样升级只需要更新 xiuno-core，一次生效多个站点，风险也容易回滚。

Web层，Nginx 配置里用 server_name 区分域名，fastcgi_param 里注入一个 SITE_ID 或 SITE_CONF_PATH，php端在入口文件根据该变量载入对应 conf（数据库、cookie 前缀、缓存路径）。注意 fastcgi_param 的作用域要在具体 server 块里设置，避免不同站点“串味”。

数据库方面，每站点单独数据库最省心。用户会问：能不能共用用户表？可以，但要评估登录态、权限、版块隔离、积分体系的耦合成本。一旦共享用户，你几乎不可避免要改登录逻辑、cookie 域、甚至把帖子/附件权限做二次封装，这会显著增加后续维护成本。我的经验是除非强需求，否则别做共享用户；要做，也用中间层（如 OAuth/SSO）把“登录”抽象出去，保持应用内逻辑简单。

缓存与会话是另一个隐性雷点。线上建议统一接入 Redis，但要按站点设置独立前缀（如 xiuno:siteA:*）。PHP session 也指向 Redis，并配置不同的 session.name 和 cookie 前缀，避免跨域或同域多站点互相污染。如果是同一顶级域名下的子域，cookie 的 domain 范围要精准，别一股脑设置成根域。

上传与静态文件建议物理隔离。每站点独立 upload 目录或独立对象存储桶，不仅便于配额统计，也方便做 CDN 绑定和清理策略。权限方面，给 php-fpm 的运行用户最小权限即可，不要让任一站点能写到 core 目录。

部署与升级可以配合 Git 与简单的钩子实现：核心仓库更新后，触发一个脚本，依次执行 composer/install（若有）、php opcode 缓存清理、Nginx reload，并对每个站点跑一次健康检查 URL。数据库 schema 变更要走迁移脚本，逐站点执行，且先在预备环境做一次冷备和灰度。

监控与限流别忽视。多站点意味着流量叠加，最好在 Nginx 层做基础限速与IP黑名单，应用层加上慢查询日志与错误日志按站点分流，配合简单的报警（如错误率、502 比例）。定期备份时，站点级的数据库和上传分开打包，命名包含站点标识与时间戳，恢复会省很多麻烦。

最后说说取舍。多站点从简到繁都有路可走，但长期可维护性比“一步到位的完美架构”更重要。先用“同代码+独立数据库/上传+统一Redis前缀”的套路跑通，等业务确定了再考虑共享用户、统一搜索、跨站内容聚合这些高级需求，用边车或中间层去接而不是直接把 xiuno 本体改成四不像。这样，你既能享受多站点带来的扩展性，又能把升级与排障的复杂度压在可控范围内。