整站源码术语：骨架、依赖与部署包

拿到一份整站源码时，最先要弄清的不是代码写得好不好，而是它由哪些部分构成。骨架、依赖、构建产物、部署包这几个词经常被混着说，导致交付时缺文件、部署时跑不起来。下面按构成、用途、操作步骤和验收要点说明。

一、四个术语的含义
骨架指源码中与业务无关的基础结构，包括目录约定、入口文件、路由组织、公共配置和基础样式，决定项目如何被组织和启动。依赖指项目运行所需的外部代码库，通过依赖清单声明版本范围，安装后落到本地依赖目录，通常不纳入版本管理。构建产物指源码经过打包、压缩、转译后生成的静态文件，是真正被访问的资源。部署包指为上线准备的完整集合，包含构建产物、运行配置和必要的启动说明。四者的关系是：骨架提供结构，依赖补齐能力，构建把源码变成产物，部署包把产物和配置打包交付。

二、交付与部署步骤
第一步核对骨架完整性：入口、配置、目录说明是否齐全。第二步检查依赖清单是否锁定版本，是否区分运行依赖与开发依赖。第三步在干净环境执行安装与构建，确认无隐式全局依赖。第四步比对构建产物与源码的对应关系，确认没有遗漏资源。第五步整理部署包，写明运行环境要求、启动方式、可写目录和回退方式。第六步做一次从零部署演练，记录每一步耗时与报错。

三、常见问题
依赖版本不锁定，换个环境就装出不同结果；开发依赖被误当成运行依赖，部署后缺包；构建产物被提交进版本库，导致源码与产物不一致；部署包缺少可写目录说明，运行时报权限错误；骨架里的配置写死环境信息，迁移即失效。这些问题都不涉及业务逻辑，却最影响交付效率。

四、验收清单
逐项确认：干净环境能否一次安装成功；构建是否可重复且结果稳定；产物是否包含全部静态资源；配置是否与代码分离；部署包是否含回退说明；日志与错误输出是否有明确位置。把这六项作为交付前的固定动作，比事后排查更省力。

术语清晰带来的直接好处是责任清晰：骨架问题找结构，依赖问题找清单，产物问题找构建，交付问题找部署包。分得清，才改得准。