长尾输入是"事故的入口"
正常输入只占一部分，真正惹麻烦的是长尾 ✗：超长文本、二进制伪装成文本、极深嵌套结构、
全角/零宽字符、几千条重复行 ✔。它们会打崩解析、撑爆上下文、拉高成本 ✔。
处理长尾的原则：白名单优先、兜底明确、拒绝要礼貌且可行动 ✔。
一、白名单（最有效）
- 格式白名单：只接受约定的格式（文本/JSON/CSV ✔），其它明确拒绝 ✔；
- 大小白名单：单次调用输入上限（例如 2 万字符 ✔），并在界面上说明 ✔；
- 字段白名单：结构化输入只取需要的字段 ✔（见数据脱敏那篇 ✔）；
- 编码白名单：入库存 UTF-8 ✔，非法字节序列明确替换或拒绝 ✔。
白名单的关键是"说清楚" ✔：限制写在界面与文档里 ✔，而不是让用户撞墙 ✗。
二、兜底（拦不住的时候）
按顺序做四件事 ✔：
- 规范化：去零宽字符、统一换行、Unicode 归一化（NFC ✔）、压缩连续空行 ✔；
- 截断并标注：超长就截断，并明确告诉用户与模型"内容已截断" ✔（静默截断 ✗ 会导致答非所问 ✔）；
- 降级处理：解析失败时退到"纯文本模式" ✔（能处理就先处理 ✔）；
- 明确失败：都不行就报错，并给出可行动建议 ✔（"请拆成两段提交""请去掉附件" ✔）。
三、礼貌地拒绝（写法）
| 别写 | 改写 |
|---|---|
| 输入非法 | 文件超过 2 MB，请压缩后重试，或只提交前 20 页 |
| 格式错误 | 需要 JSON 格式；你的内容第 3 行缺少逗号 |
| 不支持 | 暂不支持 Excel；可另存为 CSV 后提交 |
要点：说清限制值、原因、替代做法 ✔。
四、别把长尾当"恶意"
多数长尾输入是正常用户的真实情况 ✔（从 Word 复制来的带格式文本、手机拍的照片转的文字 ✔）。
所以设计时优先能处理就处理 ✔，把"严格拒绝"留给真正的安全边界 ✔（注入、越权 ✔）。
五、该观测什么
- 各类拒绝的占比（哪一种拒绝最多 → 说明界面提示不足 ✔）；
- 截断发生率（高了说明上限太紧或用户习惯不同 ✔）；
- 规范化改动率（去掉了多少字符 → 判断上游质量 ✔）；
- 解析失败 Top 样例（每周看几条，常能发现界面问题 ✔）。
一条判据
被拒绝的用户能否不问你就知道下一步怎么做 ✔？
不能，说明拒绝文案没写好 ✗（而不是用户不会用 ✗）。