处理长尾输入：白名单、兜底与礼貌地拒绝

长尾输入是事故入口。本文给出三类白名单（格式/大小/字段）、四步兜底（规范化、截断并标注、降级、明确失败）、拒绝文案的改写对照、该观测的指标与一条判据。

长尾输入是"事故的入口"

正常输入只占一部分，真正惹麻烦的是**长尾** ✗：超长文本、二进制伪装成文本、极深嵌套结构、

全角/零宽字符、几千条重复行 ✔。它们会打崩解析、撑爆上下文、拉高成本 ✔。

处理长尾的原则：**白名单优先、兜底明确、拒绝要礼貌且可行动** ✔。

**格式白名单**：只接受约定的格式（文本/JSON/CSV ✔），其它明确拒绝 ✔；

**大小白名单**：单次调用输入上限（例如 2 万字符 ✔），并**在界面上说明** ✔；

**字段白名单**：结构化输入只取需要的字段 ✔（见数据脱敏那篇 ✔）；

**编码白名单**：入库存 UTF-8 ✔，非法字节序列明确替换或拒绝 ✔。

**白名单的关键是"说清楚"** ✔：限制写在界面与文档里 ✔，而不是让用户撞墙 ✗。

按顺序做四件事 ✔：

1. **规范化**：去零宽字符、统一换行、Unicode 归一化（NFC ✔）、压缩连续空行 ✔；

2. **截断并标注**：超长就截断，并**明确告诉用户与模型"内容已截断"** ✔（静默截断 ✗ 会导致答非所问 ✔）；

3. **降级处理**：解析失败时退到"纯文本模式" ✔（能处理就先处理 ✔）；

4. **明确失败**：都不行就报错，并给出**可行动建议** ✔（"请拆成两段提交""请去掉附件" ✔）。

| 别写 | 改写 |

|---|---|

| 输入非法 | 文件超过 2 MB，请压缩后重试，或只提交前 20 页 |

| 格式错误 | 需要 JSON 格式；你的内容第 3 行缺少逗号 |

| 不支持 | 暂不支持 Excel；可另存为 CSV 后提交 |

**要点**：说清**限制值、原因、替代做法** ✔。

多数长尾输入是**正常用户的真实情况** ✔（从 Word 复制来的带格式文本、手机拍的照片转的文字 ✔）。

所以设计时优先**能处理就处理** ✔，把"严格拒绝"留给真正的安全边界 ✔（注入、越权 ✔）。

各类拒绝的**占比**（哪一种拒绝最多 → 说明界面提示不足 ✔）；

**截断发生率**（高了说明上限太紧或用户习惯不同 ✔）；

规范化**改动率**（去掉了多少字符 → 判断上游质量 ✔）；

解析失败 Top 样例（每周看几条，常能发现界面问题 ✔）。

> 被拒绝的用户能否**不问你**就知道下一步怎么做 ✔？

> 不能，说明拒绝文案没写好 ✗（而不是用户不会用 ✗）。