拿到网站更新包后，不应先删除线上原目录再解压。更新包可能只包含本次变化的几份文件，目录名看起来像完整程序，实际并不含所有页面和公共模块。删除原目录，会把包中没有的现有文件一起移除。
网站更新包覆盖的正确方式，取决于它是完整发布包、增量文件包，还是需要工具执行的构建产物。先核对类型与实际清单，再选择部署方法。目录名相同，并不意味着操作应该是整目录替换。
第一步，确认包的类型与适用版本
先查看随包说明：本次解决什么问题，适用于哪个网站与基础版本，采用什么部署方式，包含哪些文件，是否涉及数据或配置。缺少这些信息时，应先向交付人员补齐，而不是在正式站试试看。
完整包可能提供独立运行所需的程序，但仍不一定包含站点配置、上传资源和数据库。增量包通常只包含需要新增或覆盖的文件，依赖现有程序继续存在。两类包都不能单凭压缩文件大小判断。
还有些项目采用原子版本发布或自动部署，文件应进入独立版本目录再切换，不适合手工合并到旧目录。文章中的合并步骤仅适用于已经确认的增量文件更新，不能替代项目实际发布方案。
假设更新只修改文章列表与后台处理，包里出现几个熟悉业务目录很正常，但这些目录可能只各有一份新文件。看到目录名称，就删除线上的完整业务目录，是把增量范围误读成整站范围。
这一阶段的成功标志是能说清包类型、基础版本、变化范围和采用方法。只知道“这是最新版”仍不足够，因为最新版也可能依赖之前的程序和未变化资源。
第二步，对照包内文件与线上目标
解压到本地或隔离位置，查看真实文件清单，不要先在网站根目录展开。核对每个相对路径、用途和预期目标，确认包内是否存在额外外层目录，以及是否含不应公开的说明或备份文件。
文件清单应区分新增、覆盖和明确删除。增量包没有某个文件，通常不能理解为要求删除它；只有部署说明明确废弃的对象，才进入删除范围。忽略这一点容易破坏包中未包含的旧功能。
文件清单最好来自实际包内容，而不是只复制开发人员计划。制作包时可能漏文件或多带资料，计划与成品之间仍有一步核对。让包清单和交付说明互相对应，可以在上传前发现问题，不必等正式功能报错才检查缺失。
可以选一条文件路径，从包根一路读到文件名，再与线上目标对照。例如某业务模块里的列表文件，应进入对应模块位置，而不是另建一个重复模块目录。每条路径都应有明确目的地。
如果线上文件已有其他修改，要先比较差异。增量包基于旧版本制作，直接覆盖可能抹掉后来新增的修复。遇到这种情况，应由实施人员合并内容或重建适用包，不能靠文件时间新就判定可以覆盖。
同时检查包有没有需要执行的数据调整或依赖更新。文件列表本身不能证明更新只影响文件；说明中若有数据库变化，就要另列范围与恢复准备，不能隐藏在一句“复制进去即可”。
成功标志是包中的所有目标路径清楚，未包含对象保持现状，已有改动处理方式确定，部署说明与实际内容一致。清单不一致时，应先修正包或说明，再继续正式操作。
第三步，备份将被覆盖的对象及当前状态
在更新前保留需要覆盖的原文件，并记录原始相对位置与版本。备份不能只放在同一个可能被整体删除的目录里，也不应以公开可访问方式散落在网站文件中。
是否还需要数据库与上传资源备份，要看本次变化。程序文件恢复不自动撤回数据状态；如果更新会写入数据或改变结构，恢复范围应单独说明。只复制几份程序，不能称作完整站点恢复方案。相关操作可参阅《企业网站怎么备份？文件、数据库、配置与恢复演练》。
备份后可以核对能否找到一份原文件、能否确定它应恢复的位置。对于更复杂的发布，需要在隔离环境验证恢复。备份存在不代表使用者知道怎样把它放回正确位置。
当前新增的业务数据也要考虑。若部署期间仍有表单提交或文章编辑，应按实际流程安排受影响范围与核对方式，避免恢复时把后来数据一起覆盖。暂停或保留方式由业务与实施人员共同确定。
成功标志是每个覆盖对象有可定位的原版本，必要数据与配置范围明确，出现问题时知道该恢复哪一项。不能只以“已经压缩一个目录”代替这份对应关系。
第四步，按已确认的增量方式合并
对于确认采用增量文件更新的项目，合并是保留原目录中未变化的内容，将包里的新增文件放入对应位置，并覆盖清单指定的文件。它与先删除目录再重建是不同操作。
上传或同步工具可能有合并、替换、镜像等模式，名称与行为需要核对。某些模式会删除目标中未出现的文件，不能看到“覆盖”两个字就放心执行。先在隔离目录验证工具行为，再用于正式目标。
在工具要求确认覆盖时，要注意确认范围是一份文件还是整个目录。有些文件管理器显示相近提示，实际操作不同。先核对目标和工具行为，再完成已授权部署；如果行为无法确定，可以在隔离位置做小样本，不能以经验猜测正式结果。
可以采用少量文件的受控更新，检查完成的路径与文件版本，再继续后续范围。但部署是否允许分批、是否存在中间不一致，要由程序依赖决定；不能把所有更新都拆成任意顺序。
包里的说明、临时文件和源码备份，不应因为位于压缩包中就公开进入网站根目录。可部署对象应由清单定义，交接资料则保存在合适位置，避免把管理资料当成程序文件。
更新后逐项核对新增与覆盖结果，检查是否出现意外嵌套、缺失或重复目录。如果发现目标不对，先停止后续写入并定位已改变范围，不要继续拖动文件直到页面看起来正常。
这一阶段的成功标志是清单中的文件位于预期位置，原目录的未变化对象仍在，工具没有执行额外删除。上传进度完成，只证明传输结束，不能证明合并范围正确。
第五步，检查新增功能与未包含功能
先验证本次变化的任务，再核对它依赖的原有功能。例如更新文章后台，测试当前操作、保存读取与必要语言关系；若改了公共模块，补充受影响入口的核对。
包中未包含的功能也要按关联范围抽查。登录、联系表单、图片加载或其他后台页面，可能依赖仍需保留的程序。首页能打开，无法证明业务目录没有被误删。
可以用受控样本实际走一遍，比较页面反馈与保存记录。不要只检查新按钮出现，也不要用旧缓存页面证明更新已经生效。必要时由实施人员查看实际文件和运行结果。
发现阻断问题时，按预定范围恢复，并再次验证相关功能。文件恢复与数据调整分开处理，已完成的内容操作要依据真实清单判断。恢复旧程序不能自动把业务状态退回过去。
如果验证发现原有功能异常，也应先查看本次清单是否触及它依赖的公共对象。相关范围没有变化时，可能需要另外排查环境或配置；不要为了快速恢复，又从其他来源随意补进一堆旧文件。每轮修复应有可解释的对象和结果。
最终交接记录保留包版本、实际覆盖清单、备份位置、功能结果和未解决事项。成功标志是新任务可用、原有相关任务继续工作，后续人员能够解释这次改了什么以及怎样恢复。
常见问题
包中有完整目录名，是否说明这是整站包？
不一定。增量包也可能保留原目录结构，但每个目录仅包含本次变化文件。应看实际清单和说明，不按目录名判断完整性。
增量包里没出现的旧文件应删除吗？
通常不应据此删除。缺席不等于废弃，删除需要明确清单与依据。镜像同步模式尤其要注意是否会自动删除目标文件。
所有网站都适合手工合并更新吗？
不是。自动部署、独立版本切换或特定构建流程，应采用现有发布方式。手工合并只适用于已经确认的相应文件更新方案。相关操作可参阅《企业网站上线流程：域名、服务器、证书、缓存与验证清单》。
文件备份做好后，可以忽略数据库吗？
取决于本次变化。只修改文件与修改数据结构或业务状态不同。应分别列范围，不能用程序备份代表数据库也可恢复。
上传没有报错，为何还要检查旧功能？
传输成功不证明目标位置和保留范围正确。误删或覆盖公共文件可能影响未更新模块，按依赖核对原有任务才能发现这些问题。
链接复制成功
