商城商家认证

01 / BACKGROUND

项目背景

商家认证流程同时涉及用户身份、历史订单、公司信息、手机号、身份证号以及外部系统核验。不同身份拥有不同的申请资格：部分身份可以直接申请，部分身份必须满足指定的单笔购买数量门槛。提交过程中还需要处理重复申请、退款订单、跨公司手机号关系、身份证号唯一性以及外部接口的多种匹配结果。如果这些规则分散在页面说明、口头沟通和接口约定中，就很容易出现用户端、管理端和接口之间口径不一致，开发实现依赖个人理解，测试也难以完整覆盖组合场景。因此项目的核心不是单纯增加一个认证表单，而是把身份、订单、唯一性和核验状态整理成一套可执行、可验证、可追溯的统一规则。

02 / MY ROLE

我的职责

梳理销售、合伙达人、高级达人、绑定用户、店员和散户等身份的申请资格，明确哪些身份可直接申请、哪些身份需要满足单笔购买数量门槛；统一订单统计口径，仅纳入已支付成功且未全额退款的有效订单，并明确退款中的订单如何处理；设计姓名、身份证号、手机号、公司信息等表单字段及唯一性校验规则，区分身份证号全局唯一、手机号规则以及公司名称与手机号组合约束；定义用户端提交后的只读范围、管理端允许编辑的字段和认证状态；拆解外部核验接口的入参、匹配顺序、五类回参、未验证记录处理及状态更新动作；补充重复提交、部分匹配、多记录命中、退款订单、异常返回和接口失败等测试场景，并参与交互评审、联调和上线验收。

03 / CORE PROBLEMS

核心问题

第一，多种基础身份和附加身份可能同时存在，资格判断如果没有明确优先级，容易出现入口展示和申请条件冲突；第二，绑定用户和店员需要满足单笔购买数量门槛，而销售、合伙达人和高级达人无需该条件，必须明确不同身份的适用规则；第三，手机号、身份证号和公司信息存在不同层级的唯一性约束，既有全局唯一，也有跨公司可重复、同公司不可重复的组合关系；第四，订单统计不能简单按下单记录计算，只能纳入已支付成功且未全额退款的有效订单，退款中的状态也需要统一口径；第五，外部系统核验可能出现未匹配、部分匹配、已验证、重复记录等多种结果，如果没有状态矩阵，接口返回、后台状态和后续动作容易不一致；第六，重复提交、多记录命中和异常回参都必须有明确处理方式，否则认证状态可能出现不可解释的中间状态。

04 / SOLUTION

解决方案

将认证流程拆分为资格判断、订单门槛、表单校验、提交去重、后台处理和接口核验六个模块。首先按照用户身份与规则优先级判断是否展示认证入口，再对需要购买门槛的身份校验单笔已支付且未全额退款订单；提交时分别处理身份证号、手机号以及公司名称与手机号组合的唯一性校验，防止重复或冲突数据进入系统；用户提交后锁定关键认证信息，管理端仅保留业务所需的编辑范围，并统一维护认证状态；外部核验接口只处理符合条件的未验证记录，根据公司名称与身份证号的匹配结果返回明确状态，并按既定规则更新对应数据。通过资格表、校验表和状态矩阵，把每一种输入条件、匹配结果和后续动作逐项对应，使用户端、管理端、接口和测试用例共用同一套规则。

05 / PROCESS & RULES

关键流程或业务规则

06 / RESULT & REVIEW

项目结果与复盘

形成了从认证入口、资格判断、订单门槛、表单提交、后台处理到外部系统核验的完整业务闭环。原本分散的多身份规则、订单统计、唯一性约束和接口回参被拆解为明确的资格表、校验规则和状态矩阵，使开发能够按照统一规则实现，测试也可以直接围绕身份组合、订单状态、重复数据和接口结果建立用例。用户端、管理端与外部接口之间的字段、状态和提示口径得到统一，降低了复杂组合规则被遗漏、误解或自由解释的风险，也提升了后续联调、异常排查和规则维护的效率。

复盘这个项目进一步说明，复杂业务的难点往往不在页面，而在规则之间的组合关系。身份、订单、唯一性和核验状态一旦相互依赖，仅靠长篇文字说明很难保证所有角色理解一致。更有效的方法是先拆分业务对象，再分别建立资格表、校验表和状态矩阵，把每个条件对应到明确的结果与动作。对于跨系统接口，还必须明确“查询什么、如何匹配、更新哪条记录、异常时返回什么”，否则即使页面方案清晰，联调阶段仍然容易出现接口与后台状态不一致的问题。