鉴别成品网站源码，不能只看商品标题、演示站或卖家发来的截图。更可靠的做法是把来源凭据、交付文件、演示功能和实际代码逐项对照：先确认卖家对源码的提供权限及交付范围，再检查文件能否部署、页面功能是否由对应代码实现，最后按接口说明测试关键业务。1688是交易渠道，不等同于源码版权证明；商品标注“源码”也不代表交付物一定包含完整后端、数据库结构和部署配置。
先分清商品承诺的是哪一种“源码”
成品网站源码可能指可运行的网站项目，也可能只是前端模板、页面切图或定制开发的起始框架。鉴别前，应把商品描述拆成可核对的交付清单，至少明确是否包含前端、服务端代码、数据库脚本、配置示例、安装说明和约定的业务模块。
- 完整项目源码：通常能找到前端与后端目录、依赖清单、数据库迁移或建表文件，以及启动和部署说明。具体技术栈因项目而异，关键是文件之间能组成商品承诺的功能。
- 前端模板：可能包含页面、样式和静态示例数据，但没有处理登录、订单或管理操作的服务端逻辑。若商品描述承诺这些业务，应进一步确认后端代码或接口是否一并交付。
- 演示站或定制服务：可以用来展示效果，却不自动说明买家会获得可编辑的源文件。应在交易约定中写明源码文件、部署协助、授权范围和售后边界。
在1688商品沟通中，可要求卖家按目录说明交付内容，并用一项具体功能举例：用户提交表单后由哪个接口处理、数据保存在哪里、后台从哪里查看。答复若始终停留在“功能齐全”“一键上线”等描述，就还没有形成可验证的交付承诺。
来源与真实性：把卖家说明变成可核对证据
先核对商品描述、聊天约定、合同或订单备注中的项目名称、功能范围、交付格式、授权用途和售后责任是否一致。若卖家称源码由其开发或获得转售授权，可要求其提供与项目对应的权属或授权说明；演示账号、截图和口头承诺只能证明展示过某种效果，不能单独证明卖家有权交付代码。
- 核对演示与承诺：把商品列出的关键页面和业务操作逐项记录，例如注册、商品管理、下单或后台审核。确认演示站实际操作的结果，而非只对照首页图片；如果演示站与商品描述不符，要求卖家明确差异及交付时是否补齐。
- 核对交付清单：要求明确压缩包内应包含的模块、数据库文件、环境示例、依赖说明和部署文档。对“全套源码”“永久使用”等模糊说法，追问是否包含第三方组件、素材和后续更新，以及授权能否用于商用或多个站点。
- 保留对应记录：将承诺的功能、文件清单、授权范围和验收条件写入订单约定，并保存沟通记录。这样收到文件后可以按约逐项验收，而不是只凭卖家发来的演示视频判断。
这些核对不能代替法律文件，但能区分“有演示效果”和“交付范围明确、来源说法有凭据”这两件事。平台交易记录可用于追溯约定，不应被当成源码本身真实或拥有完整权利的证明。
拿到文件后：检查目录、部署过程和页面功能
收到源码后，先解压到隔离的本地测试环境，不要直接放到生产服务器。浏览目录和配置文件，确认实际交付物与清单一致；检查项目是否有依赖清单、环境变量示例、数据库初始化脚本、构建或启动命令。文件名像“完整源码”并不能证明项目完整，能否按说明构建和启动，才是基础验证。
- 对照文件结构：检查页面代码是否对应演示中的页面，后端路由是否覆盖承诺的业务，数据库表或迁移脚本是否包含相关数据结构。若只找到静态HTML，却没有商品承诺的后台处理代码，应要求说明或补齐。
- 在测试环境部署：按文档配置数据库连接和必要环境变量，再执行项目提供的安装、迁移与启动步骤。记录缺失依赖、无法构建的模块和错误日志；源码能启动只是起点，还需继续验证关键功能。
- 对照操作结果：分别测试一项前台操作和对应后台结果，例如创建测试商品后能否在列表查看，提交测试订单后后台能否读取并更新状态。使用测试数据，不要把真实用户资料或生产数据库接入尚未验收的项目。
如果卖家只提供编译后的静态文件、远程演示地址或屏幕录制，应据此判断交付类型，而不要把它们直接等同于可修改、可部署的完整源码。
接口契约核验：看说明、实现和结果是否一致
对声称包含业务后端的项目，接口文档应能说明请求路径、方法、参数、身份要求和返回结果。随后在本地测试环境中找到对应路由或控制器，确认它确实处理这些数据，并检查操作结果是否反映到数据库或后台页面。下面是一个用于验收“创建订单”功能的示例契约，字段应以实际商品约定为准：
POST /api/orders
请求：{ "items": [{"productId": 101, "quantity": 2}], "addressId": 8 }
成功：返回订单编号和初始状态
异常：商品不存在、库存不足或未登录时返回明确错误
验收时可用测试账号提交一笔测试订单，检查接口响应是否包含订单编号，再确认后台能看到对应订单、数量与状态。如果文档写的是创建订单，实际接口却只返回固定演示数据，或者订单没有保存到项目使用的数据存储中，就说明接口说明、代码实现和业务结果没有闭合。接口名称存在、能返回HTTP成功状态，都不足以单独证明业务已经实现。
最后可按结果分三类：来源与授权说明清楚、清单齐全且关键功能能在本地复现，可进入约定验收；部分模块或部署依赖缺失，但卖家能给出明确补交方案，应先补充书面约定；来源说法无法对应、交付物与清单明显不符，或核心接口只有静态演示结果，则不应按“完整可运行源码”验收。核心原则是让商品承诺、授权范围、实际文件和功能测试相互对应。