网站验收只看设计稿和页面截图可以吗？

不可以。截图不能证明手机适配、表单通知、权限、下载、错误处理和正式部署正常，必须在实际网址上按真实路径操作。

网站已经上线，为什么还要交接源码？

是否交付源码取决于合同，但必须提前约定。若约定交付，企业还应获得可运行版本、依赖说明和必要的部署资料，而不仅是无法验证的文件包。

应先判断它是未达到原约定、实际缺陷，还是新增需求。前两类按验收和修复约定处理；新增需求需要重新评估范围、工时和发布时间。

先建立旧网址清单，标出保留、合并、删除和跳转目标。上线后逐项检查重要旧网址是否到达正确新页面，并确认站点地图已经更新。

“页面大气、功能正常、兼容手机”都不是完整验收标准，因为不同人可能得出不同结论。验收项应包含操作条件、预期结果和必要证据。例如在指定手机宽度打开产品页，文字不需要缩放，按钮可以点击，内容没有横向溢出。

验收清单最好在开发前确认，而不是项目完成后临时提出。这样制作方知道需要达到什么结果，企业也不会把新增想法混入缺陷修复。错误、未达到约定结果和新增需求应分别记录，采用不同处理方式。

先建立公开页面清单，逐项核对标题、正文、图片、电话号码、地址和下载文件。不能只检查首页，因为错误更容易出现在详情页、旧内容和页脚。涉及产品参数、资质和案例时，应由业务负责人确认事实与公开权限。

移动端至少检查主导航、长标题、表格、表单、弹窗和固定按钮。页面能缩小显示不等于完成手机适配，用户不应依赖双指放大或左右拖动阅读主要内容。还要检查触摸区域、键盘弹出后表单和返回操作。

表单不能只确认按钮出现了成功提示，而要验证负责人实际收到通知、后台保存的数据完整、重复提交和发送失败有明确处理。登录、搜索、预约或订单功能也应使用接近真实的数据走完一条完整流程。

随后测试异常情况，包括必填项为空、格式错误、附件过大、网络中断、重复点击和权限不足。异常提示应让用户知道如何继续，又不能暴露服务器路径、密钥或内部错误。只有理想路径通过，无法证明功能可以稳定使用。

企业网站上线前应确认每个重要页面具有独立且准确的标题和描述，正式域名使用 HTTPS，站点地图和抓取规则能够访问，测试域名不会被当作正式网址收录。改版项目还要为有价值的旧网址建立对应关系，避免大量页面直接失效。

同时检查首屏资源是否明显过大、图片是否按显示尺寸处理、页面是否存在持续报错。这里不应承诺某个排名或收录日期，验收目标是让搜索引擎能够访问正确页面，并让用户在常见网络和手机环境中顺畅获取主体内容。

页面上线不代表企业已经掌握网站。域名注册账号、云服务器、代码仓库、对象存储、统计平台、邮件服务和第三方接口可能分散在不同账户。交接时应列出账号归属、权限级别、续费主体和找回方式，敏感密码通过安全渠道移交。

源码交付还要说明版本、构建方式、运行环境和依赖，不应只收到一个无法启动的压缩包。若项目约定不交付源码，也必须在合同和报价中提前写明。数据库结构、初始化步骤和必要配置应有可执行说明，但真实密钥不能写入仓库或交付文档。

上线切换前应保留旧版本或可恢复备份，明确由谁执行域名、数据库和文件变更。切换后立即检查首页、关键详情页、表单、登录、证书和统计，不要只凭服务器显示运行中就宣布完成。

如果出现严重问题，应能恢复到上一版本，而不是在公开网站上长时间直接修复。数据库发生结构变化时，还要确认备份是否真的可以恢复。回滚方案不需要复杂，但必须与本次发布的实际变化对应。

完整交接包通常包括页面和功能清单、已知限制、源码或仓库权限、账号清单、部署说明、备份方式、管理员使用说明和验收记录。企业应指定接收人核对材料，而不是将文件散落在聊天记录中。

最后确认缺陷修复期从何时开始、怎样提交问题、响应边界是什么，以及新增需求如何评估。上线后的内容更新、服务器维护和第三方续费也要确定责任人。把这些安排写清楚，项目才能从制作阶段平稳进入长期运行。