WordPress搬站不停机：完整步骤与回滚

一、WordPress搬站前必须盘点的九项数据，哪些漏了会出事

换服务器本身不难，难的是漏掉某些数据导致网站上线后才发现问题。迁移前先把下面九项逐条确认，每一项都要有明确的答案，不能靠"应该还在"。

第一项是数据库。确认表前缀，WordPress 默认是 wp_，但很多站点装的时候改过。查配置文件 wp-config.php 里的 $table_prefix，这个值决定了你导出导入时该选哪张表。

第二项是上传目录。wp-content/uploads 里是所有通过媒体库上传的文件，包括图片、视频、附件。但很多站点还有直接通过 FTP 传到 wp-content 下的主题、插件、字体文件，这些不在媒体库里，必须整目录复制。

第三项是主题与子主题。整站复制时如果只复制 wp-content/uploads 而漏掉主题目录，站点会直接回退到默认主题，前端样式全变。正确做法是复制整个 wp-content 目录。

第四项是插件。插件目录在 wp-content/plugins 里，复制目录就等于复制了插件代码。但插件的配置选项存在数据库的 wp_options 表里，导数据库就等于导了配置，这两件事必须配套做。

第五项是 wp-config.php。这个文件里有数据库连接信息、盐值、以及你可能加过的自定义常量。盐值决定着登录 cookie 和密码的加密结果。如果新旧站的盐值不一致，已登录用户在跳转后会全部掉线，需要重新登录，个别站点还会出现 nonce 校验失败。

第六项是上传目录的路径。如果新服务器的域名或目录结构变了，wp-content/uploads 里的图片链接如果是绝对路径就会全部 404。

第七项是定时任务。wp-cron.php 是 WordPress 的伪定时任务，依赖每次页面访问触发。如果你从静态缓存型主机迁到 VPS，这个机制通常需要重新配置。

第八项是邮件发送配置。大量主机会装 SMTP 插件让 WordPress 用第三方邮箱发信，这部分配置在插件设置里，迁站后如果不重新配置，邮件会静默失败。

第九项是固定链接结构。/%postname%/ 和 /index.php?p=123 对应的 URL 完全不同，如果新站没设成同样的结构，所有已收录的旧链接会全部 404，SEO 流量归零。这一项是九项里对流量影响最大的一项。

# 在旧服务器上一次性导出这份清单
cd /var/www/你的站点目录
grep -E "table_prefix|WP_HOME|WP_SITEURL" wp-config.php
ls -la wp-content/
mysql -u 用户名 -p 数据库名 -e "SHOW TABLES;" | head -30

盘点完这九项之后，还要做一件容易被跳过的准备：在旧站上给整个 wp-content 目录打一个备份包。这一步花不了几分钟，但它是你最后的退路：

cd /var/www/
tar -czf 你的站点目录_备份_$(date +%Y%m%d).tar.gz 你的站点目录/
mysqldump -u 用户名 -p --single-transaction --quick --default-character-set=utf8mb4 \
  数据库名 > 数据库名_备份_$(date +%Y%m%d).sql
ls -lh 你的站点目录_备份_*.tar.gz 数据库名_备份_*.sql

查看 iwebfusion 当前月价与库存

确认备份包的大小是合理的，压缩包里文件数量跟源目录一致，SQL 文件的大小跟数据库实际占用对得上。一个 0 字节的备份文件比没有备份更危险，因为它会给你虚假的安全感。

二、数据库怎么导出：三种方式的区别和各自的坑

导出数据库有三条路，适用场景不同。

第一种最常见，用命令行导出成 SQL 文件：

mysqldump -u 用户名 -p --single-transaction --quick --default-character-set=utf8mb4 数据库名 > backup_$(date +%Y%m%d).sql

四个参数各有原因。--single-transaction 让 InnoDB 表在导出时不锁表，线上站点可以照常读写，这是必须加的。--quick 让 mysqldump 逐行读取而不是一次性把整表读进内存，几百 MB 的库加上这个参数才不会被杀掉。--default-character-set=utf8mb4 保证 emoji 和生僻字不乱码，漏掉这个参数导出的内容在导入时会报截断错误。

第二种是导入时同时改域名。旧库里的表里写死了旧域名，直接导进去会导致所有链接和 siteurl 选项还是旧地址。用 sed 全局替换最省事：

sed -i "s|旧域名|新域名|g" backup_20261104.sql

第三种是结构化迁移，适合数据库特别大、或者编码容易出问题的情况，用 mysqldump 的单表导出加表结构对照：

mysqldump -u 用户名 -p --no-data 数据库名 > schema.sql
mysqldump -u 用户名 -p 数据库名 wp_posts wp_postmeta > data.sql

导入时必须先建库并指定字符集，否则中文会变成乱码：

mysql -u root -p -e "CREATE DATABASE 新库名 DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
mysql -u 用户名 -p 新库名 < backup_20261104.sql

三个必须检查的坑。第一个坑是数据库版本的向下兼容，新服务器的 MySQL 或 MariaDB 版本如果比旧站低，某些字符集和索引类型会报错，导入前先在新服务器上建好目标库再导。第二个坑是 wp_options 表里的 active_plugins 字段，导入后插件列表会恢复，但插件目录没复制过去就会在后台报一堆"插件文件不存在"，删掉那些记录或复制插件目录即可。第三个坑是超大的 wp_postmeta 表，有些站点这块有几十万行，导入耗时很长，要预留足够的执行时间并用 screen 挂着看进度。

还有两个与数据库相关的实战细节值得单独说。其一是旧站的数据库用户权限问题。多数主机的数据库账号只对自己的库有权限，如果你在新服务器上复用了旧的用户名密码但没在新机建同名用户，导入会直接报权限错误。正确做法是在新服务器上单独建库建用户，然后把 wp-config.php 里的四项改成新的值：

mysql -u root -p -e "CREATE USER '新用户'@'localhost' IDENTIFIED BY '强密码';"
mysql -u root -p -e "GRANT ALL PRIVILEGES ON 新库名.* TO '新用户'@'localhost';"
mysql -u root -p -e "FLUSH PRIVILEGES;"

其二是导入时的性能。几百万行的库直接导入会跑很久，而且会在 wp_options 这种小表上反复等待。可以用 mysqlcheck 在导入后检查表状态，必要时对大表做一次 OPTIMIZE TABLE，把碎片整理掉：

mysqlcheck -u 用户名 -p --optimize 新库名

查 racknerd 在售套餐与库存

这一步在迁移当天做意义不大，但可以放在迁移完成一周后，作为日常维护的一部分。

三、文件怎么同步：rsync增量比scp快得多

文件同步用 rsync 而不是 scp，因为 rsync 只传差异部分。第二次同步或者补传文件时，rsync 的速度通常是 scp 的十倍以上。

第一次完整同步：

rsync -avz --progress --exclude='wp-content/cache/' --exclude='.git/' \
  用户名@旧服务器:/var/www/你的站点目录/ /var/www/你的站点目录/

--exclude 排除掉缓存目录和版本库，能省下大量无意义传输。-z 启用压缩，文本文件尤其是 PHP 文件压缩率可观。

正式切换前的增量同步才是关键一步。这一步要停写只读，或者至少在同步期间把数据库设为只读，防止同步过程中有新数据写入导致新旧不一致：

# 锁定写入，防止同步期间数据变动
mysql -u 用户名 -p -e "FLUSH TABLES WITH READ LOCK;"
# 增量同步，删掉传输中断留下的临时文件
rsync -avz --progress --delete --exclude='wp-content/cache/' \
  用户名@旧服务器:/var/www/你的站点目录/ /var/www/你的站点目录/
mysql -u 用户名 -p -e "UNLOCK TABLES;"

--delete 一定要加，它会删除目标端有、源端没有的文件，否则旧站的残留文件会留在新服务器上。但加 --delete 之前务必确认路径写对了，路径写反会删掉新站的数据。

同步完成后有一件事必须立刻做：把文件的属主改成运行 PHP 的用户。rsync 是用你登录的账号执行的，复制过来的文件属主是你，不是 www-data，这会导致插件安装、主题上传、图片上传全部报权限错误：

chown -R www-data:www-data /var/www/你的站点目录

查 cloudcone 在售套餐与库存

另外，如果站点文件里有敏感内容——付费下载的模板、会员可见的资源、配置文件——同步时应该带上排除规则，不要让它们在两台机器上都留下可读的副本。

四、DNS怎么改：TTL必须提前一天降到60秒

这是整个迁移里最容易被忽略、也最容易翻车的一步。TTL 决定了全球解析器多久更新一次你的 IP。在动 DNS 之前，必须先把 TTL 降到 60 秒并等它生效。

为什么必须提前？因为改记录前的 TTL 会被各解析器缓存住。如果你现在的 TTL 是 3600 秒，改完记录后最长要等一小时全球才全部生效；如果是 86400 秒（很多默认值就是一天），就要等 24 到 48 小时。这段时间里，一部分访客还连旧服务器，另一部分已经连新服务器，你的新站点会收到一半的流量。

操作顺序是这样的：

# 改之前先查当前 TTL
dig 你的域名 A +noall +answer
# 记下当前返回的 TTL 值

第一步，在 DNS 服务商后台把 A 记录的 TTL 改成 60 秒。第二步，等 60 秒以上，确认全球解析器已经拿到新 TTL，可以用公共 DNS 服务查询验证。第三步，导入数据库、导入文件、修改 wp-config.php 里的数据库信息。第四步，在旧服务器上把 wp-config.php 里的 WP_HOME 和 WP_SITEURL 改成新域名，这样旧服务器在被访问时会自动跳转到新站，形成一个跳转缓冲层。第五步，改 DNS 记录指向新服务器。

第四步这个技巧很多人不知道，但它是实现"不停机"的关键。旧站在切换后的一段时间内仍然会收到请求，通过修改站点常量，它会把这些请求 301 到新站，搜索引擎和访客都不会遇到硬错误。

如果你的 DNS 服务商支持按线路解析，还可以做更精细的切换：境内线路指向旧站或新站、境外线路指向另一个，等两边内容一致后再统一。这个方案适合有大量境内外访问的站点。

关于 DNS 还有两个必须提前想清楚的点。其一是主机的所有权校验。改完 DNS 后域名可能因为某些原因指向了新 IP，但你的 SSL 证书还绑在旧域名上，如果证书是按域名签发的通常没问题，如果是按 IP 签发的就必须重签。提前在证书签发机构后台把新服务器 IP 加进白名单。

其二是 CDN 的回源地址。如果你的站点接了 CDN，DNS 改的是 CDN 节点，CDN 的回源配置还指向旧服务器，那新服务器就完全收不到请求，等于白搬。检查并修改回源配置：

# 确认 CDN 回源指向的是哪台机器
dig +short 你的域名
curl -sI https://你的域名/ | grep -i "server"

digitalocean 官网机型与实时报价

正确的顺序是先改 CDN 回源到新服务器，确认新站能正常响应，再改 DNS 指向 CDN。

五、WordPress白屏：六种常见报错和对应的排查命令

迁移后打开网站白屏，是最常见的问题。WordPress 的白屏是"致命错误被静默处理"的结果，先打开错误显示才能看到真正的原因。

第一步永远是打开错误日志。在 wp-config.php 里加两行：

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

调试完成后记得改回 false，否则页面底部会暴露文件路径，是安全隐患。日志在 wp-content/debug.log。

看日志时有个技巧：不要从最后一行往上读，要从第一行开始读。PHP 在遇到第一个致命错误时就中止了，后面的内容可能都是连带的噪音。第一行通常直接写着根因，比如 Call to undefined function xxx() 或者 Class not found。

六种常见报错：

第一种，数据库连接失败。日志里出现 Error establishing a database connection 或 Access denied for user。原因通常是 wp-config.php 里的数据库名、用户名、密码、主机四项对不上。核对命令：

grep -E "DB_NAME|DB_USER|DB_PASSWORD|DB_HOST" wp-config.php
mysql -u 用户名 -p -e "SHOW DATABASES;"

第二种，PHP 版本不兼容。新服务器装的 PHP 8.x 而旧站主题或插件不支持，报错里会出现 Deprecated、Call to undefined function 或 must not return a value。查当前版本和需要的扩展：

php -v
php -m | grep -E "mysqli|gd|curl|mbstring|zip"

如果错误信息里明确指向某个插件，最快的办法是先进数据库把插件全部停用：

mysql -u 用户名 -p 数据库名 -e "UPDATE wp_options SET option_value='a:0:{}' WHERE option_name='active_plugins';"

然后进后台逐个启用，定位到出问题的那个。

第三种，内存不足。白屏日志里出现 Allowed memory size exhausted。改 PHP 内存限制：

# Ubuntu/Debian
sed -i 's/memory_limit = .*/memory_limit = 256M/' /etc/php/8.2/fpm/php.ini

第四种，文件权限不对。目录需要写权限才能装插件、更新主题。常见报错是 Permission denied 或 fopen(...): Failed to open stream：

chown -R www-data:www-data /var/www/你的站点目录
find /var/www/你的站点目录 -type d -exec chmod 755 {} \;
find /var/www/你的站点目录 -type f -exec chmod 644 {} \;

第五种，插件或主题文件缺失。打开首页白屏但打开 wp-admin 也白屏，通常是某个插件文件没复制全。应急办法是先进数据库把插件全部停用：

mysql -u 用户名 -p 数据库名 -e "UPDATE wp_options SET option_value='a:0:{}' WHERE option_name='active_plugins';"

然后进后台逐个启用，定位到出问题的那个。

第六种，缓存里的旧路径。页面实际是从缓存里出来的旧内容。清掉缓存：

rm -rf /var/www/你的站点目录/wp-content/cache/*

查 hostwinds 在售套餐与库存

排查顺序建议：先看 debug.log 的第一行报错而不是最后一行，因为第一行通常就是根因；再看 PHP 错误日志 /var/log/php8.2-fpm.log；最后才逐项排除。

六、怎么确认切换成功：八项数字验收

迁完不能凭感觉点一下首页就宣布完成。按下面八项跑一遍，每项都要有数字结果。

第一项，域名解析已生效。在多地查询解析结果，必须全部指向新 IP：

dig +short 你的域名 @8.8.8.8
dig +short 你的域名 @1.1.1.1
dig +short 你的域名 @223.5.5.5

三个不同网络的 DNS 返回都指向新服务器，才算生效。

第二项，HTTP 状态码为 200 且无跳转。用 curl 看完整响应头：

curl -sI https://你的域名/ | head -5

返回 200 且没有 Location 头指向旧域名，才说明没有产生跳转循环。

第三项，首页与后台都能打开。https://你的域名/ 和 https://你的域名/wp-admin/ 都要返回 200。后台白屏是最常见的遗漏项，很多人只测了前台。

第四项，图片和附件全部可访问。随机抽查 5 个上传目录里的图片链接：

curl -sI https://你的域名/wp-content/uploads/2026/某图片.jpg | head -1

每一条都要返回 200，出现 404 说明上传目录路径或权限有问题。

第五项，文章链接可访问。抽查一篇旧文章的固定链接，因为这个最能暴露固定链接结构或数据库替换的问题：

curl -sI https://你的域名/某旧文章链接/ | head -1

第六项，后台能登录且数据完整。在后台看文章总数、页面数、媒体库文件数，跟旧站对照，数字必须完全一致。这是最容易发现数据遗漏的方法。

第七项，前台响应时间正常。首字节小于 300 毫秒：

curl -s -o /dev/null -w 'ttfb=%{time_starttransfer} total=%{time_total}\n' https://你的域名/

新服务器第一次访问可能因为 PHP 缓存冷启动偏慢，跑两次取第二次的结果。

查看 interserver 当前月价与库存

第八项，邮件功能正常。发一封测试邮件，确认能收到。静默失败是这个环节最常见的坑——表单提交成功但邮件没到，管理员完全不知情。

七、什么情况下该回滚，回滚的触发条件是什么

回滚预案必须在迁移前写好，而不是出问题时临场决定。判断该不该回滚，用下面这几条触发条件。

触发条件一：切换后 30 分钟内，首页或后台仍持续白屏，且排查后确认是环境问题而非配置问题。触发条件二：数据库导入后文章数量明显少于旧站，说明数据不完整。触发条件三：老文章的固定链接大面积 404，说明固定链接结构或表前缀配置错了。触发条件四：站点的核心功能（下单、登录、支付回调）无法正常工作，影响收入。触发条件五：切换后搜索引擎抓取大面积报错，可能导致收录下降。

不触发回滚的情况也要说清楚：切换后前 30 分钟的短暂 502 或访问变慢属于正常现象，PHP-FPM 冷启动、OPcache 未预热都会导致这个现象，等几分钟通常自己就好了。为这几分钟回滚，代价远大于收益。

回滚的完整操作步骤：

# 第一步：把 DNS 改回旧服务器 IP，TTL 保持 60 秒
# 第二步：在旧服务器上恢复 wp-config.php 的原数据库配置
# 第三步：旧服务器数据库如果被锁定过，确认已解锁
mysql -u 用户名 -p -e "SHOW PROCESSLIST;" | grep -i "table lock"
# 第四步：确认旧站数据是切换前的状态

关键是提前把旧服务器的数据库在切换时点做一次快照或至少记下导出的 SQL 文件名。这样即使旧站在切换后被写入了新数据，回滚时也能恢复到切换前的状态。切记不要在切换后继续往旧站写数据却指望它自动同步回旧库，它不会。

查看 itldc 当前月价与库存

回滚的决策权要提前指定一个人。团队里多人在同时操作时，最糟的情况是有人正在往新站导入数据、有人同时在回滚 DNS，两个方向的操作叠加会留下更难恢复的状态。

八、迁移时常见的六个误区

第一个误区，是在新服务器上装好 WordPress 再导数据库，结果新站的初始 wp_options 里带着初始管理员账号信息，和旧库的账号混在一起。正确做法是先导旧库，再进后台改密码。

第二个误区，只复制 wp-content/uploads 目录。这是最高频的错误，插件和主题文件都丢了，站点直接白屏。正确做法是复制整个 wp-content。

第三个误区，忘了改 siteurl 和 home 两个选项。这两个值存在 wp_options 表里，用 sed 替换 SQL 文件可以一次搞定，也可以导完库后在后台改：

mysql -u 用户名 -p 数据库名 -e "UPDATE wp_options SET option_value='https://新域名' WHERE option_name IN ('siteurl','home');"

第四个误区，直接在旧服务器上删文件"逼"流量切走。正确做法是改 DNS + 在旧站配置跳转。删文件会让旧站直接报错，搜索引擎抓取到硬错误反而更糟。

第五个误区，以为迁移完流量会自动过去。DNS 生效需要时间，而且各地区各运营商的解析速度不一致，完整生效可能要几小时。这期间双站并行是正常的。

第六个误区，忽略搜索引擎的索引更新。站点换了 URL 之后要在搜索引擎资源平台提交新 sitemap，并保留旧 URL 的 301 跳转至少三个月。旧链接是外部流量进来的主要入口，直接 404 的损失往往被低估。

还有两个容易被跳过的收尾动作。一是把旧服务器上的站点改成纯跳转站之后，不要立刻销毁它，至少保留 30 天。这段时间里可能有长尾的旧链接被访问到，也可能有人从旧地址给你发邮件。30 天之后确认流量归零，再把旧机器释放。

查 spinservers 在售套餐与库存

二是给迁移这件事留一份记录。把旧服务器和新服务器的配置、数据库连接方式、文件路径、TTL 调整时间、回滚操作步骤写成一份文档存到内部知识库。下次再迁站，或者别人接手运维时，这份文档能省下大半天时间。迁移操作本质上是把知识存在自己脑子里的过程，把它写成文档是唯一能降低依赖单人的办法。

九、要不要换服务器：四个不该换和四个该换的信号

不是所有站都值得搬。判断依据只取公开事实——配置、流量、机房位置、线路类型、计费方式。

不该换的信号一：当前的机器在业务低峰期内存占用低于 15%、CPU 使用率低于 20%、磁盘使用率低于 50%，说明资源完全够用。

不该换的信号二：迁移理由只是"听说新机房更快"。机房位置决定线路质量，跨机房迁移可能让延迟变差而不是变好。先测再说：

# 从你的用户所在地测当前服务器的延迟
ping -c 20 你的域名
mtr -rwz -c 100 你的域名

不该换的信号三：新服务器的流量额度不高于旧服务器。年付 200 美元的 LAX-STARTER 折合每月 16.67 美元、4.88 TB 流量；月付 19.99 美元的 RosCloud-01 折合每月 19.99 美元、1 TB 流量。为了更便宜而迁移，往往迁移后才发现带宽更紧张。

不该换的信号四：站点是纯展示、访问量小且稳定。迁移成本通常要占掉半年以上的节省额，小站迁移的经济账算不过来。

该换的信号一：当前的磁盘使用率持续超过 80%，加上剩余空间不足 10GB，WordPress 的上传和数据库增长随时会撑爆。存储型机型的性价比在这一档最突出：sixtynet LAX-Storage-1TB 是 700 美元年付，折合每月 58.33 美元、1TB 磁盘，每 GB 盘 0.06 美元；LAX-Storage-500G 是 400 美元年付，折合每月 33.33 美元、500GB 磁盘，每 GB 盘 0.07 美元。

该换的信号二：内存不足导致频繁 OOM。PHP 应用的典型需求是每个 PHP-FPM 进程 30 到 50MB，2GB 内存的机器跑十几个进程就到顶了。云途 HK.DS.S 是 800 元每月、128GB 内存、6TB 磁盘、40TB 流量，折合每 GB 内存 6.25 元。

该换的信号三：当前线路对你的用户不友好，表现为晚高峰时段首字节从 150 毫秒涨到 500 毫秒以上。这种情况换机房比换配置有用。

zenlayer 官网机型与实时报价

该换的信号四：单点故障的代价太高。核心业务站点应该至少准备一台备用机，故障时能在 10 分钟内切过去。

按你的情况，下一步该看哪家

上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：

• 只想搭个站、预算优先：先看价格最低那档够不够用，别为用不上的配置付钱。看 iwebfusion 当前机型与价格
• 主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 racknerd 当前机型与价格
• 只是开发测试、临时用：按小时或月付，用完就删，别买年付。看 cloudcone 当前机型与价格

价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。

十、常见问题

WordPress搬家后中文全是乱码，怎么解决？ 三个地方要同时是 UTF-8：导出时加 --default-character-set=utf8mb4、建库时指定 DEFAULT CHARACTER SET utf8mb4、导入时用 mysql --default-character-set=utf8mb4。只改其中一处无效。

迁移后图片全部 404，但文章能打开？ 说明数据库里的图片路径还是旧域名，两种解法：导库前用 sed 替换 SQL 文件里的旧域名，或者导库后用 UPDATE wp_options 改 siteurl 和 home。如果图片用的是相对路径且上传目录已正确复制，那问题在 wp-content/uploads 的权限。

旧的固定链接还能用吗？ 只要在新服务器上配好 301 跳转，旧链接就能继续工作。Nginx 的写法是：

server {
    listen 80;
    server_name 旧域名;
    return 301 https://新域名$request_uri;
}

迁移需要多长时间？ 站点在 1GB 以内，数据库几百 MB，全流程通常 1 到 3 小时，其中 DNS 生效等待占大部分。数据量大的站点按每 GB 文件 5 到 10 分钟估算。

能不能不换服务器，只把数据库迁到更快的数据库服务器？ 可以，这就是常见的读写分离架构。但 WordPress 对数据库延迟敏感，一半以上的慢查询都和数据库有关，效果通常比整体迁移更明显，同时复杂度更低。

迁移后网站变慢了，是怎么回事？ 三个最常见原因：PHP OPcache 还没预热，新服务器磁盘 IO 性能不如旧机，以及数据库连接数没调。第一种等几分钟自己好，第二种跑个文件缓存预热，第三种检查 max_connections 配置。

WordPress 定时任务在新服务器上不执行了？ 因为 wp-cron.php 靠页面访问触发，访问量小就不会被触发。改用系统 cron：

*/15 * * * * /usr/bin/php /var/www/你的站点目录/wp-cron.php > /dev/null 2>&1

同时在 wp-config.php 里加 define( 'DISABLE_WP_CRON', true ); 避免重复触发。

迁移过程中网站一直能访问，为什么？ 因为你的 DNS 还没改，旧服务器还在提供服务。这也是"不停机迁移"的关键：切换动作被压缩到改 DNS 这一个瞬间，前面的准备工作都不影响线上。