测试拦截效果的正确做法是「先定基线、再分级打点、最后三方对日志」：每一层拦截规则都必须同时拿到两组结果——该拦的拦住了、该放的没被误杀，只拿到前一组就等于没测。下面按拦截层次给出可直接照做的步骤和参数。
测试拦截效果要验证哪几层？
结论：一次完整的拦截效果测试要覆盖频率限制、验证码、规则匹配、人工审核四层，只测最外层等于漏掉一半。
- 频率层：社区发帖冷却 30 秒、回帖冷却 15 秒，冷却周期内重复提交必须被拒绝。
- 验证码层：注册、登录、发帖、回帖页面启用 4 位数字／字符图形验证码，有效期 10 分钟，超时需重新获取。
- 规则层：注册邮箱白名单仅支持
qq.com，临时邮箱、一次性邮箱由系统自动拦截；搜索限流登录账号按账号计数、游客按 IP 计数，关键词最小长度 2 字符。
- 人审层：先审后发支持全局开启，也支持按独立版块单独配置，测试时要分别验证「全局开」和「单版块开」两种状态。
用什么命令测频率拦截？
结论：用 curl 循环发同样的请求，靠改变请求间隔来区分「该被拦」和「该放行」两个用例。
for i in $(seq 1 5); do
curl -s -o /dev/null -w "%{http_code} %{time_total}\n" \
-X POST "https://你的站点/发帖接口" \
-b cookie.txt -d "subject=test&message=test"
sleep 5
done
把地址换成你站点的实际发帖接口，带上登录后的 Cookie。以发帖冷却 30 秒为例：间隔 5 秒连续请求，第 2 次起应返回拦截状态；把 sleep 5 改成 sleep 35 再跑一遍，5 次应全部成功。两次结果对比才是完整的拦截证据。回帖同理，把间隔改成 sleep 8 与 sleep 16 两组对照 15 秒冷却。
怎么确认拦截不会误杀正常用户？
结论：每个拦截用例都必须配一条正常用例，两者路径、UA、Cookie 完全相同，只改频率或内容这一个变量。
关键是利用系统自带的豁免项做对照组：管理员、版主免验证码，用版主账号跑一遍验证码流程应当直接通过，说明豁免生效；搜索限流值填 0 代表不限次数，把限流设为 0 后同一账号连续搜索应全部通过，改成 5 再搜第 6 次必须被拦。另外，未上传头像的账号禁止发帖，这条会污染频率测试的基线——测之前先上传头像解除限制，否则第一帖就被拒，你会误判成冷却规则生效。
日志怎么核对才算三方对齐？
结论：请求侧（状态码与耗时）、应用侧（拦截原因）、用户侧（前端提示文案）必须指向同一事件、同一时间点。
具体做法：拦截响应要给明确状态码（403／429 一类），不能是 200 空白页，否则监控抓不到；应用侧确认拦截原因记录到具体规则名，而不是笼统的「操作失败」；用户侧核对提示文案是否说明「请 30 秒后再试」这类可操作信息。事后回查时，回收站帖子和用户举报记录永久存档、不自动清理，可以据此比对测试时间窗内的实际数据。若判定为误拦截，走「反馈举报」版块提交，附上账号、时间戳、请求路径和返回码，比只写「我被封了」可复现得多。
拦截测试最容易踩的三个坑
结论：单 IP 测试、忽略验证码时效、跳过异常路径，是复测时返工最多的三项。
第一，只用一个 IP 测搜索限流。登录账号按账号统计、游客按 IP 统计，必须准备「同 IP 不同账号」和「同账号不同 IP」两组用例，否则测不出统计维度是否正确。第二，忽略验证码 10 分钟有效期，抓一个旧验证码反复提交，会得出「验证码失效」的错误结论，正确做法是每次重新获取。第三，只测正常表单提交，不测空参数、超长参数、重复提交，这些才是拦截规则真正要挡的流量。测完把用例、时间、返回码整理成一张表存档，下次改规则或换防护策略时可以直接复用。
一句话收束：拦截效果不是「能不能挡住」，而是「挡得准不准」——四层分开测、每组配对照、三处日志对得上，才算测完。
