题目重点：在发帖前端与Node后端工程中增加违规内容检测和提示/星号遮罩，兼顾状态、绕过与误报处理。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 给定工程前后端部分为mock，实际检测接口与政策未给；本文训练采用模块化检测结果，不声称复原原工程文件。
- 提示与遮罩是显示动作，不能仅依赖客户端达到发布权限控制。输入编辑、请求并发、检测失败的发布策略需先固定。
解题路线
- 先画已有post draft→submit→server→render数据流，定位validator、persist和UI层。检测器输出policyVersion、contentHash、ranges、category、confidence，接口可由mock或真实模型实现。
- 前端debounce编辑检查，给每稿revision；响应只应用于对应revision，旧文本检查迟到不能把新稿覆盖。服务端提交重新检查同一hash并按政策决定allowed/review/blocked，客户端结果仅改善体验。
- 星号遮罩按字符range而非全局replace；Unicode字形/offset定义需一致，重叠range先合并，保留安全转义防HTML注入。检测器不要直接返回未经转义HTML。
- 明确failure状态与重试：网络失败不假装clean，若需人工审核就保存pending而非发布；用户看到原因与可修改提示，并有误报反馈。客户端绝不自动替用户发帖。
- 新增feature现场实现先选最小可测试路径，例如按draftRevision防迟到、policyVersion变化重检；每次给正常/命中/编辑竞态/服务失败用例，AI改动review确认未绕过server gate。
手动走一遍
稿v1有违规片段，用户改成v2正常；v1检测迟到必须丢弃，而非在v2正确文字位置加星号。即使用户绕过浏览器API直调submit，服务端仍按提交contentHash审核。
规模与取舍
前端提示触发率与debounce决定检测QPS，服务端每次正式提交至少一次权威判断；缓存仅按hash+policy/modelVersion且租户隔离。区间遮罩排序O(R log R)、输出O(L)，R是检测片段数。
易错点与追问
容易失分的边界
- 正则关键词mock只能验证工程流程，不是有害内容模型性能证明。
- 按UTF-16下标去切Python codepoint范围会错位，前后端需统一offset协议。
- 检测错误不应用最后一份成功结果覆盖所有新文本。
继续深挖
- 若policy更新，已发布内容如何重检？异步扫描带版本，结果更新与申诉保留，不把旧hash直接视为clean。
- 如果服务端只mock，无数据库，怎样演示幂等与pending状态？定义内存训练状态并明示重启不持久，而不声称生产可靠。
