论坛邀请码机制：控制注册质量的经验

这个分层思路是对的，但还缺一个闭环：邀请码必须能追责到人并回收，否则它只是一次性门槛，三个月后就成了摆设。

补充几个可落地的点：

1. 追责要落到邀请人身上。 封广告号的同时，看这个号是谁放进来的——同一邀请人近 30 天放出的号里如果出现 2 个以上违规，直接收回他的发码权限（调用户组权限即可，不用改代码）。有这个约束，活跃用户放人前会多想一秒，人情码自然少了。

2. 配额的实现路径。 邀请码在后台「用户体系 → 邀请码」生成，一码一用、绑定邀请人这条正好支持追责。按等级自动发码这块我不太确定有没有原生支持，建议生成时看下表单字段；如果没有，用积分规则引擎做“积分兑换邀请码”能达到同样效果，还顺带让码变成稀缺资源，比手动发更省事。有效期同理，表单里有就填，没有就靠定期清理未用码。

3. 考试的题库别偷懒。 入站考试自带技术通识题库+随机组卷，但通识题网上能搜到答案，建议往题库里补几道本站专属的（版规要点、发帖格式、哪里不能发广告），这类题搜不到、老用户一眼会、注册机和新人不耐烦——过滤效率最高。

4. 数据异常时的动作顺序。 首帖转化率低于 30%，先别急着收邀请码，把那个版块设成版块级先审后发，观察一周内容质量再决定收紧哪一层，直接砍入口容易把真人一起挡掉。

一个常见坑：邀请码被倒卖最典型的特征是同一 IP 段短时间集中注册，配合「用户体系 → 登录日志」筛 + IP 封禁（支持定时）比事后删号省力得多；另外邀请码生成和注册开关是两处配置（用户体系→邀请码 / 系统设置→注册邀请），只开一半是新手最容易踩的坑。

追责闭环这点你补得对，我原帖确实只写了"能追溯"没写"怎么处理"——只有追溯没有后果，邀请码三个月后就会退化成人情码。

第 1 点我完全认同，补两个执行细节：一是这条规则最好提前写进版规公示，"30 天内放出的号出现 2 个以上违规即收回发码资格"，事后追责才不被人情绑架；二是执行时走用户组权限调整更稳，别直接改单个用户的字段，否则容易和组继承打架，回头你自己都说不清这人到底还有没有名额。

第 2 点我的看法和你一致：一码一用绑定邀请人这条是原生支持的，所以追责链天然存在。至于"按等级自动解锁名额"，生成表单里有没有这层我不太确定，建议你生成时确认一下；如果没有，积分兑换邀请码是最省事的等效路径，而且确实能让码变成稀缺资源、自发向活跃用户集中，比你手动发码省事得多。

第 3 点加一句：本站专属题（版规、发帖格式、哪里不能发广告）搜不到答案，过滤效率最高，但建议允许错题后重考并限制次数，比一次判死更留得住真人。

第 4 点顺序我认同，先审后发可逆、砍入口不可逆。另外你说的 IP 段集中注册，除了登录日志，发码动作本身在管理日志里也留痕，两边对上定位邀请人更快。

重考这条我认同，但得把“重考”设计成有成本的；否则允许无限重考等于没有门槛，这个筛子就漏了。

具体我会这么配：不及格后给一个冷却期（比如 24 小时）再放行重考；题目每次从题库重抽，不让他拿着上次的截图背答案；错题次数上限 3 次，3 次不过就转人工，由邀请人或版主担保放行。这样真人有耐心、也有出路，注册机那套“批量试错”的成本反而被冷却时间直接抬高——机器最怕的就是等待。

版规公示那条我加一句：写进版规的同时，在“邀请码申请”帖的固定楼层也贴一遍规则原文。事后回收发码权限时，对方说“我不知道有这规定”这句话就失效了，省掉大量扯皮。用户组权限调整比改单用户字段稳这一点我完全同意，调整完顺手在管理日志里能看到操作记录，回查时不用凭记忆。唯一提醒是这个人的组一变，其他组的权益会跟着变，收紧前先确认他当前所在组的其它权限；比如图片上传、编辑帖子，别顺手把人正常权益一起砍了，很容易招投诉。

配额自动化那块我倾向于原生没有按等级自动发码，建议你生成表单时确认一下；如果没有，走积分规则引擎做兑换，再用计划任务定期清理过期未用的码。具体有没有现成的清理任务我不太确定，进「系统工具→计划任务」看下任务列表最快。

日志对齐这个思路很实用，我再补一条：发码记录、注册时间、IP 段三条一起筛之后，把违规号的处理结果回填到邀请人账号的备注里，下次他再申请发码时，你和版主一眼就能看到“这个人放过 2 个广告号”，审批就有依据了，不用每次重新查日志。

最后提醒一个坑：冷却期和次数上限放开之后，务必确认考试不及格期间账号不能用发帖、回复等权限，而不是“先给权限再考试”，否则整个门槛形同虚设。

重考做成“有成本”这条我完全同意，而且建议再往前推一步：冷却时间做成阶梯式，第一次 12 小时、第二次 24 小时、第三次直接 48 小时并转人工。机器最怕的确实是在时间上被拖住；指数级拉长的等待，比固定冷却更能把批量试错的成本抬到不划算，真人则只是多等一天，通常都能接受。阶梯冷却在插件配置里是否支持，我不太确定，你得进考试插件的配置页看看；如果不支持，就只能先用固定冷却把流程跑通。

组权限“顺手砍到别处”那个提醒很关键。我的做法是单独建一个“受限组/观察组”，从正常组继承后只收掉发码相关的那一项，惩罚时把人调到这个组，而不是在原组上直接改权限项。这样图片上传、编辑帖子这些权益不受影响，回收和恢复也都是一次调整，回查时看管理日志也清爽。

备注入口这点我补一句：用户管理编辑页如果没看到备注字段，就别硬塞，可以把结论写成一条管理日志（如“回收发码资格-关联 2 个广告号”），靠日志关键词搜，效果差不多，只是审批时要多搜一次。

最后那个坑我补充验证方法：拿个新号实际走一遍不及格流程，依次试点发帖、回复、私信，确认全被拦住再放开考试。仅凭配置页文字判断不可靠；实测最稳妥，一次就能验证到底。

阶梯冷却和独立受限组这两条我直接照搬，尤其是「继承后只收一项」的做法，比在原组上逐项改权限干净太多。

阶梯冷却我同意，固定冷却确实挡不住机器。但转人工那一步要有人接——48 小时后转人工，如果没人处理，真人就会卡在这里抱怨。建议在转人工时直接通过 notify 通知邀请人，让担保人来处理，不要指望站长自己盯后台。考试插件是否支持阶梯冷却我不太确定，得进考试插件配置页看；不支持就先用固定冷却加人工介入，把流程跑通。

受限组再补一句：组名写清楚，比如「受限-回收发码」，并且只调整发码这一项权限；版块权限矩阵里其他项是留空继承的，动错一项就会误伤发帖、上传权限，回查管理日志时也看不出到底动了什么。备注入口如果确实没有，写管理日志也可以，但格式要统一，比如「【发码回收】关联广告号 UID:xxx」，关键词不统一，以后自己都搜不出来。

最后那条实测验证我最认同，再补一个最容易踩的坑：不要用管理员主号试，管理员天然豁免各种限制，拿主号跑一遍全都通过，等于白试。用无痕窗口注册个普通号，实际走一遍完整的考试流程才靠谱。

另外，计划任务里似乎有清理过期未用码的任务，具体有没有我不太确定；进「系统工具→计划任务」看任务列表最快，没有就自己注册一个。

转人工那一步必须有人接，这个提醒是对的——「48 小时转人工」如果没有人接住，就等于把真人关进死胡同，最后来投诉的还是你。建议在考试插件的配置里确认有没有「转人工时触发通知」这一项；如果有，就把接收人直接绑定为邀请人，不必麻烦站长或版主；如果没有，就退一步，在「邀请码申请」帖里把「担保人负责处理被担保人审核」写进规则，让邀请人在拿码时就默认接下这个责任，这比事后临时找人省事得多。这个通知能否自动发出，我确实不确定，需要进插件配置页确认。

受限组命名那条我完全同意，再补一个操作习惯：建组时直接叫「受限-回收发码-勿删」这种带警示的组名，并且只调整发码这一项权限；版块权限矩阵里其他项留空继承，动错一项就会误伤发帖、上传权限。改完立刻发一个测试号验证一遍发帖和上传，不要等有人投诉才发现。

管理日志格式统一这点很关键，「【发码回收】关联广告号 UID:xxx」这种带固定前缀的写法，比写一段自然语言好用太多，以后靠关键词一搜就能全部找出来。建议把前缀也写进版规或版主手册里，让版主统一使用，否则不同的人写法不同，一年后就搜不全了。

用管理员主号实测这个坑踩得太准了，管理员天然豁免各类限制，跑一遍全都通过，等于白试。用无痕窗口注册普通号走完整流程这一点值得单独写进操作清单。

最后，计划任务里有没有现成清理过期未用码的任务，我也不确定，需要进「系统工具→计划任务」看任务列表最快；没有的话可以用 Cron::register 自定义注册一个，但要注意任务必须可重复执行，避免误伤仍在有效期内的码。

结论：转人工绑给邀请人是这条链上最省力的一环，但必须再配一条兜底规则，否则邀请人自己失联或账号被封，真人还是卡死在门口。

我建议在「邀请码申请」帖的规则里一次写清两层：一是“担保即担责”，拿码即默认接下被担保人的审核与申诉；二是“邀请人 7 天不处理自动升级到版主”，不给无限挂起。能不能在转人工时自动发通知，我不太确定，得进考试插件配置页看有没有这一项；没有就纯靠规则约束，效果也不差。

受限组那条，除了组名带“勿删”，建议把“只收哪几项”也写进版规，因为发码资格涉及的开关可能不止一处，别只关了一处以为收干净了。日志前缀同理，做成一张词表贴在版主区，让新上任的版主照抄，比自己摸索统一得多。

主号实测那个坑确认无误，再补一层：测试用的普通号最好确认它身上没挂含图片上传权益的会员套餐，不然上传那步会“意外通过”，等于只测了一半。计划任务里有没有现成的过期码清理任务我不确定，进任务列表看一眼最快；要自己用 Cron::register 注册的话，清理条件写成“已过期 + 未使用 + 未绑定用户”三个同时成立，保证重复执行不出事。

最后一个容易忽略的点：清过期码前先确认码表和使用记录是分开的，别把已注册用户的邀请关联一并删掉，追溯链一断，你之前辛苦对齐的那些日志就白做了。

兜底规则这条补得对，7 天自动升级到版主，可以再压到 72 小时：会看到通知并处理的邀请人，一天内就处理了；拖过三天的基本不会再管。规则里还应写明一句：“邀请人账号封禁期间，担保自动转移给版主”，否则真出现邀请人被封的情况，被担保人就会无处申诉。

测试号不要挂会员套餐那条很实用，建议把测试清单固定下来：无痕窗口、普通号、无任何权益，按“发帖→回复→私信→上传”顺序走一遍，每一步都要看到明确拦截提示，而不是单纯没反应，再放开考试。

清理条件写成“已过期 + 未使用 + 未绑定用户”，我同意；执行前先补一步：把删除条件改成等价的 SELECT，跑一次先看数量与样本，确认无误再换成删除。码表与使用记录是否分开存储，我不确定 Clara 的具体表结构，你进数据库看一下 invite 相关表，或直接备份后再操作最保险；如果邀请关系是落在用户表上的，清理时只要不触碰用户表，就不会断追溯链。“断链比留垃圾数据更贵”这个判断我完全认同。

日志前缀词表建议只做三五个，比如【发码回收】【发码发放】【考试转人工】，多了版主记不住就会各写各的。

72 小时这个压缩我认为是对的，但升级还得落到「有人看得见」上才算闭环：光把 7 天改成 72 小时，版主并不知道有哪些担保已经升级过来。

我的建议是：转人工或超时升级时，除了通知邀请人，同时给全体版主发一次 notify，并在版主区开一个置顶帖当「待处理担保台账」，格式就一条一行（日期 / 被担保人 UID / 邀请人 UID / 状态）。版主处理完改状态即可，不用翻后台日志反查。邀请人封禁期间担保自动转移这条我也同意，靠规则文本约束之外，最好再加一个自定义计划任务定期扫一遍「邀请人处于封禁状态 + 被担保人尚未通过考试」的组合，把清单推给版主——这类扫描用 Cron::register 注册就行，注意写成可重复执行。

SELECT 先跑一遍再换成 DELETE 这一步是对的，而且要多看一个东西：DESCRIBE 一下 invite 相关表，确认「未使用」到底怎么判定——是 used=0，还是 used_by 为空，还是两者都有。这个我不太确定 Clara 的具体字段设计，进数据库看一眼最快，别凭猜测写条件。样本量对不上就先别删。

日志前缀压到三五个我完全同意，顺便把每个前缀配一行真实示例贴上去，版主照抄比看词表更不容易走样。测试清单再加一句：每一步把拦截提示的原文记下来，将来改权限时能立刻对比出哪一步失效了。

结论：台账这条我赞成，但别让"每天扫一遍"变成"每天轰炸版主"——通知必须做幂等，否则三天后版主就全体免打扰了，闭环等于没做。

具体做法：用 Cron::register 注册的扫描任务每次只负责生成清单，notify 只在某条担保首次进入待处理时发一次。落地就得有个状态位（待处理 / 已升级 / 已处理），任务里先判断该条已存在记录就跳过、不存在才发通知。否则一天一次扫描，版主一天收一次重复通知，最后没人看。

"邀请人封禁"这个条件也别只看当前状态：封禁通常带到期时间，任务里要同时判断"封禁生效中且未过期"，不然历史封禁记录会被当成现状反复触发担保转移。这块具体字段我不敢打包票，进用户表看一眼最稳。

SELECT 先跑那一步再补一句：如果开了读写分离，SELECT / SHOW / DESCRIBE / EXPLAIN 是自动走从库的，存在秒级延迟，你确认数量后紧接着的 DELETE 走主库，两边可能对不上。所以别只凭"数量一致"就删，建议在条件里再加一条时间上界（如 created_at < 今日零点）把窗口锁死，或者干脆先看 DELETE 的影响行数再提交。DESCRIBE 确认 used 到底怎么判定那条我完全同意，我没有依据，看表最快。

台账用置顶帖的话，规则里必须写清"处理后改状态行 + 留处理人 UID 和时间"，否则两周后就分不清谁在跟、哪条跟丢了。

结论：这四点我都认，但其中“读写分离延迟”那条其实有更省事的解法——把 SELECT 和 DELETE 包进同一个事务里跑，事务内的查询会被强制走主库，直接从根上消除主从延迟，比加 time 上界更干净（当然两个一起用也行，加时间上界还能防止 DELeted 窗口外的数据被误伤；两者不冲突）。

通知幂等，我建议不要只用布尔位，直接加 notified_at 时间戳字段：判断条件写成“该担保记录不存在 或 notified_at IS NULL”，命中才发一次并写回时间。相比 is_notified=0/1，多存一个时间的好处是： später 版主问“这条到底通知过没有、什么时候发的”，你一眼就能答，不用翻通知表反查。另外扫描任务本身要写成可重复执行——先查或插入（INSERT 前先查），再判断要不要 notify，别用“先删后建”的写法，中间失败会丢记录。

封禁到期时间那条很关键，我再补一层：如果用户表里除了 ban_until 还有独立的封禁记录表（含历史记录），判断条件要落在“有效封禁”视图上，别直接扫历史表。字段名我不确定，进表 DESCRIBE 一下最快，这个我没法替你看。

台账“处理人 UID + 时间”必须写死进版规，而且建议再加一列“处理结论”（放行 / 驳回 / 转站长），否则两周后你只知道谁动过，不知道他的判断，容易来回翻烧饼。

坑：这个扫描任务建议先只推清单、不自动改状态，观察一两周确认没有误报，再考虑让它自动写入“已升级”，不要一步到位。

事务那条我认，而且系统里确实是这个规则：读写分离的三种强制走主库场景之一就是“事务内查询”，所以 SELECT + DELETE 包进同一事务，从根上就没有延迟问题，比加时间上界干净；两者叠加也不冲突，时间上界负责防止误伤窗口外的数据，事务负责保证查询和删除一致。

但清理过期未绑定邀请码这件事，我的取舍是不用事务，就用“先看后删”两步人工操作。理由：这是低频运维动作，不是高并发业务，原子性在这里买不到什么；而且你本来就要先跑 SELECT 看数量和样本、人工确认没问题再换 DELETE，这个停顿本身就是最可靠的保护。真要自动化到无人值守，再包事务，同时建议 SELECT ... FOR UPDATE——系统的行锁查询同样强制走主库，否则普通 SELECT 拿到结果、PHP 判断完再发 DELETE，中间仍有间隙。

notified_at 比布尔位好，我完全同意，版主问“通知过没有、什么时候发的”能直接答。再加半句：写回时用 UPDATE ... SET notified_at = NOW() WHERE id = ? AND notified_at IS NULL，看影响行数是否为 1 再算发成功。Cron 有文件锁，懒触发和外部 /cron 基本撞不上，但多一层条件不吃亏。

“有效封禁视图”这条我同意思路，但具体字段我真不敢替你写——封禁是存在用户表还是独立记录表，我不确定，DESCRIBE 一眼最快，别凭猜测。处理结论列建议也压到三四个固定值（放行 / 驳回 / 转站长），和日志前缀一样，多了版主记不住就各写各的。

坑：先只推清单、观察一两周再自动写状态，这个节奏别省——误报一次自动升级，比漏报更伤版主信任。