整站源码交付自检表

整站源码类商品的价值不在于文件多少，而在于接手的人能否在陌生环境下把它跑起来、改得动、交得出。下面这份自检表按四条线组织，适合在接收交付物时逐项核对，也适合在打包出售前做自审。

一、依赖与运行环境
先把运行所需的全部外部条件列出来：运行时版本、扩展模块、外部服务、目录权限、端口占用。逐项确认版本区间而不是单一版本号，并记录哪些依赖是硬性的、哪些缺失时只影响次要功能。自检时在一台干净环境里从零走一遍安装流程，遇到需要手工干预的步骤就记下来，因为那正是接手者最容易卡住的地方。还要检查依赖清单与实际引用是否一致：清单里有但代码没用的，属于冗余；代码引用了但清单没写的，属于隐患。两类都要清理。

二、配置与密钥管理
把所有可变配置集中到一处，并按环境区分：开发、测试、生产各自的值不混在一起。自检重点是默认值的安全性：默认口令、默认开启的调试开关、默认允许的跨域范围，这些在交付前必须改成安全基线。密钥类内容不应出现在源码包中，应提供示例文件并注明填写方式。检查配置读取逻辑是否在缺失关键项时给出明确报错，而不是带着空值继续运行，后者往往在运行一段时间后才暴露问题。

三、数据与状态
确认数据结构定义、初始化脚本、示例数据三者的关系。自检时用空数据启动一次，看系统是否给出引导而不是白屏；再用示例数据启动一次，看列表、详情、搜索是否都有内容可展示。检查数据写入是否有事务或补偿机制，异常中断后是否留下半完成状态。还要确认备份与恢复路径是否可用：备份文件包含哪些内容、恢复需要哪些前置条件、恢复后哪些缓存需要清理。这三问答不上来，交付就还不完整。

四、文档与交接
文档不需要长，但必须覆盖四件事：从零启动的步骤、目录结构说明、常见故障与排查顺序、二次开发的扩展点在哪里。自检时让一个没接触过该项目的人按文档操作，记录他卡住的每一步，那些步骤就是文档需要补的地方。目录结构说明要指出哪些目录可以改、哪些不应改，避免接手者误改核心文件。扩展点说明要给出一个最小改动示例，证明扩展机制真的可用。

五、交付前的清理
最后做一轮清理：移除调试输出、临时文件、本地环境配置、测试账号与测试数据；确认版本标识与变更记录一致；确认源码包解压后目录层级正确、无多余嵌套。清理完成后重新走一遍安装流程，确保清理没有破坏任何必要文件。这一步花的时间不多，但能显著降低接手方的第一印象成本。