网站交接需要哪些清单?避开性能优化陷阱
网站做好了没人访问，别急着怪推广没跟上。很多时候，问题出在交接环节。上一手代码烂、服务器配置乱、SEO标签缺失，导致后续性能优化无从下手。
很多市场人员以为建站是设计师的事，上线后只要盯着点击率就行。大错特错。如果拿到的网站像个大杂烩，连基本的文件结构都理不清，后期改个价格都得提心吊胆。更可怕的是，那些没被写进文档的“坑”，会在流量起来时瞬间爆发，拖垮整个服务器。
网站交接不是一张简单的账号密码表。它是一套完整的资产移交流程。今天咱们不聊虚的，直接拆解一份老法师都在用的交接清单。从威胁场景到代码级防护，从目录规范到性能基线，每一步都得落实到人、落实到文件。
一、 威胁场景：谁在盯着你的服务器
接手一个旧站，最怕的不是功能少，而是“历史遗留问题”。
想象一下，你从外包公司手里接过一个运行了两年B2B网站。对方说：“都正常，账号给你了。”你登录后台，发现管理员密码还是初始的admin/123456。数据库连接文件config.php里，数据库密码明文写着。
这不是段子，这是行业常态。
常见交接风险场景：
- 敏感信息泄露：FTP账号、数据库密码、SSL私钥、API密钥全部明文躺在代码里。一旦代码被误提交到公共仓库，或者服务器被入侵，整个业务数据瞬间裸奔。
- 权限混乱：运维、开发、设计共用一个服务器root账号。谁改了什么，谁删了什么，查无实据。一旦出问题，互相推诿。
- 依赖版本失控：PHP版本是5.6，WordPress插件全是3年前的版本。这些老旧组件本身带着高危漏洞，攻击者扫描到直接打穿。
- 性能债务堆积：图片没压缩、CSS/JS没合并、数据库查询没加索引。网站打开要10秒，用户早就关了。这时候谈性能优化，无异于在漏水的船上修装饰。
这些风险，在交接时如果不识别，就是给未来埋雷。雷什么时候爆？就当你准备投SEM广告，流量涌入的那一刻。
二、 漏洞原理：代码里的“后门”
为什么这些旧站容易出事？因为早期开发往往追求“快”，忽略了安全边界。
以最常见的SQL注入为例。很多旧站的数据查询直接拼接用户输入。
危险代码示例（PHP）：
// 错误示范：直接拼接用户输入
$username = $_GET['user'];
$query = "SELECT * FROM users WHERE username = '$username'";
$result = mysqli_query($conn, $query);
如果攻击者在user参数后输入' OR 1=1 --，SQL语句就变成了SELECT * FROM users WHERE username = '' OR 1=1 -- '。数据库会返回所有用户数据，甚至执行恶意命令。
再看文件上传漏洞。旧站常允许上传任意类型文件，且不检查真实文件头。
危险代码示例（PHP）：
// 错误示范：只检查扩展名，不校验文件内容
if (strpos($_FILES['file']['name'], '.jpg') !== false) {move_uploaded_file($_FILES['file']['tmp_name'], 'uploads/'.$_FILES['file']['name']);
}
攻击者只需将木马文件改名为shell.jpg上传，再通过URL访问，就能执行任意代码。服务器瞬间变成肉鸡。
这些漏洞原理看似基础，但在交接时，如果没人逐行审查关键代码，这些“小毛病”就会成为致命伤。尤其是那些为了赶工期，由初级开发者堆出来的代码，更是重灾区。
三、 防护方案：交接时的“安检”流程
拿到代码和服务器，别急着改功能。先做“安检”。
第一步：凭证清洗与重置
- 数据库：创建新的专用数据库账号，权限最小化（只给SELECT, INSERT, UPDATE, DELETE权限，禁止DROP, ALTER）。删除原有的高危账号。
- FTP/SFTP：禁用FTP，改用SFTP。为每个角色（开发、运维）分配独立账号，禁止使用root或admin账号操作。
- SSL证书：检查证书有效期。如果是自签名证书，必须更换为受信任CA颁发的证书。私钥文件权限设为600。
第二步：代码安全审查
重点审查以下文件：
config.php或.env文件：确保所有敏感信息（数据库密码、API Key）不在版本控制中。建议将配置文件移出代码目录，或使用环境变量。- 登录页面：是否有暴力破解保护（如验证码、登录失败锁定）。
- 文件上传目录：确保该目录禁止执行PHP脚本。
Nginx配置加固示例：
# 禁止在上传目录执行PHP
location ~* ^/uploads/.*\.php$ {deny all;return 403;
}# 隐藏版本号，防止攻击者针对特定版本漏洞
fastcgi_hide_header X-Powered-By;
server_tokens off;
第三步：依赖项更新
检查CMS（如WordPress、Drupal）及其插件、主题的版本。
- WordPress：确保核心版本为最新。
- 插件：卸载未使用的插件，更新剩余插件到最新版本。
- 主题：确认主题来源可靠，无后门代码。
这一步非常耗时，但至关重要。很多旧站的崩溃，都是因为一个未更新的插件引入了漏洞。
四、 检测与修复：工具化验证
光靠人眼审查不够，得用工具。
1. 漏洞扫描
使用开源工具进行自动化扫描。推荐OWASP ZAP（Zed Attack Proxy）。它是GitHub上非常活跃的开源项目，拥有完整的社区支持和规则库。
在交接阶段，运行一次基础扫描：
- 启动ZAP，指向目标网站。
- 执行“Active Scan”。
- 关注High和Medium级别的漏洞。
2. 代码审计
对于关键业务代码，使用静态分析工具。
- PHP项目：使用
phpstan或psalm进行类型检查和潜在错误分析。 - JavaScript项目：使用
eslint配合安全插件（如eslint-plugin-security）检查不安全API使用。
3. 性能基线测试
这是性能优化的前置步骤。用工具量化现状。
- Lighthouse：Chrome内置工具，生成性能、可访问性、最佳实践和SEO报告。重点看Performance Score和LCP（最大内容绘制）。
- GTmetrix：提供详细的瀑布图，看到底哪个资源加载慢。
修复案例：图片优化
假设Lighthouse显示LCP高达4.5秒，主要瓶颈是首屏大图。
优化前：
- 原图大小：2MB，格式JPG，尺寸3000x2000px。
- 加载时间：3.2秒。
优化后：
- 使用WebP格式，尺寸压缩至1200x800px（适配主流屏幕）。
- 添加
loading="lazy"属性。 - 使用CDN加速。
- 代码实现：
<!-- 优化后 -->
<img src="hero-image.webp" alt="产品主图" width="1200" height="800" loading="lazy" srcset="hero-image-480.webp 480w, hero-image-800.webp 800w, hero-image.webp 1200w"sizes="(max-width: 600px) 480px, (max-width: 1000px) 800px, 1200px"
>
修复后，LCP降至1.2秒。这就是性能优化的直观效果。没有这个基线，后续优化就是盲人摸象。
五、 安全加固清单：交接验收标准
完成上述步骤后，需要一份可执行的验收清单。这份清单不仅是技术文档，更是责任划分的依据。
1. 文档交付物
- 服务器架构图：包含IP、端口、用途、负责人。
- 账号权限矩阵：谁有什么权限，操作日志记录在哪里。
- 部署文档：如何从代码到上线，包含每一步的命令和注意事项。
- 紧急联系表：域名服务商、服务器商、CA机构、核心开发人员联系方式。
2. 代码规范检查
- 代码是否遵循统一规范（如PSR-12 for PHP）。
- 是否有单元测试覆盖核心逻辑。
- Git仓库历史是否干净，无敏感信息提交记录。
- 依赖项是否锁定版本（
package.json或composer.lock）。
3. 性能指标承诺
在交接协议中，明确以下指标作为验收标准：
- 首屏加载时间：< 2秒（4G网络模拟）。
- TTFB（首字节时间）：< 500ms。
- 可用率：99.9%。
- 安全扫描：无高危漏洞。
4. 备份策略
- 数据库：每日自动备份，保留30天。
- 代码：推送到私有Git仓库。
- 配置：Nginx/Apache配置、数据库结构定期导出。
- 恢复演练：必须实际执行一次从备份恢复的流程，确认可用。
给市场人员的建议：
作为市场推广人员，你可能不懂代码，但你必须懂“资产”。网站是公司的数字资产，交接就是资产盘点。
- 不要只看界面：界面好看，后端烂掉，等于买了辆漂亮壳子车，发动机是坏的。
- 索要测试报告：要求开发方提供交接前的安全扫描和性能测试报告。如果没有，说明他们没做过，风险极大。
- 明确责任边界：交接后，谁负责维护？谁负责更新？SLA（服务等级协议）怎么定？这些必须白纸黑字写清楚。
很多公司建站花了十几万，结果因为交接不清，半年内就出现数据泄露、网站打不开等问题，被迫重新开发，浪费几十万。这就是没做好交接的代价。
性能优化不是上线后的一次性任务，而是贯穿全生命周期的持续工作。交接时的基线数据，是后续所有优化决策的依据。
最后，抛出一个问题：
建站花了多少钱？留言说说真实价格。
是想听听同行们避坑的经验，还是想知道怎么把预算花在刀刃上？评论区见。