“我这篇 1000 字的稿子”——这个数字在不同平台意味不同。Word 字数、字符数、公众号、小红书、X，各按各的算法。真正会踩坑的，不是不会数，而是以为所有平台都在数同一件事。
各平台字数规则一览
| 平台 | 计数单位 | 上限 | 备注 |
|---|---|---|---|
| Word（字数） | 中字 + 英文词 | — | 中文按字、英文按词 |
| Word（字符不计空格） | 单字符 | — | 所有非空白字符 |
| 公众号正文 | 更接近字符数 | 以编辑器实时提示为准 | 标点、emoji、换行常会影响统计 |
| 公众号摘要 / 标题 | 字符 | 以后台当前限制为准 | 截断和显示长度不等于发布上限 |
| 小红书正文 / 标题 | 更接近字符数 | 以发布页实时提示为准 | 这类规则变动频繁 |
| 微博 | 字符口径为主 | 以发布页实时提示为准 | 长文与短文入口可能不同 |
| X | weighted length | composer 实时计算 | URL、emoji、中日韩字符会加权 |
| Threads | 字符 | 500 | Meta 出品 |
| Mastodon | 字符 | 500 | 实例可调 |
| Bluesky | grapheme | 300 | 按”用户感知字符”算 |
| 知乎回答 | 字符 | 5 万 | 标题 50 字符 |
| 知乎专栏 | 字符 | 10 万 | 标题 50 |
| 简书 | 字符 | 几万 | 标题 36 字符 |
| 豆瓣广播 | 字符 | 10000 | 大幅超过早期 140 |
| 豆瓣短评 | 字符 | 140 | 经典门槛 |
数字和上限会随平台政策调整，这张表更适合帮你分辨平台按哪种“长度概念”在计数，而不是把所有上限背下来。
Word 的三个口径
打开 Word 文档，左下角”字数”实际有三个数字：
- 字数（words）：英文按空格分词、中文按汉字
- 字符数（不计空格）：所有非空白字符
- 字符数（计空格）：包括空格
纯中文：三个数字接近一致（汉字之间没有空格）。
"今天天气真好" → 字数 6, 字符数 6, 字符数(空) 6纯英文：差距大。
"The quick brown fox" → 字数 4, 字符数 16, 字符数(空) 19中英混合：最容易出问题。
"Hello, 世界！这是 100 个 demo"
→ Word 字数: ~6（"Hello" + "世界" + "这是" + "100" + "个" + "demo"，分词规则版本依赖）
→ 字符数(不空): 22
→ 字符数(空): 24投稿场景的”3000 字”指什么：
- 中文期刊、网文：基本指字符数（不计空格）
- 英文期刊：指 words
- 报告 / 论文：摘要计字符、正文计字数
- 不确定时直接问编辑——同一个数字差 30%+
公众号的字数比 Word 多
把 Word 1000 字的稿子粘到公众号编辑器，常会显示 1300-1500 字。原因：
- 公众号按”字符数”算，含标点
- 中文标点（。，”！？等）每个都算 1
- 英文字母、数字按字符算
- emoji 算 1-2 个字符
- 换行算 1 字符
Word 字数 1000：
中文 600 字（汉字）
英文 100 词 ≈ 500 字符
标点 200 个
公众号显示：
600 + 500 + 200 = 1300 字符（不算 emoji 的话）实务：
- 公众号的显示值常常会高于你心里的“纯汉字数”
- 最终以上传或发布页右下角的实时统计为准
- 如果你在做时长估算，读完时间和段落密度往往比“总字数”更有意义
小红书的限制更适合看发布页
小红书对标题和正文通常都比较敏感，但最稳的做法不是背旧数值，而是盯住发布页当前提示。
| 字段 | 上限 | 备注 |
|---|---|---|
| 项目 | 更稳的理解 | |
| --- | --- | |
| 正文 | 按字符思路控制，并看发布页提示 | |
| 标题 | 空间很紧，尽量把信息密度放高 | |
| emoji / 话题 / @ | 不要假设旧口径永远成立 |
更实用的写法：
先把正文写在安全范围内，再把话题和 `@` 当成附加信息，而不是依赖它们“挤字数”。emoji 字数计算：
- BMP 内 emoji（U+0000-FFFF）算 1 字符
- 星 emoji（U+10000+）算 2 字符
- 复合 emoji（带肤色 / 性别变种）按组成算
"☀️ 今天天气真好" → 7 字符（☀️ 算 1-2）
"👨👩👧👦 家庭" → 11 字符（复合 emoji 拆开算）字数策略：
- 先用字符数视角控制正文长度
- 标题位置最珍贵，优先保留关键词和结果词
- 长文接近上限时，拆上下篇比硬挤更稳
X 的 weighted length 系统
X 不是简单地“数字符”，而是在数 weighted length：
- 纯英文通常更接近 1:1
- 中日韩字符、emoji、链接混排时，实际可发长度会缩短
- URL 会按平台自己的固定口径折算
你真正需要记住的不是某个旧数字，而是这件事：
- X 会在 composer 里实时显示当前占用
- 同样是 100 个“看起来差不多长”的字符，英文和中文的可发结果可能不同
- 混有链接和 emoji 的内容，最好直接在发布页再确认一次
一个英文 + 一张图 + 一个链接的典型推：
"Check out this great article about web performance optimization techniques and best practices for modern apps! https://example.com/very-long-url-here"
↑
URL 占 23 weight 不论长度中文 / 英文 / 数字的混合算法
字数统计的复杂性主要来自多语言混合。常见的几种规则：
规则 A：字符等价（公众号 / 小红书 / 微博）
所有非空白字符算 1 个，不区分中英数字
"Hello 世界！" → 9 字符规则 B：CJK 加权（Twitter / X）
ASCII = 1 weight，CJK = 2 weight
"Hello 世界！" → 5 + 2×3 = 11 weight规则 C：分词混合（Word 字数）
英文按空格分词 + 中文按汉字
"Hello 世界！" → 1 词 + 2 字 = 3规则 D：字节数（数据库 / API 限制）
按 UTF-8 字节算
"Hello 世界！" → 5 + 3×2 + 3 = 14 字节
（中文每字 3 字节，英文每字 1 字节）不同口径下同样一句话的”长度”差 5 倍。
emoji 的字数陷阱
emoji 的字数计算比想象复杂：
🙂 U+1F642 → JS string 长度 2 (UTF-16 代理对)
👨 U+1F468 → 长度 2
👨💻 组合 → 长度 5（👨 + ZWJ + 💻 = 2 + 1 + 2）
👨🏻💻 组合 → 长度 7（加肤色修饰）
👨👩👧👦 组合 → 长度 11（4 个人 + 3 个 ZWJ）不同平台的处理：
- JS
'👨👩👧👦'.length→ 11（按 UTF-16 code unit） - 用户感知 → 1 个字符（视觉一个 emoji）
- Twitter → 2 weight（一个 emoji）
- Bluesky → 1 grapheme cluster（按”用户感知字符”算）
- 小红书 → 看具体 emoji，1-2 字符
正确的”用户感知字符”算法：
// ES2022+
[...new Intl.Segmenter().segment('👨👩👧👦')].length; // 1
// 老 API
[...'👨👩👧👦'].length; // 7（split by code point，但仍拆 ZWJ 复合）本工具按多种规则同时显示，避免歧义。
几个常见的字数误区
1. “段落字数限制”vs”全文字数限制”
公众号编辑器有”单段不超过 5000 字符”的隐性限制，超过会提示拆段。但这是编辑器排版限制，不是发布限制。
2. 复制粘贴带格式后字数变化
从 Word / Notion 复制带格式文本到公众号，HTML 标签可能被算入字数（取决于编辑器）。建议先转纯文本再粘贴。
3. 表情符号 vs 颜文字
"开心 😊" emoji，1-2 字符
"开心 (^_^)" 颜文字，5 字符（包含括号、_）颜文字字数多但兼容性好——所有平台都正确显示。
4. 草稿字数与发布字数差异
部分平台草稿不严格限字数，但发布时检查。写之前确认上限，避免写完发不出。
一句话总结
字数没有统一标准——Word 字数 vs 字符数差 30%+、公众号比 Word 多 30-50%、小红书 1000 字符硬限制、Twitter 中文按 2 倍 weight、emoji 算法千奇百怪——写作前先按目标平台校准。