先说结论平台型商城与自营商城的工程分水岭不在商品表多一个商家字段而在三套结构能不能立住商家主体核验档案模型 周期性核验任务 资质失效自动冻结、交易规则版本与公示状态机规则改动可追溯、可公示、可回滚、评价留痕与数据留存不可删除的评价模型 分级留存策略 报送导出。这三块决定平台在监管核验、纠纷仲裁、历史回溯三类场景下能不能拿出证据。这篇按这三段拆实现要点四节给出模块划分速查。一、商家主体核验档案模型与到期任务配图位 · 图 5商家主体核验与到期任务structure档案模型 / 核验周期 / 失效处置 / 类目资质映射四组图注图 5商家核验侧的模块划分——档案、周期任务、失效冻结、类目映射1. 档案模型商家主体档案建议单独建表与业务表解耦字段至少覆盖主体名称、统一社会信用代码、法定代表人、实际经营地址、联系方式、类目许可证类型与编号、证照影像文件、核验人、核验时间戳、核验版本号。证照影像是敏感材料存储层加密读取动作写审计日志接口层按角色脱敏返回。2. 周期性核验任务核验不是一次性的按要求核验、登记并建立登记档案每 6 个月核验更新一次。工程上落成一张核验任务表商家 ID、上次核验时间、下次核验日、当前状态配一个日跑的定时任务到期前 30 天进入临期状态给商家与运营双通道提醒到期未核验进入限制状态平台上新与提现受限核验完成后写回时间戳并递增版本号历史核验记录保留。任务必须幂等可重跑——漏跑一天就等于一批商家超期所以任务执行结果要写运行日志并对连续失败告警。3. 资质失效处置许可证要单独建有效期字段与状态机有效 / 临期 / 已失效 / 被吊销。失效即冻结商家经营权限并下架在售商品这是平台核验义务的落点。冻结动作要记录触发依据哪份证照、什么时间判定失效与执行人便于事后说明。4. 类目—资质映射类目表与许可证类型做多对多映射作为上架前置校验的依据商家发布某一品类商品时系统检查其是否持有对应有效许可证缺失直接拒绝上架。映射表放后台可维护新增类目时强制要求配置资质项避免新类目默认可卖。5. 未登记商家的动态监测对于未办理市场主体登记的商家按周期统计其经营额超过规定额度的进入提醒队列提示其依法办理登记。这条对个人卖家较多的平台尤其需要——人工盯不现实必须用统计任务兜。二、交易规则版本与公示状态机配图位 · 图 6交易规则版本与公示状态机flow草稿→公示中→待生效→生效→归档图注图 6规则版本流转——公示期不可提前生效历史版本可查可下载1. 规则建模每一条平台服务协议与交易规则单独建模一条记录带版本号、正文含加粗等显著提示标记、公示起始时间、计划生效时间、实际生效时间、状态、发起人。不要把规则写成前端硬编码文案——一旦硬编码公示与留存都无从谈起。2. 状态流转草稿 → 公示中 → 待生效 → 生效 → 已归档。关键约束两条公示期内不允许提前生效这个约束要在服务端校验不能只靠后台按钮置灰生效时间必须由公示起始时间推算公示期不足不允许提交生效一般规则实施前 7 日公示。3. 历史版本留存保留修改后版本生效之日前 3 年的历史版本并对外提供查阅与下载入口。实现上是版本表追加写不做物理更新下载走鉴权后的文件服务下载行为写日志。4. 商家退出路径不接受新版规则的商家要有退出流程发起退出 → 下架商品 → 冻结权限 → 结算清零 → 档案转入归档库。退出后按修改前的协议与规则承担相应责任的边界写入商家的电子档案避免后续争议时口径不一致。5. 被禁止的规则形态默认勾选同意、限制商家退出、单方最终解释权、不合理违约金、在会员服务期内单方面减损权益——这几类在设计注册与协议流程时就要从产品层拦掉不要等到合规评审再改。三、评价留痕、工单与数据留存配图位 · 图 7评价留痕与数据留存双通道compare前场评价工单通道 vs 后场留存报送通道图注图 7前场做留痕与工单后场做分级留存与报送导出前场 · 评价与工单通道评价表只增不改不删在数据库层面收回对评价表的 UPDATE / DELETE 权限业务侧只允许 INSERT。这一条必须落在表结构或账号权限上放在业务逻辑层迟早会被后人改掉违规内容隐藏留档涉及辱骂、违法信息的评价走隐藏并留档记录操作人、时间、理由与依据前台不可见但不物理删除不做诱导好评返现、好评返券这类活动不在下单链路做自动触发运营侧也不提供批量干预评价的工具投诉与申诉工单消费者投诉与商家申诉共用一套工单内核提交 → 受理 → 处理 → 申诉 → 升级全流程留痕、时限计时人工判定入口独立于自动审核当申请人要求人工判定时链路可直接转人工。后场 · 留存与报送通道分级留存策略商家身份信息自其退出之日起保留不少于 3 年商品与服务信息、支付记录、物流快递、退换货与售后信息自交易完成之日起保留不少于 3 年。留存策略写在数据字典里作为建表规范的一部分冷热分离近线库承载近期热数据归档库承载历史数据归档任务做条数与摘要比对校验防止静默丢数据报送导出把报送所需字段做成固定模板主体名称、统一社会信用代码、实际经营地址、联系方式、店铺名称与链接等按周期一键导出导出动作与操作人留痕权限与脱敏分级权限模型平台 / 运营 / 客服 / 商家 敏感字段脱敏展示 全量操作日志谁改了商家资质、谁隐藏了评价必须可追溯到人。四、模块划分速查模块核心职责关键约束商家档案主体信息、证照材料、核验版本影像加密存储读取留痕核验任务周期核验、临期提醒、到期限制幂等可重跑漏跑告警资质状态机证照有效期与失效冻结失效即停服并落审计记录类目映射类目与许可证多对多校验新类目强制配资质项规则版本协议与规则的版本、公示、生效公示期服务端强校验不可提前生效版本归档历史版本留存与下载追加写不覆盖下载鉴权评价中心评价写入、违规隐藏留档表级禁改禁删隐藏留依据工单内核投诉、申诉、人工判定全流程留痕人工入口独立留存归档冷热分离与校验策略写进数据字典归档校验比对报送导出周期报送模板与导出导出留痕字段对齐监管口径权限审计分级权限、脱敏、操作日志敏感操作可定位到人小结平台型商城的合规工程量集中在三件事上把商家核验做成档案模型加周期任务而不是一次性的上传审核把交易规则做成可版本化、可公示、可归档的对象而不是前端的几段文案把评价与交易数据按只增不删 分级留存落成数据层约束而不是靠业务代码自觉。这三块在架构期定稳后续加类目、加渠道、加商家都只是配置级变更定不稳任何一次资质过期未冻结、规则改动无留痕、评价被删在核验或纠纷场景下都拿不出证据。附图三张按核验模块、规则流转、评价与留存双通道分别给出结构参考。
