计数单位需与用户理解一致
别名: 字符还是字节 · word count vs character · 中文词数
概念解释
屏幕写着「还可输入 12」，人按自己的单位去理解：中文用户数汉字，英文用户数单词或字母，工程师数字节，短信网关数 septet。界面若按另一种单位在减，就会出现计数单位不一致（count-unit mismatch）：看起来还剩 12，贴一个汉字或一个 emoji 却少了 2，甚至直接顶格。它管的是减的是什么，不是计数器何时亮，也不是超了就切掉。
机制
「字」在自然语言里不是一个工程量。Unicode 里一个视觉字符可能是多个码点（组合音符、emoji 序列）；UTF-8 下中文三字节、emoji 更多；Twitter 一类产品曾按加权单位计。用户看见的是字形，系统减的是码点、字节或加权。每次按键的递减步长对不上预期时，人会以为计数器坏了，或在接近上限时不敢用标点、表情。中英文混合时更乱：空格算不算、英文单词算 1 还是按字母算。单位不一致会把「还剩多少」从刹车变成谜题。
怎么研究
让人在已知上限下尽量写满，比较他们以为的剩余与系统剩余，并记录 emoji、组合字符、换行、中英混合处的争议。自变量：展示单位的名称（字 / 字符 / 词 / 字节）、是否把换行算入、是否对 emoji 加权。因变量：预测误差、在上限附近改用「安全字符」的次数。不要只用 BMP 基本汉字当测试集。把界面文案里的单位词和实际算法对照，是成本最低的审计。
边界
后端存储按字节、界面按字形，两边单位可以不同，但必须在提示里说清「按显示字符，约合 N」，不能假装是同一个数。搜索关键字、标签往往按 token 而不是按字，把字数器搬过去会错。无空格语言没有「词」的直觉单位，英文产品的 word count 对中文用户没有意义。屏幕阅读器读「还剩十二」时若不带单位，听觉通道同样发生错配。
怎么落地
- 选定与用户任务相同的单位（中文界面多数用「字」= 一个可见字符），在文案里写死这个词，不要只显示光秃数字。
- 让一个可见字符（含常见 emoji）对应一次递减；若技术上必须按字节，就在说明里写「按字节，汉字约三倍」。
- 审计换行、空格、零宽字符是否计入，并与文案一致。
- 验证：分别输入 10 个汉字、10 个字母、10 个 emoji、一段中英混排，看计数是否按人能点着数的个数在减。步长跳变或文案写「字」却按字节减，就改算法或改用词。