黄程宇：第1次个人汇报

• 汇报人：黄程宇
• 报告期次：第1次
• 报告日期：2026-10-08
• 项目：第5组在线购物系统

本次迭代我负责第6–10项任务，主要是商品发布、图片上传校验、买家浏览与意向提交、界面美化和模块自测。我负责的业务链路是：卖家填写并发布商品，买家查看商品、填写购买意向，提交后看到返回的口令码。

一、我完成了什么

任务	我的具体工作	成果链接
6 商品发布	名称、价格必填，价格须大于0并按两位小数处理；发布前检查当前商品，已有在售或冻结商品时拒绝重复发布	商品发布路由
7 图片上传校验	检查空文件、文件大小、扩展名和文件头；校验通过后保存，未上传时使用占位图	图片校验代码
8 买家浏览与意向提交	支持免登录浏览；姓名、电话必填；无商品或商品冻结时拒绝提交；调用公共意向服务并展示返回的口令码	买家路由
9 界面美化	完善商品卡片、状态徽章、表单分组、必填提示和口令码卡片样式	买家页面、后台发布表单、样式文件
10 模块自测	编写18个自动化测试步骤，检查发布字段、重复发布、图片上传、匿名浏览、意向必填和同号重复提交	模块测试脚本

界面展示

以下为2026-10-08在本地独立演示环境中截取的实际页面，使用演示商品和测试买家信息。商品未上传图片，灰色区域为系统默认占位图。

1. 买家商品页：在售状态

商品卡片集中展示图片、名称、描述和价格，状态徽章提示“可购买”。购买意向表单按买家信息分组，姓名和联系电话明确标为必填。

2. 意向提交成功页

提交成功后，用醒目的卡片展示公共服务返回的口令码，并提示买家保存。我负责提交路由接入及卡片样式完善；口令码生成与撤销逻辑由周到负责。

3. 卖家后台发布表单

发布表单分为“基本信息”“商品图片”“定价”三个区域，突出名称与价格的必填标记，并说明图片格式、大小限制和缺省占位图规则。此图展示我完善的发布表单区域。

协作分工说明

我在发布和意向提交入口检查商品状态，并让页面提示与服务端限制保持一致。状态机架构设计和公共骨架由胡成溯负责；口令码生成、排队、撤销、冻结和失败递补等核心服务由周到负责。我负责调用公共服务、处理表单和完善页面展示。

同一电话号码重复提交时，我的路由按需求不去重，每次调用公共服务创建独立意向，展示各次返回的口令码。口令码生成算法属于公共服务的工作内容。

二、技术问题与解决方法

1. 图片后缀不能证明文件内容

问题： 文本文件也可以改成 .png，只检查扩展名会接受伪造后缀的文件；同时还要处理超大文件、空文件和未上传图片的情况。

处理方法： 我在商品发布路由中，按空文件、大小、扩展名和文件头的顺序进行检查。接受的扩展名为 .jpg、.jpeg、.png，并要求文件头与对应格式匹配。大小上限在代码中是 5 × 1024 × 1024 字节，页面提示为5MB。

校验失败时返回具体错误提示，不保存上传文件；通过后生成文件名并保存。未上传图片时使用默认占位图。测试脚本中对应了伪造PNG后缀、超限文件、空文件、PNG头匹配的字节流和占位图等场景。

当前检查依据文件头特征，并未增加完整图片解码验证；文件头匹配不能保证整张图片都能正常解码。

2. 冻结状态需要同时落实到页面和提交入口

问题： 买家能够查看商品，并不代表当前仍能提交购买意向。页面需要说明状态，服务端也需要在收到请求时检查状态。

处理方法： 买家浏览页读取当前商品，并根据状态展示“可购买”或“商品交易中”。提交接口再次读取商品：没有商品时返回提示，冻结时拒绝新增意向，姓名或电话缺失时返回必填提示。

通过这些检查后，调用公共服务 create_intent 创建意向，再把返回的口令码传给模板展示。这里我的工作是入口检查和服务接入，排队与后续状态流转由公共服务完成。

三、我的收获

这次实践让我学会把需求落实到接口和页面中：既要让正常操作顺利完成，也要处理错误输入和商品状态变化，并给用户清楚的提示。

通过图片校验和模块测试，我认识到不能只看功能能否运行，还要检查异常和边界情况。

与组员配合时，我也更清楚了自己的职责，以及怎样通过公共服务把各个模块连接起来。

四、教师点评与后续改进

评审后按实际记录填写，并同步到第1次阶段性评审报告对应任务的“教师评审意见”列。

教师点评	对应任务或问题	后续改进行动	完成与验证记录
待评审后填写	—	—	—

返回项目 Wiki 首页