网站全源码交付，要重点核实哪几个关键点

      拿到源码那一刻，很多人是懵的。一个压缩包解开来，几十上百个文件夹，看着挺齐全，真要用起来才发现处处是坑。

下面这些点，都是实际项目里踩过、或者见过别人踩的，挑要紧的说。

最怕的是代码加密。

有的服务商交付时核心文件是加密过的，用了 Zend Guard、ionCube 这类工具处理。文件摆在你面前，你打不开也改不了。更隐蔽的做法是不加密，但把关键逻辑塞进一个看起来正常的公共文件里，或者把文件后缀改掉，让你以为那是个图片或者配置。

怎么查？全站搜一下 eval、base64_decode、gzinflate 这几个函数，正常的业务代码不该出现这些东西。再看文件头是不是规规矩矩的 PHP 开头。有个别加密文件混在里面，说明对方留了后手。

数据库这块也得盯紧。完整的交付应该包含表结构和数据。只给结构不给数据算运气好的，至少你还能搭起来；怕的是连表都少几张，本地一跑，满屏报错。

还有一种情况不容易发现——数据库里存着跟原服务商绑定的配置，比如接口地址、通信密钥。功能上看不出异常，等你换了服务器，某个模块突然就不干活了。

授权问题，是网站建设这一环里最容易出事的。

交付过来的代码，里面可能用了商业插件、付费字体、图库素材。原服务商买的是单站点授权，你换个域名就等于侵权。中文字体尤其常见，一套商用授权一年几千到几万不等，不少老板是收到律师函才知道有这回事。

所以交付的时候让对方出一份第三方组件清单，写明白每个插件、字体、图片的来源和授权范围。这份清单的价值不比源码本身低。

权限要拿到最高级。

      后台必须给超级管理员，所有配置能改、所有用户能管。有些服务商给的是普通管理员，一半菜单看不见，想加个功能模块加不了。

顺便看一眼用户列表里有没有不认识的账号，有就清掉，或者干脆把数据库里的用户表重刷一遍。

环境依赖必须写清楚。

这份代码要跑起来，PHP 用几点几、要不要装扩展、数据库什么版本、服务器跑 Nginx 还是 Apache。这些不给，你手里就是一堆死代码，找人部署都无从下手。

靠谱的做法是让对方在一个干净环境里重新部署一遍，跑通了再交。这一步能挡掉大部分源码不全的问题。

还有一种最阴的，远程门。

代码里藏一段校验，隔段时间去原服务商的服务器问一声“这个站还有效吗”，验证不过网站就打不开，或者某个功能悄没声地瘫掉。你查不出毛病，因为它本来就是故意留的，逻辑写得跟正常业务一样。

查的办法是搜代码里的外部域名和接口地址，看有没有你不认识的联系。正常的代码不该主动往外发请求。

前端源文件也别忘了要。

设计稿源文件、图标源文件、图片素材，不给的话以后想改个页面都得重做。这一项很多服务商默认不提供，得提前写进合同。

域名、服务器、备案、SSL 证书，交付时要一起过户。这部分容易被当成小事，等到续费没人管、备案还挂在对方名下，才知道麻烦。

网站建设这个行业，源码交付本来就缺乏统一标准，各家给的深浅差别很大。所以只能自己盯。

说到底就一个判断标准：能不能独立运行，能不能自由修改。这两条做不到，文件给你也只是个摆设。

签合同的时候把这些条目写进去，比事后扯皮有用得多。