织梦网站模板迁移到新服务器，需要检查哪些文件和配置？

把织梦（DedeCMS）网站搬到新服务器，常见的误区是只复制模板目录，或者只导入数据库。实际运行的网站通常由程序文件、模板与上传资源、数据库、服务器环境及路径配置共同组成。漏掉其中任意一项，都可能出现首页正常但栏目页报错、图片丢失、后台无法登录、静态页仍显示旧内容等问题。

本文以常见的 DedeCMS 5.x 站点为背景，说明迁移前要盘点什么、怎样备份与恢复、需要检查哪些配置，以及如何验证结果。不同版本、二次开发项目和主机面板的目录布局可能不同，文中涉及具体文件时应先在旧站核实，不要把示例路径当成所有站点的固定结构。

一、先判断迁移的范围和边界

迁移前先确认本次究竟要迁移什么。一般可分为三种情况：

• 整站迁移：迁移程序文件、模板、上传资源、数据库以及必要的运行配置。适合更换主机、云服务器或控制面板。
• 只迁移模板：只将模板文件用于另一套网站。模板可能依赖原站的栏目 ID、字段、插件、标签或自定义 PHP 代码，单独复制模板并不一定能够正常工作。
• 更换域名或目录：除迁移文件和数据库外，还要处理域名、安装子目录、静态页面地址、图片路径、缓存和搜索引擎收录问题。

如果目标是“把旧站完整搬到新服务器”，不要把模板等同于网站本身。模板通常位于 templets（常见拼写为复数）目录，但内容数据、栏目结构和文章记录保存在数据库中；图片等资源则常放在 uploads 或其他自定义目录。只复制模板不会带走文章，单独导入数据库也不会自动带走模板和图片。

还要区分“迁移”和“升级”。原样迁移的目标是尽量恢复旧站行为；升级 PHP、升级 DedeCMS、修改模板、调整 URL 规则属于额外变更。建议先在新服务器恢复一个可验证的副本，再单独安排升级。旧版 DedeCMS 存在已知安全风险，原样搬迁不等于安全加固，也不应将旧程序直接当作已受支持的软件运行。

二、迁移前盘点：先记录，而不是先复制

迁移前在旧服务器记录下列信息，并保存到站点之外的安全位置：

• DedeCMS 版本、是否经过二次开发、安装目录及网站根目录。
• 模板目录名称、当前实际使用的模板，以及是否存在自定义标签、插件或扩展文件。
• 数据库名称、表前缀、数据库字符集、数据库版本和备份文件大小。
• 站点使用的 PHP 版本、扩展、Web 服务器类型（Apache、Nginx 等）和伪静态规则。
• 主域名、是否安装在子目录、后台入口、静态页生成方式，以及图片、附件实际存放路径。
• 定时任务、邮件发送、远程接口、第三方统计、CDN、对象存储等外部依赖。

可以先查看程序中的版本信息和服务器面板配置。不同版本的版本文件、数据库连接文件和配置缓存文件可能不完全相同；不要只凭文件名判断版本。可在站点副本中搜索配置变量和数据库连接代码，确认实际生效位置。常见文件包括 data/common.inc.php，但二次开发站点可能将连接参数放在其他文件中，或由环境变量、面板配置提供。

三、必须检查的文件和目录

除了表中项目，还要检查根目录中是否有站点验证文件、robots 文件、证书验证文件、用户上传的下载包，以及项目自行加入的任务脚本。迁移策略应以“实际被访问、被引用、被定时执行的文件”为准，而不是只照搬一份通用目录清单。

四、配置文件重点：路径、域名和数据库连接

1. 数据库连接

在常见版本中，data/common.inc.php 用于保存数据库连接等配置。恢复到新服务器后，常见需要调整的值包括数据库主机、端口、数据库名、用户名、密码和表前缀。字段名称会随版本和改造而异，应该按实际文件修改，不要直接用别的站点的配置覆盖。

数据库通常应使用新建的独立账号，只授予该站点所需数据库的权限，不建议使用数据库管理员账号。配置文件含有敏感凭证，不能粘贴到公开工单、聊天记录或代码仓库。迁移完成后可检查文件读取权限；Web 进程需要读取配置，但不应让无关用户随意读取。

2. 站点域名和安装目录

如果旧站安装在网站根目录，搬迁后仍使用根目录，路径一般较简单；如果旧站位于 /cms、/news 等子目录，需同时核对程序配置、Web 根目录、伪静态规则和静态页面生成路径。只改数据库中的域名，不一定能修复所有绝对路径；只改配置文件，也不一定能替换文章正文中已经写入的旧域名。

先确定新站最终的访问地址，再统一检查站点主机名、协议（HTTP/HTTPS）、安装目录和页面 URL。若更换域名，要检查模板中的硬编码地址、数据库内容中的旧域名、图片地址、canonical 地址、站点地图和外部回调地址。不要对数据库文件做未经验证的全局字符串替换：序列化数据、转义内容和二进制字段可能因此损坏。

3. 配置缓存

有些配置由后台写入缓存文件，修改配置后可能需要按该版本的方式清理或重新生成缓存。常见缓存位于 data 或相关目录，但具体文件名并非所有版本都一致。不要把“删除整个 data 目录”当作清缓存的方法：该目录可能包含连接配置、备份、日志或其他运行所需数据。应先备份，再清除明确可重建的缓存，最后由后台或程序重新生成。

五、数据库备份和恢复

数据库备份前先确认旧站使用的库名、表前缀、字符集及数据库版本。建议在业务低峰期进行一致性备份，并保留原服务器上的原始数据库，直到新站完成验收。若网站仍在持续发布内容，初次备份后到切换前可能产生新文章或用户数据，需要安排短暂只读窗口，或在切换前再做一次增量/最终备份。单纯复制较早的备份会丢失这段时间的更新。

以下命令使用 MySQL/MariaDB 常见客户端。请将占位符替换为实际值；命令中的 -p 会提示输入密码，避免把密码直接写进命令行历史。执行用户必须有相应的数据库访问权限。大数据库可能需要额外评估备份时间、磁盘空间和导入限制。

mysqldump -h OLD_DB_HOST -u OLD_DB_USER -p \
  --default-character-set=utf8 \
  --single-transaction \
  OLD_DB_NAME > dede-site.sql

--single-transaction 对 InnoDB 表可用于取得一致性快照；它不能保证非事务型表在并发写入时也具有同样的一致性。若站点包含 MyISAM 表或备份期间仍有写入，应在维护窗口中停止写入，或采用适合当前数据库的备份方案。字符集参数也应结合旧库实际字符集确认；不要为了“兼容”随意把所有数据统一转换。

在新服务器创建空数据库和独立用户后，可按实际主机、库名导入：

mysql -h NEW_DB_HOST -u NEW_DB_USER -p \
  --default-character-set=utf8 \
  NEW_DB_NAME < dede-site.sql

新数据库字符集应与旧站数据及应用兼容。老站可能使用不同于现代项目默认设置的字符集；如果出现乱码，先检查数据库、连接、导出文件和页面响应的字符集，别立即对整库执行批量转换。导入完成后，确认表数量、文章记录、栏目记录及重要业务表存在；同时核对表前缀与程序配置是否一致。

六、复制文件：保留资源，也避免误传敏感内容

迁移整站时，建议先将旧站设置为维护状态或暂停会写入数据的功能，再复制文件。下面示例从旧服务器同步站点目录到新服务器临时目录；需将主机、用户名和路径替换为实际值，并确保网络和账号权限已配置。使用前先确认目标路径，避免把内容同步到错误目录。

rsync -a --human-readable --info=progress2 \
  /var/www/old-site/ \
  deploy@NEW_SERVER:/var/www/new-site/

命令末尾源路径中的斜杠表示同步目录内的内容。-a 会保留常见文件属性和目录结构，但具体能否保留所有所有者、权限及扩展属性，取决于执行用户、文件系统和 rsync 配置；它不等于完整服务器镜像。若需要在新服务器清除目标端多余文件，才考虑 --delete，且必须先备份并确认目标路径。误用该选项会删除目标目录中源端不存在的文件。

复制前可排除明确不需要的临时文件，但不建议第一次迁移就排除整个 data、uploads 或静态页面目录。目录名称相同不代表用途相同；应先确认其中内容，再决定是否迁移。数据库备份文件若临时放在网站可公开访问的目录中，完成传输后应立即移走，并从可公开目录删除。

七、新服务器环境：先满足旧站，再考虑升级

PHP 版本、扩展、数据库版本及 Web 服务器行为会影响旧版程序能否运行。迁移前应从旧服务器确认当前实际环境，并在新服务器检查兼容性。常见问题包括旧 PHP 语法在新版本中报错、已移除的函数、缺失扩展、错误的文件权限、短标签设置差异，以及数据库驱动或默认字符集变化。

可用以下命令查看命令行 PHP 版本和已加载扩展；但它显示的是命令行 PHP，不一定与网站实际使用的 PHP-FPM 或面板版本相同。最终应同时检查 Web 运行环境的版本信息及错误日志。

php -v
php -m

常用扩展可能包括数据库驱动、图像处理、XML 或多字节字符串支持，但准确需求取决于 DedeCMS 版本、模板和扩展功能。不要因为网上某张“必装扩展清单”就盲目安装，也不要用修改系统时区、关闭错误检查等方式掩盖程序兼容问题。出现致命错误时，先看 PHP 和 Web 服务器日志，定位具体文件、行号及缺失组件。

生产环境应关闭面向访客的错误详情输出，日志则应保存到非公开位置并限制访问。错误信息可能暴露文件路径、数据库结构或请求内容。旧版程序不适合直接公开运行；更稳妥的做法是先在隔离环境验证，评估程序和扩展风险，再安排升级或迁移到受支持的平台。若必须短期保留旧系统，应限制后台访问、及时打补丁、移除不必要脚本，并做好离线备份；这些措施不能替代升级。

八、伪静态、静态页和访问规则

织梦站点可能使用静态 HTML、伪静态或动态页面。迁移前要确认旧站实际采用哪种方式，以及栏目页、文章页和分页的 URL 格式。静态 HTML 通常是已生成的文件；伪静态则依赖 Web 服务器把特定 URL 转发到程序入口。两者处理方式不同，不能仅凭首页能打开就判断配置正确。

Apache 的 .htaccess 只在服务器启用相应模块和目录配置允许时生效。Nginx 不读取 .htaccess，需要把规则转换成 Nginx 配置，并在测试通过后重新加载服务。不要直接套用网上不明来源的规则：规则可能与站点子目录、PHP-FPM 路径、静态文件目录冲突，也可能将所有请求错误地转发到后台或首页。

如果网站主要提供静态页面，迁移后先检查旧静态文件是否完整，再决定是否重新生成。重建前记录首页、栏目页、文章页和分页的 URL 样例；生成目录与 Web 根目录必须对应。若更换域名或安装路径，应检查生成结果中的链接是否指向新地址。静态文件不能替代数据库备份，重新生成也不一定能恢复原来的 URL、发布时间或自定义内容。

九、权限与安全：迁移时最容易忽略的一层

• 让 Web 服务仅对确实需要写入的目录拥有写权限，例如上传目录或特定缓存目录。不要为了省事把整个网站设为所有用户可写。
• 检查配置文件、数据库备份和日志是否可通过浏览器访问。数据库备份、源码压缩包和配置文件都不应留在公开下载目录。
• 确认后台目录是否经过改名，以及新服务器上的访问控制是否仍有效。改名并不等于安全；还应使用强密码、限制来源或配合额外认证。
• 清除迁移过程中的临时文件、测试脚本和安装残留。若站点根目录存在安装程序或安装锁文件，应按该版本文档处理，不能为了方便重新开放安装入口。
• 检查计划任务、后台自动任务和外部接口的执行身份、绝对路径、访问凭证及运行频率，避免任务继续指向旧服务器。
• 对新站做可恢复的备份，并限制备份文件的访问权限；“已经复制到新服务器”不是备份，因为误删或入侵可能同时影响在线文件和备份。

十、迁移后的验证清单

切换 DNS 或正式开放访问前，应在新服务器上完成验证。可以通过临时 hosts 解析、内部测试域名或服务器本机测试访问新站，避免把尚未验收的站点直接暴露给所有访客。DNS 缓存有传播时间，切换后也要分别检查新旧解析结果。

1. 首页与静态资源：检查首页、CSS、JavaScript、字体和图片是否返回正常；浏览器开发者工具中查看 404、混合内容及重定向循环。
2. 栏目与内容：抽查多个栏目、文章、分页和历史图片，确认 URL、标题、正文、附件均正确。
3. 后台：确认登录、栏目管理、文章编辑、上传及生成页面可用。不要只测试首页。
4. 数据库：核对关键表及记录数，观察应用日志和数据库日志，确认没有连接失败、字符集异常或表前缀错误。
5. 写入功能：测试发布或编辑一篇临时内容、上传一个测试文件，再按计划清理测试数据。对会员、表单、邮件等功能分别验证。
6. HTTPS 与域名：检查证书、HTTP 到 HTTPS 跳转、站点主机名、canonical、站点地图及 robots 设置，避免错误地屏蔽正式站点。
7. 任务与监控：确认定时任务的脚本路径、运行账号和时区；查看错误日志与访问日志，持续观察一段时间。

确认切换成功后，再决定何时关闭旧站。不要在新站刚能打开时立刻删除旧服务器数据；建议保留旧站的只读副本和独立备份一段观察期，并明确回滚条件，例如新站持续报错、关键写入失败或数据不一致。若新站已经接收了新文章、订单或会员数据，回滚前还要考虑这些新数据如何保留，不能简单把 DNS 切回旧站就认为业务恢复。

十一、常见错误及排查方向

错误一：只搬了模板目录

表现为页面结构变化或栏目内容为空。模板只负责展示，文章、栏目、用户等数据通常在数据库中；图片与附件也可能独立存放。按整站迁移清单补齐数据和资源，或确认本次确实只是模板移植并逐项解决依赖。

错误二：程序连不上数据库

依次检查新库是否创建、账号是否被授权、数据库主机是否应使用本机地址或独立主机名、端口是否开放、连接配置是否写对、表前缀是否一致。不要把数据库管理面板密码当作程序账号密码，也不要为了排错把数据库开放给所有公网来源。

错误三：首页正常，文章页或图片 404

可能是静态文件未复制、生成目录不正确、上传资源缺失、路径大小写不同，或伪静态规则没有转换。检查具体请求的 URL、Web 根目录映射、文件实际路径和访问日志；不要先用全站重定向掩盖 404。

错误四：新站乱码

需要同时检查 SQL 文件编码、数据库表字符集、连接字符集和页面输出字符集。确认旧站原始字符集后，再针对副本进行验证。不要用编辑器打开后另存整个 SQL 文件，也不要在未备份的情况下对生产数据库执行字符集转换。

错误五：权限改成 777 后才可写

这说明目录所有者或写入范围需要修正，而不是应长期开放所有权限。确认 Web 服务运行用户，再只对必需目录授予所需权限；具体权限值取决于服务器用户模型和部署方式。

错误六：新 PHP 下出现大量报错

先定位第一个致命错误和对应版本兼容问题，再评估旧程序、模板或插件是否支持目标 PHP。不要在生产环境不断切换版本碰运气，也不要直接关闭错误提示就上线。可以在隔离副本中评估兼容性和升级方案。

错误七：后台可用，但发布后内容不更新

检查静态页生成配置、生成目录权限、缓存清理、栏目模板引用及定时任务。发布成功只代表数据写入成功，不代表对应静态页面已生成或 Web 服务正在读取正确的目录。

十二、推荐的执行顺序

1. 盘点版本、目录、数据库、模板依赖、URL 规则和外部服务，制定回滚方案。
2. 备份文件与数据库，并验证备份文件可读；有条件时先在测试环境恢复一次。
3. 建立新服务器站点、数据库与受限账号，匹配或明确评估 PHP、数据库和 Web 环境。
4. 复制程序、模板、上传资源、必要的静态文件和自定义代码。
5. 导入数据库，修改实际生效的数据库连接和站点路径配置。
6. 配置 Web 根目录、HTTPS、伪静态或静态页服务，处理缓存并检查权限。
7. 在不对外切换的情况下验证前后台、文章、图片、写入功能、日志和定时任务。
8. 完成最终数据同步后切换域名解析，观察新站并保留旧站副本，确认无误后再清理临时文件。

织梦网站迁移的关键不是“复制几个目录”，而是弄清楚程序、模板、数据库、资源和服务器规则之间的对应关系。迁移前记录现状，迁移中保留可回滚的备份，迁移后按真实业务逐项验证，通常比事后猜测故障原因更省时间。若站点是多年改造的旧项目，先在副本上查清自定义依赖，再制定迁移或升级计划，尤其重要。