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