企业官网建设流程全解析

上星期一个朋友让我在一台服役多年的 CentOS 7.6 机器上部署 Flarum。这个论坛框架属于近几年 PHP 论坛领域人气很高的那一类：界面现代、响应快、扩展生态也完整，可问题是它需要 PHP 8.1+ 环境，而 CentOS 7.6 默认带的 PHP 还停留在 5.4。很多人一听这个版本组合第一反应就是“别折腾了”，但我实际做下来发现，整个过程比想象中顺得多，前提是每一步环境准备都要想清楚。

这篇文章就是那台机器上的完整操作记录，覆盖从替换软件源、配置 PHP 8、装 MariaDB、拉取 Flarum、跑安装器，再到上线后的排错与优化。如果你手里正好有一批 CentOS 7.x 的老机器，或者因为业务迁移成本暂时不能换系统，这份攻略会比直接照着 Flarum 官方文档硬走更省时间，很多坑我都替你踩过一遍了。

1. 部署前要想清楚的第一件事：CentOS 7.6 与 Flarum 的兼容边界

1.1 为什么还会有人在这套组合上折腾

先说场景。我那位朋友的情况很典型：公司内部已经有一批基于 CentOS 7.6 的服务器，跑着内部工具、Jenkins、数据库，整个运维流程和监控告警都围着这套系统转。想换 Ubuntu 的话，团队就得重新做安全基线、改监控脚本，很多老同事还不一定熟悉，整套迁移周期至少两周。所以他们宁可在这台能用的旧机器上“缝缝补补”，也不愿意动整个体系。

另一个常见场景是老牌社区站长。很多论坛站点从十年前就在 CentOS 上跑，数据量不小，代码也不敢乱动。Flarum 这类轻量 PHP 论坛对站长们吸引力很大，因为它把发帖、分类、回复这些核心体验做得干净利落，资金消耗又比动辄几个 GB 的“重型论坛”低得多。但老服务器上的系统不可能说换就换，这时在 CentOS 7.6 上做兼容部署，反而是最实际的方案。

我个人的态度也很明确：如果你的服务器空转、系统可以随意更换，那确实没必要守着一个接近生命周期末尾的旧系统。但如果上面已经挂着一堆业务，换系统的隐性成本比装一个新版 PHP 高得多，那么静下心来把这套组合跑通，就是最划算的选择。

1.2 先对照 Flarum 的依赖清单，别装到一半才后悔

Flarum 对 PHP 的要求不是闹着玩的。当前主线版本要求 PHP 8.1 或更高，官方列出的 PHP 扩展包括：curl、dom、fileinfo、gd、json、libxml、mbstring、openssl、pdo_mysql、zlib，另外还隐式依赖 tokenizer、ctype、filter、session 等常见扩展。大多数 Linux 发行版默认会带上后者，但 CentOS 7.6 默认环境里缺的非常多。

给你一张对比表，看得更清楚：

还有一个容易被忽视的点：Flarum 对 PHP 的 memory_limit 有要求，建议至少 128M。我实际安装时遇到过 64M 导致 Composer 和安装引导中途退出的情况。CentOS 的默认 php.ini 里 memory_limit 恰好是 128M，但如果你用第三方源升级 PHP 后没动过 ini，这个值可能会被改成更低的值，后面在配置 PHP-FPM 时需要专门确认。

1.3 官方文档的“隐藏假设”：它是按 Debian 系写的

Flarum 官方安装文档写得不错，但如果你直接照抄，一定会在某个地方卡住。官方文档默认你用的是 Ubuntu/Debian，包管理用 apt，PHP-FPM 默认用户是 www-data，php 配置文件路径也是 /etc/php/8.1/fpm/ 这种结构。到了 CentOS 7.6 上，这些全部对不上。

我踩过最尴尬的一坑是：官方文档给了 Nginx 配置，root 路径写的是 /usr/share/nginx/html/flarum/public，可 CentOS 的 nginx 包默认站点目录也是 /usr/share/nginx/html，两者极其相似。我那次把 root 指错，访问首页直接看到 404。后来我把经验总结成一条：在 CentOS 上装 Flarum，你需要的不是“看懂文档”，而是把文档里的路径、用户、服务名都翻译成 CentOS 的术语。这也是这篇攻略最主要的价值所在。

2. 基础环境搭建：先换源，再装 Nginx 和数据库

2.1 替换软件源，解决 yum 下载慢、超时的问题

CentOS 7.6 原生 yum 源默认指向 CentOS 官方海外镜像，在很多内网或国内服务器环境下要么速度很慢，要么频繁超时。我第一次部署时，光是在 yum install 阶段就等了快二十分钟，实在忍不了。后面换成阿里云镜像，整个安装过程提速明显。

操作挺简单，先备份现有源配置，再做替换：

mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak curl -o /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo yum clean all yum makecache

这里有个细节：CentOS 7 的官方源里有 “updates”、“extras” 等仓库，阿里镜像给出的文件名是 Centos-7.repo，下载后注意看下 repo 文件里的仓库标识。如果 makecache 报错，多半是仓库标识冲突，直接把 /etc/yum.repos.d 下多余的 .repo 文件移到备份目录再试即可。

替换完源之后，顺手把 EPEL 也装上。CentOS 7 里很多扩展包只能在 EPEL 里找到，不装的话后面装 PHP 相关包会非常痛苦：

yum install -y epel-release

2.2 Nginx 与数据库：版本选择直接影响后面会不会翻车

Nginx 直接用 CentOS 官方源里的版本就够跑 Flarum，不需要刻意追求最新版。假如你不需要某些特别新的特性，官方源版本反而更稳定。安装命令：

yum install -y nginx systemctl enable nginx systemctl start nginx

数据库这里我建议走 MariaDB 而非 MySQL。原因在于 CentOS 7.6 默认仓库里只有 MySQL 5.7 甚至更早的兼容包，性能上没问题，但 5.7 的密码认证插件和 Flarum 的 PDO 连接方式偶尔会闹矛盾，比如安装器里明明填对密码却提示 Access denied。MariaDB 10.5 与 MySQL 5.7 高度兼容，又在 utf8mb4 的默认支持上更省心。

安装 MariaDB 需要先添加官方仓库。创建 /etc/yum.repos.d/MariaDB.repo，写入：

[mariadb] name = MariaDB baseurl = https://mirrors.aliyun.com/mariadb/yum/10.5/centos7-amd64/ gpgkey = https://mirrors.aliyun.com/mariadb/yum/RPM-GPG-KEY-MariaDB gpgcheck = 1

然后执行：

yum install -y MariaDB-server MariaDB-client systemctl enable mariadb systemctl start mariadb

首次启动后强烈建议执行一下 mysql_secure_installation，把 root 密码和匿名账号问题处理掉。很多部署教程会跳过这步，但一旦后期排查权限问题，你根本分不清是业务账号的问题还是 root 被改了。

2.3 PHP 8.1 的安装问题：REMI 源比手动编译靠谱得多

这一步是整个 CentOS 7.6 部署里的头号难点。CentOS 7.6 的原生源最多只提供 PHP 5.4，要升级到 8.1，常见有两条路：手工编译，或者用第三方源。

手工编译 PHP 在 Flarum 项目上没有太大必要。Flarum 依赖的 PHP 扩展数量众多，编译参数一旦漏一个，装完 Flarum 后就会在运行中某一步报错，而且编译时间动不动半小时起步，还要自己处理 openssl、libxml 的系统依赖。我前后折腾过两三次之后，彻底转向 REMI 源。

REMI 是 RHEL/CentOS 生态里维护新版 PHP 的主力仓库，安装方式如下：

yum install -y epel-release yum install -y https://rpms.remirepo.net/enterprise/remi-release-7.rpm yum --enablerepo=remi-php81 install -y php php-cli php-fpm php-mysqlnd php-xml php-mbstring php-gd php-curl php-zip php-json php-opcache php-intl

注意命令里我特意写了--enablerepo=remi-php81，而不是直接 yum install。因为 REMI 仓库里同时存在多个 PHP 分支的软件包，直接安装可能装到默认的旧版本。指定仓库标识后，才能确保得到 PHP 8.1。

装完以后验证一下：

php -v php -m | grep -E 'pdo_mysql|xml|mbstring|gd|curl'

如果版本显示 8.1.x 且扩展列表里包含 pdo_mysql，这步就算过了。还有个小提醒：MySQL 的扩展名在 CentOS 系里是 php-mysqlnd，不是 Ubuntu 系里的 php-mysql，网上教程鱼龙混杂，照用前先看清楚是哪个发行版。

3. 获取 Flarum 源码：Composer 使用与源码权限

3.1 安装 Composer 2 与设置国内镜像

Flarum 的安装方式是通过 Composer 拉取项目骨架。Composer 2 在 PHP 8 环境下的兼容性已经非常成熟，安装步骤常规：

curl -sS https://getcomposer.org/installer | php mv composer.phar /usr/local/bin/composer chmod +x /usr/local/bin/composer

如果你所在服务器访问国外站点速度不理想，或者安装过程中经常超时，可以设置阿里云 Composer 镜像。这属于镜像站分流下载流量，是行业里最常见的加速手段，现在很多国内项目都在用，不涉及任何非常规配置：

composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/

设置完成后，全局目录 ~/.config/composer/config.json 里会多出一行仓库地址。以后所有 composer 依赖下载都会走镜像，速度提升非常明显。

3.2 创建项目目录并跑通 create-project

我习惯把 Flarum 站点放在 /var/www/flarum，原因是 nginx 默认可以读取 /var/www 下的内容，SELinux 文件上下文也基本不用额外处理，能少踩两个隐藏坑。

执行安装：

mkdir -p /var/www/flarum cd /var/www/flarum composer create-project flarum/flarum:*.x .

这里有一个很多人踩过的坑：命令末尾的.表示把项目装在当前目录。如果没有这个点，Composer 会默认创建一个名为 flarum 的子目录，导致站点根路径变成 /var/www/flarum/flarum，Nginx 配置也得跟着改。我第一次弄的时候忘了写点，结果站点实际代码在 /var/www/flarum/flarum/public，偏偏 Nginx 配置指到了 /var/www/flarum/public，白白排查了十分钟。

create-project 的耗时和网络速度强相关。我这边用镜像大约 3 到 5 分钟就能完成。跑完后检查目录：

ls /var/www/flarum # 应该看到 public、src、extensions、vendor、storage、config.php 等

如果看到的是残缺文件或者下载中断，别慌，直接删掉重来即可，Composer 缓存会帮助加速。

3.3 文件权限与进程用户：这里的坑最隐蔽

Flarum 需要在运行时写入 storage 目录和 public/assets 目录。Web 请求由 php-fpm 执行，用户是 php-fpm 专用用户；Nginx 的工作进程又以 nginx 用户运行。两边一旦权限不一致，就会出现“安装进去却传不了头像、发不了帖”的怪问题。

最稳妥的做法是统一属主为 nginx。我习惯这么做，因为静态文件交给 nginx 直接读，写入则由 PHP-FPM 以同一个身份完成，避免不同用户冲突：

chown -R nginx:nginx /var/www/flarum chmod -R 755 /var/www/flarum

但要注意，别图省事直接 chmod -R 777。论坛目录被写坏、日志被篡改的情况，多是权限开太大惹的祸。755 配合正确属主已经能满足绝大多数读写。

还有 SELinux。CentOS 7 默认开启 SELinux，如果你权限改完依旧写不进去，多半是 SELinux 在背后拦你。最快速的判断方式：

setenforce 0

然后刷新页面试试。如果问题消失，说明确实被 SELinux 拦截。这时别为图方便一直关着 SELinux，正确的是给 Flarum 目录设置正确的上下文：

yum install -y policycoreutils-python semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/flarum(/.*)?' restorecon -Rv /var/www/flarum

这一套做完，既保留了 SELinux 防护，又给了 Flarum 正常读写空间。我在实际项目中用这套方法解决过多台机器的上传失败问题。

4. 数据库初始化与 Nginx 伪静态规则

4.1 建库建用户：一次成功，远离安装器里的 Access denied

Flarum 安装向导会要求填写数据库连接信息，所以我们在进入 Web 安装前先建好库。

登录 MariaDB：

mysql -u root -p

然后依次执行：

CREATE DATABASE flarum CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; CREATE USER 'flarum'@'localhost' IDENTIFIED BY '这里换成强密码'; GRANT ALL PRIVILEGES ON flarum.* TO 'flarum'@'localhost'; FLUSH PRIVILEGES; EXIT;

几个细节值得重点说。

第一，字符集必须指定 utf8mb4_unicode_ci。Flarum 本身是多语言论坛，中文、Emoji 都会用到四字节字符，如果建库时用默认的 latin1，后续内容会乱码到怀疑人生。

第二，账号主机段用 localhost 还是 %。如果 Flarum 和 MariaDB 在同一台机器上，用 localhost 就够安全，也不需要开放外部访问。如果数据库是独立服务器，再改 'flarum'@'%'，同时要在防火墙里放行对应端口。

第三，MariaDB 10.5 的密码认证插件默认兼容 MySQL 原生密码，PHP 的 PDO mysqlnd 驱动连接时没有障碍。但如果你用的是网上下载的某些 MySQL 5.7+ 包，就可能遇到密码插件不兼容的问题。这也是我推荐 MariaDB 的直接原因。

4.2 Nginx 站点配置与 Flarum 伪静态规则

Flarum 的前端很依赖 URL rewrite。它默认把/当作前端入口，交给我我们部署好的 index.php 路由处理。Nginx 配置上，需要保证所有不存在的文件请求都能转到 index.php。我用的站点配置如下：

server { listen 80; server_name forum.example.com; root /var/www/flarum/public; index index.php; location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } location ~* \.(?:css|js|jpg|jpeg|png|gif|ico|svg|woff2?|ttf)$ { expires 7d; access_log off; } }

把这份配置放到 /etc/nginx/conf.d/flarum.conf 后，执行 nginx -t 测试语法，再 systemctl reload nginx。

这里最容易出错的是fastcgi_pass。我上面写的是 127.0.0.1:9000，因为 PHP-FPM 默认监听 TCP 9000。很多教程会用 Unix socket/var/run/php-fpm/php-fpm.sock，那样配置就得改成fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;。两者都能用，但必须保证 php-fpm 实际监听的地址与 nginx 写的保持一致，别一边用 socket 一边用 TCP，那样 502 跑不了。

伪静态还有一个隐藏前提：/var/www/flarum/public 这个目录必须存在，并且里面有 index.php。如果你把 root 指到 /var/www/flarum 而不是 /var/www/flarum/public，访问域名只会看到目录列表或直接 403。

4.3 访问测试：先通 HTTP 再谈 HTTPS

配置完成后，直接访问 http://服务器IP/ 或者用临时域名解析测试。如果一切正常，你会看到 Flarum 的安装引导页。看到页面后先别急着填表单，先观察两件事。

第一件事，看浏览器地址栏和 Nginx 日志里是否有异常跳转。Flarum 会把非规范域名跳转到配置里指定的 URL，如果配置和实际访问域名不一致，会出现无限重定向。安装阶段可以随便填一个域名，等装完再改 config.php 和 Nginx 的 server_name 保持一致。

第二件事，确认 PHP-FPM 是否正常执行。如果首页能打开但所有 .php 结尾的请求都空白，大概率是 fastcgi 路径配置有问题。看日志是最快的定位方式：

tail -f /var/log/nginx/error.log tail -f /var/log/php-fpm/error.log

这两个日志基本上能帮你判断 90% 的方向。

至于 HTTPS，我的建议是先用 HTTP 跑通整个部署流程，之后再用 certbot 或者已有证书把 443 接上。第一次部署就把证书、跳转、强制加密全加进去，一旦页面打不开，你会分不清是部署问题还是证书问题，排查成本翻倍。

5. Web 安装器与 config.php 的细枝末节

5.1 安装表单的填写逻辑

进入安装引导页后，会看到数据库、管理员账号、站点设置三块内容。数据库主机这一栏我建议填 localhost 而不是 127.0.0.1，因为 MariaDB 默认把 localhost 解析到 Unix socket，连接更快更稳；如果指定 127.0.0.1 走 TCP，万一防火墙没放行，也会遇到连接拒绝。

管理员账号部分，用户名以后可以在后台里改，但邮箱必须认真填，密码找回和邮件通知都要靠它。我一般先把 SMTP 邮件配置留空，用 PHP 自带的 mail 函数跑通，等论坛正式上线再填 SMTP 参数。这样能避免刚开始部署时因为邮件服务不通而卡在安装环节。

点击安装后，Flarum 会在浏览器端跑一小段安装逻辑，通常十几秒就结束。如果中途跳回“数据库连接失败”，不要急着重装，先回头检查 4.1 节的 GRANT 和密码是否真的没问题。这类错误九成是字符集或权限问题。

5.2 安装完成后的第一件事：中文语言包

Flarum 默认只有英文界面，对国内用户来说肯定要装简体中文扩展。安装方式有两种：一种是到后台扩展页面查看有没有可安装的扩展，但 Flarum 官方扩展市场加载比较慢，有时候列表显示不出来；另一种是直接用 Composer 命令行装，更可靠，也适合服务器环境：

cd /var/www/flarum composer require flarum-lang/chinese-simplified

装完以后执行：

php flarum cache:clear

然后到后台扩展页找到 Chinese Simplified，启用即可。语言包启用后，管理员界面和前台默认语言都会切到中文。

如果不希望去后台手动操作，也可以在 config.php 里直接改默认语言环境，但我在实操中还是推荐扩展方式。Flarum 的设计思路就是“语言包是一种扩展”，按官方方式管理，后续卸载或切换语言都会更干净。

5.3 config.php 里的几个关键键位

安装完成后，/var/www/flarum/config.php 会自动生成，内容结构类似这样：

<?php return [ 'debug' => false, 'database' => [ 'driver' => 'mysql', 'host' => 'localhost', 'database' => 'flarum', 'username' => 'flarum', 'password' => '强密码', 'charset' => 'utf8mb4', 'collation' => 'utf8mb4_unicode_ci', 'prefix' => '', ], 'url' => 'http://forum.example.com', 'paths' => [ 'api' => 'api', 'admin' => 'admin', ], ];

重点关注url和database。url 决定了 Flarum 内部分发链接的域名，如果你后来换域名，不仅要改 Nginx 的 server_name，还要改 config.php 里的 url，再执行一遍php flarum cache:clear。否则后台栏目里很多绝对地址不会自动更新，图片、链接都会指向旧域名。

debug在正式环境请保持 false。以前我调试时开着 true，做压力测试时直接把数据库连接路径暴露在页面上，虽然 Flarum 做了多处脱敏，但这种信息不该在公网出现。

另外你可能注意到 config.php 里没有明写“加密密钥”。Flarum 的 key 存放在 bootstrap/cache 目录，如果你迁移站点，要把整个项目目录一起带走，别只拷贝 config.php 而丢掉 cache 目录，否则 session 和用户登录状态会全部失效。

6. 上线后的排错链路、优化与备份

6.1 第一次实际使用最常见的 502 排错

论坛装完看起来能访问，但一提交表单、登录、发帖就可能弹 502 Bad Gateway。502 基本上就是 Nginx 无法从 PHP-FPM 拿到回应。排查顺序我建议固定成一条链路：

systemctl status php-fpm tail -n 50 /var/log/php-fpm/error.log

如果 php-fpm 服务还在跑，再看 Nginx 日志：

tail -n 50 /var/log/nginx/error.log

最常见的报错是connect() failed (111: Connection refused) while connecting to upstream。这说明 php-fpm 没有监听在 Nginx 配置的地址上。打开 /etc/php-fpm.d/www.conf 看 listen 指令，我前面用的是 127.0.0.1:9000，如果你打开文件看到的是 listen = /run/php-fpm/php-fpm.sock，那么 Nginx 那边也要改成对应 socket，或者把这边改回 9000。两者必须一致。

还有一类 502 和进程崩了有关。PHP-FPM 的子进程数太小，流量稍大就会挂。以 1GB 内存的 CentOS 7.6 为例，php-fpm 单进程大约占用 40 到 60MB，建议给 PHP-FPM 预留 512MB，除以单进程 60MB，大概可以开 8 个。设置成：

pm = dynamic pm.max_children = 8 pm.start_servers = 3 pm.min_spare_servers = 1 pm.max_spare_servers = 5

改完重启 php-fpm。

6.2 URL 404 与静态文件 404 的区分

论坛首页正常，但点进某些帖子或分类时 404，这基本不是 Flarum 的问题，而是 Nginx 的try_files规则没写到位。我的配置里用的是：

try_files $uri $uri/ /index.php?$query_string;

这段的意思是：先看有没有真实文件，再看有没有真实目录，都没有就交给 index.php 处理。如果你把第二项$uri/删掉，很多带斜杠的路由就会 404；如果最后一项写错成index.php（缺少前面的斜杠和 query string），也会导致发帖、登录时跳转异常。

另一类 404 是后台资源加载不出来。后台页面能打开但样式全是白的，多半是静态资源请求被 Nginx 的 location 规则挡住。Flarum 的静态资源路径带一长串哈希，如果你在 nginx.conf 里写了过于严格的正则，比如只允许固定目录，就会拦截这些请求。我的习惯是按扩展名匹配而不是按目录匹配，能有效避开这类冲突。

每次改动 Nginx 配置后，记得先执行：

nginx -t systemctl reload nginx

别直接用 restart。生产环境 restart 会闪断当前全部连接，reload 是平滑重载，对在线用户更友好。

6.3 PHP-FPM 优化、缓存与 Nginx 压缩

Flarum 这种 PHP 框架在高并发下很依赖 opcache。REMI 源里的 php-opcache 装好后默认是开启的，可以再调整一下：

opcache.enable=1 opcache.memory_consumption=128 opcache.interned_strings_buffer=8 opcache.max_accelerated_files=4000 opcache.validate_timestamps=1 opcache.revalidate_freq=60

validate_timestamps 设 1，表示修改代码后最多延迟 60 秒生效，这对调试期非常友好。正式环境你可以把 revalidate_freq 调成 0 并手动刷新缓存，但我个人觉得保持 1 更保险。论坛模板和扩展更新频繁，清缓存这步一旦忘记，改动看起来就会像“没生效”，特别容易误判成 Bug。

Nginx 压缩也能明显降低带宽消耗。在站点 server 块里加：

gzip on; gzip_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml; gzip_min_length 1024;

实测下来，Flarum 前台和后台的 CSS/JS 体积能缩减 70% 左右。压缩对 JSON 接口也有收益，写入后 reload Nginx 即可。

6.4 备份方案：老派的 tar + mysqldump 在救援时刻最有用

Flarum 的数据主要分布在数据库和 storage 目录。数据库保存帖子、用户、设置；storage 保存上传的图片、附件、日志。备份策略其实很简单：

mysqldump -u flarum -p --databases flarum > /backup/flarum_$(date +%F).sql tar czf /backup/flarum_files_$(date +%F).tar.gz /var/www/flarum

有个容易被忽略的点：/var/www/flarum 里包含了 vendor 目录（Composer 拉下来的依赖）和 bootstrap/cache。如果只备份数据库和 public 目录，迁移会变成一场灾难。所以我做备份时都是整个 Flarum 目录一起打包，恢复时解压加导库就能跑起来，不用重新 composer install。

迁移到新服务器时，除了解压、导库，还要检查 config.php 里的 url 是否要换成新域名，以及 storage 目录的属主是否还是 nginx。很多人导完数据后忘记 chown，导致新环境里图片全部打不开，实际上把属主改对就能解决。

另外我建议备份脚本里把 nginx 配置、php-fpm 的 www.conf 也顺带拷一份：

cp /etc/nginx/conf.d/flarum.conf /backup/ cp /etc/php-fpm.d/www.conf /backup/

这样重建环境时不用凭记忆重新写配置，能省至少半小时。

上面的流程全部走完，论坛已经能在 CentOS 7.6 上稳定跑了。那台机器目前还带着十几个老业务进程，Flarum 是在不动原系统组件的情况下并行装上去的，运行了一个多月，缓存和数据库都很稳定。如果你也在老系统上做类似的新旧技术栈组合，我个人最深的体会就是：别急着否定旧系统，先把它当成一台“只能装有限软件”的专用来处理，把每个组件的版本边界摸清楚，问题真的没有想象中那么多。