网站设计外包交付物可以验收但不能被使用时怎样界定缺口
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /b51b00b081c3.html
📄
网站设计外包交付物可以验收但不能被使用时怎样界定缺口
能验收但不等于能用，通常不是验收单写错，而是验收对象停在“文件存在”，没有跨到“在真实环境中可执行”。要界定缺口，先把争议落到一个具体页面上，再按“打开—替换—发布—回退”四步复现，看断点出在哪一步。
先区分两类成立条件：文件级合格与使用级合格
文件级合格指交付包里有可打开的设计稿、导出的图片、样式文件或页面文件，命名清楚，数量对得上。使用级合格指这些文件放进目标站点后，页面能正常显示、链接能跳转、表单能提交、样式不互相覆盖。两者可以同时成立，也可以只成立前者。
当只有个别样本成立时，常见原因是样本恰好没有依赖缺失的资源、没有触发冲突的样式、没有走到需要接口返回的环节。规模一放大，例外就出现。所以不要把单个页面的通过当成整站通过，也不要把整站的失败当成所有页面都不可用。
拿一个页面做四步复现，定位缺口位置
选一个在验收单上已经“通过”、但实际使用时出问题的页面，按下面顺序操作，每一步记录结果：
- 打开：用目标环境的访问方式打开该页面，而不是只在本地双击文件。若打开后样式错位、图片缺失，缺口在资源路径或依赖引用。
- 替换：把交付的页面文件或样式放入目标站点对应位置，刷新查看。若替换后其他页面受影响，缺口在样式作用域或公共文件覆盖关系。
- 发布：走一次实际发布流程，观察是否需要人工改路径、改入口或补文件。若必须手工修补才能上线，缺口在交付物与发布流程的衔接。
- 回退：把这次替换撤掉，确认原状态能恢复。若撤不干净，缺口在文件版本或目录结构没有交代清楚。
四步中最早失败的那一步，就是缺口的边界。它比“整体不可用”更可操作，因为它指向一个具体环节，而不是一句笼统的评价。
用假设例子说明缺口如何被算清
假设某次外包交付了一个产品列表页，验收时打开文件能看到完整排版，于是被记为通过。上线后该页在目标站点里图片全部裂开，但同一批交付的另一个静态页正常。此时不能直接判定“整批交付不可用”，而应检查两页的资源引用方式是否不同：正常页用的是相对路径，问题页用的是本地绝对路径。缺口就落在资源路径规则上，而不是全部文件。
这个判断会改变下一步：如果缺口只在路径规则，处理动作是要求交付方按目标站点的目录约定重新导出引用，并抽两个以上同类页面复验；如果替换后连其他页面也错位，处理动作就要先隔离公共样式，再谈单页修复。动作不同，验收结论和后续工作量也不同。
把缺口写成可执行的处理方案
界定清楚后，不要停在“请修复”。把缺口写成三列信息：现象、触发条件、可验证的完成标准。例如现象是“列表页图片不显示”，触发条件是“放入目标站点根目录后”，完成标准是“同一目录下打开该页，图片全部加载且不修改其他页面”。
然后按影响范围排序：先处理会阻断发布或影响多页的问题，再处理只影响单页展示的问题。每修一项，用同一套四步复现再走一遍，确认没有引入新的替换冲突。若某项修复需要改变原有目录结构，应先确认这是双方都接受的方案，再继续，否则会把缺口从页面层推到结构层。
哪些情况下不能直接照搬这套判断
如果目标站点本身还在改版、发布流程未定，那么“发布”和“回退”两步的结论不稳定，此时只能先确认文件级合格，把使用级验收推迟到环境稳定后。若交付物包含第三方接口或外部资源，而接口在验收时不可用，那么页面打不开可能来自外部依赖，不应直接算作交付缺口，需要先区分是资源不可达还是引用写错。样本量很小时，个别页面通过也不能推断整站可用；反过来，个别页面失败也不能推断全部失败。把边界写进验收记录，比追求一个笼统的通过结论更有用。
