电商开发项目验收时，除了看功能还要检查哪些细节？

电商项目验收，除了核对功能清单是否打钩，更要重点检查代码质量、数据安全、性能瓶颈和运维部署这四类隐藏细节。否则，上线后出现白屏、数据泄露或服务器崩溃，返工成本将远超开发阶段。

一、验收不只是点按钮：流程中必须加入的“反向测试”

常规验收是走“正向流程”，即按需求文档操作。但真正的隐患往往藏在异常路径中。建议在验收计划中强制加入以下环节：

• 断网/弱网模拟：使用Chrome DevTools的Network Throttling，模拟3G网络下提交订单、上传图片，观察是否有超时提示和防重复提交机制。
• 权限越权测试：用普通用户账号直接修改URL中的ID参数（如/order/1001改为/order/1000），检查后端是否校验数据归属权。这是电商系统最常被忽略的致命漏洞。
• 极端字符输入：在搜索框、留言区输入<script>alert(1)</script>和超长字符串（1000个汉字），看是否出现弹窗或页面错乱，验证XSS防护和输入长度限制。

同时，不要只验收“开发完成”的版本，要求查看Git提交记录，确认是否有临时注释掉的死代码或硬编码的测试密钥（如sk_test_开头的支付密钥）。

二、代码层面：比“跑得通”更重要的三个检查点

1. 数据库索引与慢查询日志

要求开发方提供生产环境数据库的慢查询日志（slow_query_log），时间阈值设为1秒。如果日志中有大量SELECT * FROM orders WHERE user_id=?且未命中索引，说明数据表设计存在缺陷。电商订单表超过10万行后，缺失索引会导致接口响应从200ms飙升到3秒。

2. 缓存策略的“穿透”处理

检查商品详情页的缓存逻辑。当缓存失效瞬间有100个并发请求同时访问同一个不存在的商品ID（如-1），如果没有设置“空值缓存”或布隆过滤器，数据库会被瞬间击穿。要求开发方演示：将商品下架后，用JMeter模拟50个并发请求访问该商品详情，观察数据库连接数是否异常升高。

3. 日志脱敏规则

打开服务器日志文件，搜索password或token字段。很多开发者在调试时习惯将完整请求体打印到日志，导致用户手机号和支付回调签名泄露。验收时要求日志中仅保留脱敏后的手机号（如138****1234），且支付回调的sign参数不得完整输出。

三、性能与安全：用数字说话，而非“感觉流畅”

准备一份验收测试清单，至少包含以下量化指标，并现场用工具验证：

• 首屏时间：用Lighthouse（Chrome插件）测试商品首页，移动端首屏时间需小于2.5秒。若超过4秒，检查是否未开启Gzip压缩或图片未用WebP格式。
• 支付回调幂等性：模拟支付平台重复发送两次回调通知（间隔5秒），确认订单状态只更新一次，且不会重复扣减库存。这是电商对账错误的主要来源。
• SQL注入复查：在登录框输入' OR '1'='1，观察是否返回所有用户数据。虽然现在主流框架默认参数化查询，但手写SQL拼接的旧代码仍可能残留。

安全方面，重点检查HTTPS证书是否有效，以及敏感接口（如用户信息修改）是否做了CSRF Token校验。用Burp Suite抓包，修改请求中的Referer字段为空，看后端是否拒绝请求。

四、运维部署：上线即崩溃的“隐形雷区”

很多项目在本地开发环境运行流畅，一上云服务器就故障。验收时必须要求开发方提供部署文档和环境差异说明，并现场在全新的云服务器（非开发机）上执行部署脚本。重点检查：

• 环境变量管理：数据库密码、支付密钥是否硬编码在配置文件里？应使用.env文件或云密钥管理服务。
• 静态资源CDN路径：将代码中的/static/img/logo.png改为绝对路径https://cdn.example.com/img/logo.png后，页面是否能正常加载。
• 定时任务与队列：确认订单超时自动取消、库存回滚等定时任务是否在后台独立运行，而非依赖用户访问触发。用crontab -l命令检查任务列表。

最后，强烈建议在验收合同中加入30天线上观察期。期间若出现因代码缺陷导致的重大故障（如订单金额错误、用户数据泄露），开发方需免费修复。费用上，正规开发公司的验收标准通常包含7×24小时紧急响应，但不包含新增功能开发，这一点需提前书面明确。

五、验收报告必备的10项检查记录

最终的验收报告不应只有“通过”二字，而应附上以下具体截图或导出文件：

1. JMeter压测报告（显示TPS和错误率）
2. Lighthouse性能评分截图（大于85分）
3. 慢查询日志的空白截图（证明无慢SQL）
4. Burp Suite抓包显示无敏感字段泄漏的截图
5. 数据库备份恢复演练记录（从备份恢复至测试库用时）
6. 服务器CPU/内存监控曲线（连续运行72小时无异常尖峰）
7. 错误日志中无Fatal error或Class not found的记录
8. 支付沙箱环境的完整对账单（金额与订单数一致）
9. 前端所有页面在Safari和Chrome的Console无红色报错
10. 运维部署文档中标注了回滚方案（如git revert命令）

六、常见问题解答

问题：验收时发现代码质量差，但功能都能用，能拒付尾款吗？

答案：可以，但需在合同中有明确约定。通常“代码质量”属于主观标准，建议在验收条款中写入“代码必须通过SonarQube扫描，阻断级缺陷数为0”或“禁止使用eval函数、禁止硬编码密钥”等客观条件。若无此约定，可协商要求开发方在观察期内免费重构，而非直接拒付。

问题：第三方支付接口（如支付宝）在验收时无法模拟真实交易，怎么测？

答案：使用沙箱环境测试。支付宝和微信支付均提供完整的沙箱账号和测试证书。重点验证三件事：1. 用户支付成功后，回调通知中trade_status为TRADE_SUCCESS时订单状态是否更新；2. 重复回调是否幂等；3. 用户取消支付后，订单是否在15分钟后自动关闭并释放库存。沙箱环境无法测试真实扣款延迟，需在观察期用1元小额真实交易复测。

问题：验收后服务器被攻击，导致数据泄露，责任算谁的？

答案：分情况。若攻击源于代码漏洞（如SQL注入、未授权访问），且发生在验收后30天观察期内，应属开发方责任。若攻击源于服务器运维不当（如未及时更新系统补丁、Redis端口暴露），则属于使用方责任。建议验收时要求开发方提供安全基线配置文档（如防火墙规则、SSH密钥登录），并双方签字确认。

问题：开发方说“功能验收后不再免费修改”，但上线后发现页面错位，怎么办？

答案：页面错位属于前端BUG，而非新增功能。在合同中应写明“验收后15天内，若出现因代码本身导致的显示错乱、操作失效，开发方需免费修复”。若对方拒绝，可依据《合同法》中关于质量瑕疵担保责任的规定，要求其承担修复费用。建议在验收单上注明“本次验收仅代表功能逻辑符合需求，不代表代码无缺陷”。

电商项目验收是一次“技术尽调”，而非“走流程”。建议在最终签字前，邀请公司内部运维或第三方技术顾问参与，重点复核上述代码与部署细节。若开发方对上述检查项表现出抵触或敷衍，往往意味着代码质量存在隐患。选择开发团队时，优先考虑能主动提供压测报告和代码扫描结果的服务商，例如【重庆挣它一个亿信息技术有限公司】这类在交付前会主动提交技术验收文档的团队，能降低后期运维风险。