商城商家认证

01 / BACKGROUND

项目背景

商家认证流程同时涉及用户身份、历史订单、公司信息、手机号、身份证号以及外部系统核验。不同身份拥有不同申请资格，部分用户需要满足单笔购买数量门槛；提交后还要处理重复申请、退款订单、跨公司重复手机号、身份证号唯一性和外部接口多种回参。原有规则分散在多个页面和沟通记录中，用户端、管理端和接口容易出现口径不一致，开发与测试也难以覆盖所有组合场景。

02 / MY ROLE

我的职责

梳理销售、合伙达人、高级达人、绑定用户、店员和散户等身份的申请资格，明确哪些身份可直接申请、哪些身份必须满足单笔购买门槛；设计姓名、身份证号、手机号和公司信息的填写与唯一性校验规则；统一已支付、退款中和全额退款订单的统计口径；定义用户端提交后的只读规则、管理端可编辑范围和认证状态；拆解外部核验接口的入参、匹配顺序、五类回参及状态更新动作；补充重复提交、部分匹配、多记录命中和异常返回等测试场景，并参与测试用例评审、联调和上线验收。

03 / CORE PROBLEMS

核心问题

第一，多种基础身份和附加身份可能同时存在，资格判断顺序容易冲突；第二，绑定用户和店员需要满足单笔购买数量门槛，而销售、合伙达人和高级达人无需该条件，规则必须清晰区分；第三，手机号和身份证号涉及全局唯一性，公司名称与手机号又存在跨公司可重复、同公司不可重复的组合约束；第四，订单统计只应包含已支付成功且未全额退款的记录，申请退款中的订单不能误计入；第五，外部系统核验可能出现未匹配、部分匹配、已验证、重复记录等多种结果，如果缺少统一状态矩阵，接口与后台处理容易不一致。

04 / SOLUTION

解决方案

将认证流程拆分为资格判断、表单校验、订单统计、提交去重、后台处理和接口核验六个独立模块。先按身份优先级确定是否展示入口，再针对需要购买门槛的身份校验单笔已支付订单数量；提交时分别校验身份证号全局唯一、手机号唯一及公司名称与手机号组合唯一。管理端统一维护申请状态和可编辑信息，外部核验接口只处理未验证记录，并按照公司名称与身份证号的匹配结果返回明确状态。通过状态矩阵把每一种输入、匹配结果和后续动作逐项对应，确保用户端、管理端、接口和测试用例使用同一套规则。

05 / PROCESS & RULES

关键流程或业务规则

06 / RESULT & REVIEW

项目结果与复盘

形成了从申请入口、资格判断、表单提交、后台处理到外部核验的完整业务闭环。多身份、订单门槛、重复校验和接口回参均被拆解为明确规则，便于开发直接实现，也能让测试人员按状态矩阵覆盖主要正常与异常场景。用户端、管理端和接口之间的字段、状态和提示口径得到统一，降低了复杂组合规则被遗漏或自由解释的风险。

复盘这类需求的难点不在页面数量，而在身份、订单、唯一性和核验状态之间的组合关系。相比把所有条件写成一段长说明，更有效的方法是先拆分业务对象，再分别建立资格表、校验表和状态矩阵。同时，接口规则必须明确“查询什么、匹配什么、更新哪一条、异常时如何返回”，否则即使页面设计清楚，跨系统联调仍然容易出现分歧。