重复访客资料合并与编号处理建议规则｜正式启用前由 Super Admin 确认
V15 新增
只有在确认多个 G 编号确实属于同一个人后，才可以进行资料合并。发现疑似重复，不代表可以立即合并。
01暂停相关转正申请避免重复建立 M 编号或错误关联网站账号。
02核实是否同一人检查昵称、活动记录、管理员核实资料及其他可用证据；不能只凭昵称相同判断。
03由 Super Admin 确定主要 G 编号根据资料完整度、历史记录及实际情况综合判断，不以建立日期作为固定优先条件。
04保留其他 G 编号其他编号转为该身份的历史/别名编号，永久保留，不再分配给别人。
05合并历史资料活动、积分、赠品及相关记录归入同一社群身份；原始记录和来源编号仍可追溯，不重复累计。
06审核并记录操作记录合并前后编号、原因、证据摘要、操作人、批准人及时间。
编号示例（假设已确认是同一人；主要编号由 Super Admin 决定）
主要编号G0003保留为主要身份
＋
重复编号G0012转为历史编号
→
合并后身份G0003一份社群身份资料
未来转为正式会员时，由 Super Admin 确定主要 G 编号后，再办理正式转正并分配一个 M 编号；其他 G 编号均保留为历史编号，所有历史记录继续可追溯。
禁止事项
- 不得仅凭昵称相同就合并。
- 不得默认以最早建立的 G 编号作为主要编号；由 Super Admin 根据资料完整度、历史记录及实际情况决定。
- 不得删除或重新使用任何已分配的 G 编号。
- 不得直接相加重复的积分记录；须先识别重复交易/活动记录，避免重复计算。
- 不得在身份尚未确认时，把两个不同人的资料合并。
- 涉及正式身份合并及重要关联修正，须由 Super Admin 最终批准。
身份合并后的历史记录与重复数据处理合并身份，不等于删除或直接合并所有交易记录
V17 新增
核心原则
先确认记录属于同一人，再逐类核对记录。保留原始记录及来源，不因身份合并而重复累计；任何财务或库存流水不得直接删除或改写来掩盖重复。
| 记录类别 | 处理方式 | 重复记录处理 |
|---|
| 活动记录 | 归入同一社群身份，保留原活动、报名、出席及取消资料。 | 同一人同一活动若出现重复报名记录，先核实哪条为有效记录；不把一次出席算成两次。 |
| 积分记录 | 保留每笔积分变动的来源、规则、时间及操作人。 | 按已核实的唯一活动及有效付款/出席结果计算；重复积分流水标记待核查，不重复累计。 |
| 付款与退款 | 保留每笔收款、退款、付款凭证及对应活动。 | 同一笔付款若在两份资料中重复出现，只能确认一次实际收款；无法确认时标记待核查，不自行冲销。 |
| 财务流水 | 保留原始账目、账户、凭证及审计轨迹。 | 不得因会员身份合并而删除或直接合并账目；疑似重复交易须按财务更正流程处理并留下关联记录。 |
| 赠品与库存 | 保留领取人、物品、数量、日期、活动及库存流水。 | 同一领取事件重复登记时先核对实际发放数量；不得重复扣库存，也不得把两次真实领取误判为重复。 |
| 纪律与内部备注 | 按原权限保留记录、补充内容、创建人及时间。 | 不因身份合并而删除、覆盖或向无权限管理员开放。 |
建议核对顺序
1 确认身份与主要编号
→
2 按记录类别比对来源
→
3 标记疑似重复，不直接删除
→
4 授权审核并完成更正
重要限制
身份合并只统一记录归属，不代表可以自动改变历史活动结算、实际收付款、库存数量或已完成的财务账目。需要更正时，应通过对应模块的正式更正/冲正流程，并保留原记录及审计日志。
重复身份合并审批机制明确申请、核实、批准、执行及撤销权限
V18 新增
01提出申请获授权管理员提交疑似重复身份合并申请，附上相关 G 编号及原因。
→
02资料核实核对身份依据、活动记录、积分、付款及其他相关资料。
→
03Super Admin 审批审查合并依据、主要编号及影响范围；申请人不得审批自己的申请。
→
04授权执行批准后由获授权人员执行，系统记录合并前后资料及审计日志。
可提出申请Super Admin 或获授权处理会员身份资料的管理员。普通会员及访客不能直接合并身份。
负责核实获授权管理员可以整理证据与核对记录；核实人员应与审批人员区分。
最终批准仅 Super Admin 可以批准正式身份合并，并决定主要 G 编号及处理方案。
执行合并由获授权管理员或 Super Admin 执行；执行权限与批准权限分开管理。
审批限制
- 申请人不得审批自己的合并申请。
- 审批前，所有原有 G 编号、账号关联及历史记录保持不变。
- 批准内容必须明确列出涉及的 G 编号、主要编号、历史编号及记录处理范围。
- 如证据不足或身份无法确认，申请应退回补充资料或驳回，不得先合并后核实。
- 所有申请、核实、批准、执行及拒绝操作均须保留操作人、时间和原因。
合并后能否撤销？允许申请更正，不提供直接一键回滚
若合并后发现身份判断错误，必须提交「身份合并更正／拆分申请」，说明错误原因、涉及记录及恢复方案，再由 Super Admin 审批。不得直接删除合并记录或覆盖原始历史。
待审核：维持原状
已批准：按方案更正
已驳回：维持现状
建议将「身份合并」与「合并后更正／拆分」作为两种独立的高风险操作权限。即使管理员有提出申请或执行权限，也不能因此获得最终批准权。
会员状态与生命周期管理正常、非活跃、冻结、已退出、已封禁、无网站账号六种状态及相关管理流程
V20 新增
会员主动退出
会员提交退出申请，管理员审核。审核通过前，会员状态及登录权限保持不变。
批准后：社群身份状态设为「已退出」，网站账号暂停登录；历史资料保留。
冻结会员
由有权限的管理员执行，可设定固定期限或无限期，并记录冻结原因及生效时间。
冻结期间：不能报名或参与活动，但仍可登录查看个人历史、冻结原因及通知。
封禁会员
对应会员资格终止及网站账号封禁，属于高风险操作，必须经 Super Admin 最终批准，申请人不得审批自己的申请。
批准后：会员状态设为「已封禁」，网站账号禁止登录；历史资料永久保留。
重新加入
已退出会员可申请恢复原身份；已封禁会员必须经过 Super Admin 特别审批。
批准后恢复原 M 编号及历史记录，不创建新的会员身份。
不同状态的权限影响区分社群参与资格与网站登录权限
| 会员状态 | 网站登录 | 报名／参与活动 | 说明 |
|---|
| 正常 | 允许 | 允许 | 正式会员，正常使用社群功能 |
| 非活跃 | 允许 | 按活动规则 | 会员仍保留身份；非活跃不等于冻结 |
| 冻结 | 允许 | 禁止 | 暂时不能报名或参与活动；可查看个人历史、冻结原因及通知 |
| 已退出 | 禁止 | 禁止 | 退出申请获批后生效；保留原身份及历史记录 |
| 已封禁 | 禁止 | 禁止 | 会员资格终止并封禁网站账号；恢复须 Super Admin 特别审批 |
| 无网站账号 | 不适用 | 按访客／社群身份规则 | 尚未建立网站登录账号，不代表没有社群身份 |
重新加入处理
会员提交申请→管理员核实原身份→依退出／终止类别审批→恢复原 M 编号及权限
已退出会员：按一般重新加入审批流程处理。已封禁会员：必须由 Super Admin 特别审批。审批完成前，原状态不变。
管理及审计要求
- 冻结、退出、封禁及重新加入均须记录原因、申请人／操作人、审批人、生效时间及相关通知。
- 冻结可设定到期日或无限期；管理员可在到期前提前恢复。固定期限到期后的状态恢复应按已批准规则执行并留下记录。
- 会员主动退出申请获批前，不提前停用账号；获批后会员状态设为「已退出」，网站账号禁止登录。
- 将会员设为「已封禁」及恢复已封禁会员身份，均属于高风险操作，必须由 Super Admin 最终批准。
- 重新加入恢复原身份、M 编号及历史记录，不重置积分、不复制活动记录、不创建新会员身份。
- 所有历史申请及审批记录保留，不因恢复会员资格而删除先前退出或终止记录。
会员颜色（绿／黄／红）及正式警告与冻结、退出、封禁独立管理。颜色或警告不会自动触发停权。
六种会员状态：后台权限与处理边界区分会员可使用的功能，以及管理员可以执行的管理动作
V22 新增
| 会员状态 | 会员端权限 | 管理员处理边界 |
|---|
| 正常 | 可登录、查看个人资料及历史，并按活动规则报名。 | 按既有模块权限管理资料、活动及会员事务。 |
| 非活跃 | 可登录及查看个人资料；活动报名依活动规则及社群安排。 | 连续达到管理员设定的期限（3、6 或 12 个月）仍没有实际参加任何社群活动时，系统自动标记为非活跃；再次实际参加活动后，系统自动恢复正常。不得自动冻结或封禁。 |
| 冻结 | 可登录；可查看个人历史、冻结原因及通知；不能报名或参与活动。 | 获授权管理员可按权限发起／处理冻结；记录原因、期限及操作人。提前恢复或到期处理须留痕。 |
| 已退出 | 不能登录或参与活动；历史资料继续保留。 | 可按权限查看必要历史资料及处理重新加入申请；获批恢复后沿用原 M 编号。 |
| 已封禁 | 不能登录或参与活动；历史资料继续保留。 | 封禁及恢复均属高风险操作，必须由 Super Admin 最终批准；普通管理员不得自行解除。 |
| 无网站账号 | 没有网站登录权限；不代表没有社群身份或活动历史。 | 获授权管理员可代访客处理活动报名及维护访客资料；账号关联须先核实身份，不得自动建立重复身份。 |
管理员权限仍按原有四层授权执行
模块／页面→字段→具体操作→高风险审批
会员状态不会自动赋予管理员额外权限。管理员只能查看及操作其获授权的内容；前端隐藏按钮不构成安全边界，数据库 RLS 仍须阻止越权访问。
必须保持的边界
- 冻结不是禁止登录；冻结期间仍可登录，但不能报名或参与活动。
- 非活跃不是冻结；不得把非活跃自动转换为冻结、已退出或已封禁。
- 已退出与已封禁都禁止登录，但两者原因及重新加入审批级别不同。
- 无网站账号只代表没有登录账号；访客仍可有 G 编号、活动记录及积分。
- 管理员查看纪律记录、内部备注及敏感资料，仍须遵守逐项授权，不因会员状态改变而扩大权限。
非活跃期限设置允许日后按社群实际情况调整，不需要修改系统程序
可配置设置
目前默认设置12 个月
可选期限3 个月 ／ 6 个月 ／ 12 个月
谁可以更改？
建议由 Super Admin 或获授权管理「系统设置」的管理员更改。没有相关权限的管理员只能查看，不能修改。
更改设置后的计算方式
系统按会员最后一次实际参加社群活动的日期重新计算。若期限缩短，已经超过新期限的会员可能立即被标记为非活跃；若期限延长，尚未达到新期限的会员继续保持原状态，系统按新期限判断。更改设置不会重置会员的最后参加日期。
设置变更记录
每次更改须记录旧期限、新期限、修改人、生效时间及修改原因；建议变更前显示影响会员人数，并要求管理员确认后才生效。
非活跃状态自动判定规则
判定期限管理员可设 3／6／12 个月
判定条件没有实际参加任何社群活动
状态更新系统自动标记「非活跃」
恢复条件再次实际参加任何社群活动
系统以最后一次实际出席／参与记录作为计算依据。仅登录网站、浏览资料或报名但未实际参加，不会重置 12 个月期限。自动变更及恢复均须写入审计记录。
冻结期限与恢复规则明确冻结的有效期限、到期处理方式及提前解除权限
待确认规则
必须保留的限制
- 冻结期间会员仍可登录及查看个人历史、冻结原因和通知，但不能报名或参与活动。
- 非活跃会员不会自动转为冻结；冻结到期也不得直接转为已退出或已封禁。
- 恢复后状态为「正常」；若要终止会员资格或封禁账号，必须走独立审批流程。
- 所有冻结、延期、提前恢复及到期处理均写入不可覆盖的审计记录。
会员冻结操作流程规范冻结申请、执行、通知及延期处理
流程待确认
建议操作流程
- 具备「冻结会员」权限的管理员进入会员详情，发起冻结操作。
- 填写冻结原因、冻结开始时间及到期时间；原因和到期时间为必填。
- 系统显示冻结影响：会员将无法报名或参与活动，但仍可登录及查看个人历史、冻结原因和通知。
- 确认执行后，会员状态变更为「冻结」，并记录操作人、时间、原因及到期时间。
- 系统按设定的到期时间自动恢复为「正常」，并记录自动恢复时间及系统执行记录。
流程边界
- 冻结期间不得报名或参与活动，但不禁止网站登录。
- 冻结到期自动恢复为「正常」；系统不得自动转为「已退出」或「已封禁」。
- 如果会员在冻结期间提出退出申请，应按独立的退出审批流程处理；冻结到期自动恢复不得覆盖已经批准的其他状态变更。
- 所有冻结、延期、取消及自动恢复记录均须保留，不能直接删除或覆盖。
会员主动退出流程会员申请退出、审核批准及日后重新加入
规则已确认
已确认的退出流程
- 会员提交主动退出申请，并填写退出原因（可按实际情况设为必填）。
- 申请进入待审核状态；审核完成前，会员原有状态及权限维持不变。
- 由具备退出审批权限的授权管理员或 Super Admin 审核并作出最终批准。
- 批准后，会员状态变更为「已退出」，网站账号禁止登录，不能报名或参与活动。
- 保留原 M 编号、身份资料、活动、积分、付款、纪律及其他历史记录。
- 会员日后获准重新加入时，恢复原来的 M 编号及原社群身份，不建立新的会员身份。
退出记录要求
- 保留申请时间、申请原因、审核结果、批准人、批准时间及生效时间。
- 重新加入时新增恢复记录，不删除或覆盖过去的退出记录。
- 退出期间不得登录或参与活动；重新加入获批后，按恢复后的正常会员权限处理。
会员封禁流程封禁申请、Super Admin 最终审批及不可恢复规则
规则已确认
已确认的封禁流程
- 具备封禁发起权限的授权管理员或 Super Admin 提交封禁申请。
- 填写封禁原因及相关证据／附件；申请进入待 Super Admin 审批状态。
- Super Admin 作出最终批准或拒绝；申请人不得审批自己的申请。
- 批准前，会员原状态及权限不变；批准后状态变更为「已封禁」。
- 封禁生效后，网站账号立即禁止登录，会员不得报名或参与活动。
- 已封禁会员不允许提交恢复申请；不得通过普通会员状态操作解除封禁。
封禁记录与身份保留
- 保留封禁原因、证据、发起人、Super Admin 审批结果及时间。
- 原社群身份、M 编号及所有历史资料永久保留，不删除、不重新分配编号。
- 封禁与「已退出」是不同状态，不得混用；封禁不允许申请恢复。
- 封禁批准属于高风险操作，必须有完整审计记录。
会员状态转换与身份保护规则处理冻结期间退出、退出后重新加入，以及封禁后的重复注册
规则已确认
1. 冻结中的会员申请退出
- 允许冻结中的会员提交主动退出申请。
- 退出申请审核期间，会员维持原「冻结」状态，不因提交申请而自动变更状态。
- 退出申请获批后，状态由「冻结」变更为「已退出」，并按退出规则禁止登录及参与活动。
- 若退出申请被拒绝或取消，会员继续维持原「冻结」状态，并按原冻结到期规则处理。
- 冻结到期自动恢复任务必须先检查是否已有获批的退出或其他有效状态变更，避免覆盖已批准结果。
2. 已退出会员重新加入
- 允许已退出会员重新申请加入；审核通过后恢复原来的 M 编号及原社群身份。
- 原有纪律记录、警告、活动、积分、付款、赠品领取及其他历史资料全部保留。
- 重新加入是新增一次身份恢复记录，不删除、不覆盖过去的退出记录及纪律历史。
- 重新加入后按现行会员规则恢复权限；既有纪律记录仍可供具备相应权限的人员查阅。
3. 已封禁会员重复注册防护
- 已封禁会员不允许通过更换 Email 重新注册或建立新的社群身份。
- 系统应以原社群身份及已核实的身份关联记录识别重复注册，不可只依赖 Email 判断是否为同一人。
- 发现疑似重复注册时，不自动创建新 M 编号、不自动关联身份，转入身份核验异常处理。
- 已封禁身份不得通过一般身份合并、重新注册或更换登录邮箱来绕过封禁。
- 封禁身份及相关审计记录永久保留；不提供恢复申请入口。
系统执行保护
- 所有状态转换须由后端验证当前状态、操作者权限及审批结果；前端按钮隐藏不能作为安全控制。
- 自动任务执行前须重新读取最新状态，避免过期任务覆盖管理员刚批准的状态变更。
- 状态变更记录须包含变更前状态、变更后状态、原因、操作者或系统任务、时间及关联审批记录。
会员管理模块 · 最终验收清单集中检查身份、状态、权限、审批及历史记录规则
待逐项验收
会员身份与账号
- 每个人只有一份唯一社群身份；网站账号只是登录凭证。
- 访客 G 编号与正式会员 M 编号独立编号；G 转 M 时保留历史编号。
- 已退出会员重新加入时恢复原 M 编号；已封禁身份不得通过更换 Email 重新注册。
- 同一网站账号不可关联多个社群身份，同一社群身份不可关联多个网站账号。
六种会员状态
- 正常：允许登录及按规则报名活动。
- 非活跃：允许登录；达到设定期限未实际参加活动时自动标记，再次实际参加后恢复正常。
- 冻结：允许登录及查看个人资料，但禁止报名和参与活动；到期自动恢复正常。
- 已退出：退出申请获批后生效；禁止登录及参与活动；允许重新加入并恢复原 M 编号。
- 已封禁：必须由 Super Admin 最终批准；禁止登录及参与活动；不允许申请恢复或更换 Email 重注册。
- 无网站账号：没有网站登录权限，但可以保留社群身份及历史记录。
审批与权限
- 退出：须审核；由具备相应审批权限的授权管理员或 Super Admin 最终批准。
- 封禁：授权管理员或 Super Admin 可发起；必须由 Super Admin 最终批准。
- 高风险审批不得由申请人审批自己；审批通过前原状态不变。
- 权限须由后端及数据库 RLS 强制执行，不能只依赖前端隐藏按钮。
历史记录与审计
- 身份合并、退出、重新加入、冻结、自动恢复及封禁记录均须保留。
- 纪律记录、警告、活动、积分、付款及赠品记录不得因状态转换而删除。
- 自动任务执行前须检查最新状态，避免覆盖已批准的状态变更。
- 审计记录应包含操作前后状态、原因、操作者／系统任务、时间及关联审批。
非活跃会员规则已确认：连续达到系统设置的非活跃期限仍没有参加任何社群活动，系统自动将会员状态标记为「非活跃」。判定依据为最后一次实际参加社群活动的日期，不以网站登录日期或单纯未报名作为依据。会员之后再次实际参加任何社群活动时，系统应自动将状态恢复为「正常」，并记录状态变更时间及触发活动。冻结到期处理细节及不同管理员角色可处理哪些状态变更，仍待确认。
V31 已将非活跃判定期限设计为可配置的 3、6 或 12 个月；默认 12 个月，修改权限及变更审计纳入设计；目前仍是 UI 流程原型，尚未连接注册申请队列、身份核验工具或真实账号关联。实际操作前必须确认账号尚未被其他社群身份使用。