字符与字数限制完全指南 2026 — Twitter、SMS、SEO、Instagram
**字符限制（character limit）**指的是一个平台在单个字段中允许的 Unicode 码点（codepoint）最大数量。Twitter 单条推文 280、GSM-7 编码下的单段 SMS 是 160、Google meta description 在被截断前大约是 160。具体哪个数字对你重要，看你发布在哪，以及文本里是否含 emoji、智能引号或中日韩字符，它们都会改变计算方式。
本指南面向写社交媒体的人、SEO 专员、营销文案、按段计费的 SMS 发送方，以及需要让校验逻辑与 Twitter、Instagram 或 SMS 网关实际计数对齐的开发者。想直接看 25 个平台的速查表，跳到速查表章节；想把草稿放在六大平台旁实时对照，请用字数统计，超出限制时进度条会立刻变红。
Quick Reference — Every Platform’s Character & Word Limit
下面这张表覆盖了写作者和开发者最常遇到的 30 多个字段。「硬限制」是平台强制执行的上限；「可见 / 折叠以上」是读者在被截断前能看到的部分；「甜区」是经验范围内内容表现最好的区间。
| 平台 | 硬限制 | 可见 / 折叠以上 | 甜区 | emoji 如何计数 |
|---|---|---|---|---|
| Twitter / X 推文 | 280 字符 | 280 | 70-100 字符 | 1 码点 |
| Twitter / X 简介 | 160 字符 | 160 | — | 1 码点 |
| Twitter / X 显示名 | 50 字符 | 50 | — | 1 码点 |
| X Premium 长文 | 25,000 字符 | — | — | 1 码点 |
| Instagram 标题 | 2,200 字符 | 前 125 字符（之后显示「more」） | 钩子 <125 | 1 码点 |
| Instagram 简介 | 150 字符 | 150 | — | 1 码点 |
| Instagram 标签 | 最多 30 个 | — | 5-10 | — |
| LinkedIn 帖子 | 3,000 字符 | 前 210 字符（之后显示「see more」） | <1,300 | 1 码点 |
| LinkedIn 文章 | 110,000 字符 | — | — | 1 码点 |
| LinkedIn 标题 | 220 字符 | 220 | — | 1 码点 |
| Facebook 帖子 | 63,206 字符 | 桌面端约 477 / 移动端约 125 | 自然流量 <80 | 1 码点 |
| TikTok 标题 | 2,200 字符 | 前约 100 | <150 | 1 码点 |
| YouTube 标题 | 100 字符 | 70（搜索结果） | <60 | 1 码点 |
| YouTube 简介 | 5,000 字符 | 折叠以上前 100-150 | 钩子前 150 | 1 码点 |
| YouTube 评论 | 10,000 字符 | — | — | 1 码点 |
| Reddit 标题 | 300 字符 | — | <60（取决于子版规则） | 1 码点 |
| Reddit 评论 | 10,000 字符 | — | — | 1 码点 |
| Discord 消息 | 2,000 字符 | 2,000 | — | 1 码点 |
| Discord 嵌入描述 | 4,096 字符 | — | — | 1 码点 |
| Slack 消息 | 40,000 字符 | — | 可读性 <2,000 | 1 码点 |
| Pinterest pin 描述 | 500 字符 | 前 50-60 | <125 | 1 码点 |
| Mastodon toot | 500 字符（可配置） | 500 | — | 1 码点 |
| Bluesky 帖子 | 300 字符 | 300 | — | 1 字素簇（grapheme cluster） |
| Threads 帖子 | 500 字符 | 500 | — | 1 码点 |
| SEO meta description（Google） | 桌面端约 160 / 移动端约 120 | 150-160 | 150-160 | 1 码点 |
| SEO 页面标题（Google） | 桌面端约 60 / 移动端约 50 | 50-60 | 50-60 | 1 码点 |
| Open Graph description | LinkedIn/FB 截断前约 200 | 150-200 | 150-200 | 1 码点 |
| Twitter Card description | 最多 200 字符 | 200 | 150-200 | 1 码点 |
| SMS 单段（GSM-7） | 160 字符 | — | — | 特殊——见下文 |
| SMS 单段（UCS-2 / emoji） | 70 字符 | — | — | 1 码点 |
| WhatsApp 消息文本 | 65,536 字符 | — | — | 1 码点 |
| 邮件主题行 | 平台无限制 | 桌面端约 60 / 移动端约 30 | <50 | 1 码点 |
| Google Ads 标题 | 30 字符 × 15 条 | 每条 30 | 30 | 1 码点 |
| Google Ads 描述 | 90 字符 × 4 条 | 每条 90 | 90 | 1 码点 |
| App Store 标题 | 30 字符 | 30 | 30 | 1 码点 |
| App Store 副标题 | 30 字符 | 30 | 30 | 1 码点 |
| App Store 描述 | 4,000 字符 | 折叠以上前 252 | 钩子 252 | 1 码点 |
| Play Store 短描述 | 80 字符 | 80 | 80 | 1 码点 |
| Play Store 长描述 | 4,000 字符 | 折叠以上前 80 | 钩子 80 | 1 码点 |
超出「甜区」的内容多数会被截断、降权或在可见卡片中被裁剪。X Premium 长文和 Mastodon（每个实例可单独配置）是少数几种允许超过 500 字符且不被惩罚的例外。上表中除 SMS 一栏适用特殊规则外，所有计数都按 Unicode 码点算，一个 emoji 是 1 个字符，不是 2 个。想一次性对照六大主流平台的限制，把草稿粘贴到字数统计，进度条会在你点发布前就抓住超限文本。
How Characters Are Actually Counted (Unicode Code Points vs UTF-16)
三个不同的工具可能给同一段字符串报出三个不同的字符数。原因是「字符」本身就不是单一概念，它可能指 Unicode 码点、UTF-16 码元（code unit），也可能指字素簇，而每个平台各选一种。
「字符」到底是什么——码点 vs 码元 vs 字素
**码点（codepoint）**是一个 Unicode 标量值，即 U+0000 到 U+10FFFF 之间任何被 Unicode 分配给字符或标记为保留的整数。**码元（code unit）**是某种编码下的最小存储单位：UTF-16 使用 16 位的码元，UTF-8 使用 8 位的码元。**字素簇（grapheme cluster）**是人类感知到的「一个可见字符」。有时是一个码点，有时是一个基础码点加若干组合标记，有时则是像家庭 emoji 👨👩👧👦 这样的零宽连接序列（七个码点连成一个可见字形）。
对于字符串 "a🌍👨👩👧"，三种数法给出的结果互不相同：
| 计数方法 | 结果 | 谁在用 |
|---|---|---|
UTF-16 码元（JS string.length） | 10 | 朴素的 JavaScript 代码 |
| Unicode 码点 | 6 | Twitter、Instagram、SMS 网关 |
| 字素簇 | 3 | Bluesky、屏幕阅读器、文本编辑器 |
为什么 string.length 会在 emoji 上说谎
JavaScript 在内部以 UTF-16 存储字符串。任何高于 U+FFFF 的码点（所有 emoji，以及全部辅助平面字符）都会被编码为一个代理对（surrogate pair），也就是两个 16 位码元。.length 属性报告的是这两个码元，而不是一个字符。
"🌍".length // 2 (UTF-16 code units)
[..."🌍"].length // 1 (codepoints — what Twitter/SMS counts)
"🌍".match(/./gu).length // 1 (codepoints via regex with /u flag)展开运算符和带 /u 标志的正则都按码点遍历，这正是 Twitter、Instagram 和 SMS 网关对照限制时用的尺度。一个直接用原始 .length 写出的校验函数，会把实际未超限的推文拒之门外，或者更糟，放行下游系统会拒收的消息。
中日韩字符与组合标记又如何
中文、日文和韩文表意文字（ideograph）每个都是一个码点，在所有平台上都计为一个字符。代价最大的地方在 SMS：消息中只要出现任何非 GSM-7 字符，整条短信就会切换到 UCS-2 编码，单段限制从 160 跌到 70（下一节会展开）。
组合标记的行为则不同。带重音的 á 写成预组合形式 á 是一个码点；同样的 á 拆成 a + ́（组合尖音符）则是两个码点，但只是一个字素簇。多数平台按码点计数，因此第二种写法多花一个字符。Bluesky 是一个明显的例外，它按字素簇计数，两种写法都只算 1 个。
各语言中如何计数——快速参考
// JavaScript
[...str].length // codepoints
Array.from(str).length // codepoints
// Python 3 — len() is codepoint by default
len(s)
// Go — utf8 package
utf8.RuneCountInString(s)
// Rust — chars() iterates codepoints
s.chars().count()
// Java — codePointCount
s.codePointCount(0, s.length())作为对照，Base64 编码解码展示了另一个方向：当文本被编码为 Base64 用于传输时，每 3 字节的 UTF-8 输入会变成 4 个 ASCII 输出字符，编码后的长度取决于字节数，而不是码点数。粘贴一个 emoji 就能看到 Base64 输出扩展到 8 个字符；同一个 emoji 在 Twitter 上只占 1 个字符，在 UTF-8 中却占 4 字节。
想在任何草稿上看到码点计数（Twitter 实际衡量的数字），字数统计默认按 Unicode 正确计算。
SMS Character Limit — GSM-7, UCS-2 & Multi-Part Messages
SMS 是唯一一个加一个 emoji 就能让账单直接翻倍的主流渠道。问题出在编码上，这套数学自 1985 年以来就没变过。
160 字符这个魔法数——GSM-7 的来历
1985 年的 GSM-03.38 标准把单条 SMS 的有效载荷定在 140 字节。配合一种 7 位的字符编码，140 字节能装下 1,120 比特 ÷ 7 = 160 个字符，这就是著名的 sms character limit 160 的来源。GSM-7 字符集包含 128 个基础字符，外加一张 10 字符的扩展表（覆盖 { } [ ] | \ ~ ^ € 以及换页符）。只要文本完全落在这个集合内，每段 160 字符的预算就能用满。
落在 GSM-7 之外、会触发切换的字符包括：
- 全部 emoji
- 弯引号 / 智能引号（
""''），注意它们与 ASCII 直引号"'不同 - GSM-7 那 35 个之外的大多数带重音拉丁字母（
é á ñ ü ø等；GSM-7 只包含ä ö å æ ø à è ì ò ù等少数几个） - 全角标点、中日韩字符、阿拉伯文、希伯来文、希腊文小写、西里尔文
- 反引号
`和波浪号~（波浪号属于 GSM-7 扩展表，会占掉 160 字符中的 2 个）
UCS-2 陷阱——一个 emoji 让上限从 160 跌到 70
只要消息中任何位置出现一个非 GSM-7 字符，整条消息就会切换到 UCS-2 编码。UCS-2 每字符占 16 位，因此 140 字节 ÷ 2 = 每段 70 字符。真实示例：
"Hello, your code is 12345" → 26 chars, GSM-7, 1 segment
"Hello, your code is 12345 ✓" → 28 chars, GSM-7 (✓ in extension), 1 segment
"Hello, your code is 12345 ✅" → 28 chars, UCS-2 (emoji), 1 segment (under 70)
"Hello, "your" code is 12345 ✅" → smart quotes + emoji → UCS-2
"Hi 你好" → CJK → UCS-2, 1 segment (5 chars)最后那条 "Hi 你好" 才是真正的陷阱：明明只有 5 个字符，却已经按 UCS-2 计费，之后再加 65 个字符还能装进一段，再多就要开第二段。
多段 SMS（拼接）
一旦越过 160（GSM-7）或 70（UCS-2），消息就会被拆成多段。每段都要带一个 7 字符的用户数据头（User Data Header, UDH）用于重组，因此每段可用的有效载荷会下降：
- GSM-7 多段：每段 153 字符
- UCS-2 多段：每段 67 字符
接收端会把多段无感地重组，但计费是按段，而不是按消息。一条 161 字符的 GSM-7 消息要花 2 段；一条 1,000 字符的 GSM-7 消息要花 7 段（153 × 6 = 918，第 7 段装下最后的 82 字符）。
成本计算——一个 emoji 何时让账单翻倍
考虑一条 80 字符的纯文本营销短信：
- 纯文本：80 字符 → GSM-7 → 1 段，单价 X
- 加一个 emoji：80 字符 → UCS-2 → 80 > 70 → 2 段，价格 2X
加一个 emoji 让账单翻倍是真实存在的现象，规模一上去就更明显。一场 10 万条消息的活动，每段 $0.0075，在 GSM-7 下要 $750，在 UCS-2 下要 $1,500，这就是一个价值 $750 的 emoji。所有主流 SMS 服务商（Twilio、Bandwidth、AWS SNS、MessageBird、Vonage）都按这种方式计费。编码规则来自 GSM 标准，不是各家厂商的政策。关于字节级编码取舍的来龙去脉，以及为何 ASCII / UTF-8 / UCS-2 会作为不同标准并存，可以参考 Understanding Base64，它是同一类「比特如何变成字符」的问题，只是落在邮件而不是 SMS 上。
如何让消息留在 GSM-7 内
- 使用 ASCII 直引号
"'，而不是智能引号 - 使用 ASCII 连字符
-，而不是长破折号—或半字线– - 把
©和®拼写成(c)和(R) - 除非活动预算已经把 UCS-2 成本算进去，否则避免使用 emoji
- 厂商控制台（Twilio、Bandwidth、MessageBird 的）会在预览旁显示「encoding: GSM-7」或「UCS-2」，群发前先确认
起草过程中最快的自检方式是字数统计的 SMS 进度条，它按 160 字符基准报告。如果文本触发了 UCS-2，把字符数心算除以 2.29 就能在 70 字符规则下估出段数。
SEO Limits — Meta Description, Title Tag, OG, Twitter Card
SEO 的字符限制比平台限制软，meta description 写到 300 字符 Google 也不会拒收页面，但实际的截断规则对点击率仍然重要。下面这些数字在 2026 年仍然适用。
Meta description——150-160 字符甜区
Google 桌面端搜索结果会在 155-165 字符附近截断 meta description；移动端的截断点落在 100 到 120 之间。截断位置并不固定，因为 Google 衡量的是显示像素，而不是字符。一段满是 W 和 M 字形的描述会比一段满是 i 和 l 的描述更早到达截断像素。
实战写作规则：
- 总长度对准 150-160 字符
- 核心信息放在前 120 字符内（移动端安全）
- 在前 30 字符抛出该页面的 meta description character limit 关键词
- 在最后 30 字符放 CTA，这样即使桌面端从中间截断，CTA 依然可见
2017-2018 年那段时间，Google 曾短暂把 meta description 的显示上限放宽到 320 字符，至今仍有大量 SEO 教程引用这个数字。Google 已于 2018 年中恢复到 160。今天再写到 200 字符以上，只会把后半句藏起来。
另一个失败模式：低于 120 字符的描述常常被整段替换。Google 判断你的描述无法完整服务查询意图，就会从页面正文中另抽一段，你在毫无预警的情况下失去对 CTR 的控制。
Title tag——桌面 60、移动 50
title 标签在桌面端大约 60 字符处被截断，移动端约 50 字符。与描述同样按像素截断，同样要小心宽字形。
甜区：50-60 字符，把目标关键词放在前 30 字符以扛过任何截断。长尾品牌后缀（| Brand Name）放在最后，那里被截断的代价最小。
像素宽度 vs 字符计数——Google 真正的规则
Google SERP 描述容器在桌面端宽度约 920 像素。平均字符宽度约 6.5 像素，因此得出 140-160 字符的经验目标。但每个字符的宽度差距很大：i 渲染大约 3 像素，M 大约 11 像素。一段全大写的文案（「BEST WIDGETS FOR WINTER WEDDINGS」）会比同样长度的小写版本早得多地被截断。
发布前的预览用像素精确的 SERP 模拟器比单纯的字符计数器更可靠，尤其在 SEO 文案上。
OG description 和 Twitter Card description
Open Graph 协议中的 og:description 决定了 Facebook、LinkedIn、Slack 和 Discord 上分享链接预览下方显示的内容。各平台的显示上限不同，多数在 200 字符处截断，部分扩展到 300。Twitter Card 的 twitter:description 在 Twitter 解析器中被硬限制为 200 字符。
合理的默认值：
- OG 和 Twitter Card 都写 150-200 字符
- 它们可以与 meta description 一致，但 OG 可以略长，因为 OG 长度不影响搜索排名
- 验证你的结构化数据选择（尤其是哪些字段会被无意拉入 OG）时，参考 Security Best Practices 中的模式，不受信任的 OG 元数据是常见的钓鱼向量
「无字符限制」到底意味着什么
H1 标签、正文内容和 URL slug 没有平台强制的 SEO 字符限制，但软上限仍然适用：
- H1 超过 70 字符会破坏视觉层级和可扫读性
- URL slug 技术上无限；Google 在 SERP 显示约 90 字符，再长只是装饰
- 正文没有长度上限，但 Google 把「内容是否有用」排在水分之上，单纯的字数不是排名信号
字数统计在你起草时实时跟踪 meta description（160）和 title tag（60），临近截断像素时进度条会变橙再变红。
Social Platforms — Twitter/X, Instagram, LinkedIn, Facebook & Beyond
每个平台的字符上限背后都有具体由来；硬限制之下，还有一个让内容真正表现得好的甜区。
Twitter / X——280、Premium 25,000、URL 替换规则
标准的 twitter character limit 是 280 字符，2017 年 11 月从 140 翻倍而来。X Premium 订阅者可以发布最多 25,000 字符的长文并附带富文本格式，但 280 字符的短贴依旧是自然触达的主流。
不太显然的规则是 URL 替换。Twitter 在发布时会把每个 URL（无论原始长度）包裹进一个 23 字符的 t.co 短链，这 23 个字符的代价是固定的。
published_length = raw_length − URL_length + 23例：草稿 "Check this: https://example.com/very-long-path?id=12345" 共 53 个原始字符。其中 URL 占 38 字符，发布时会被替换为一个 23 字符的 t.co 链接，因此发布长度为 53 − 38 + 23 = 38 字符。你白捡了 15 个字符。
把长 URL 粘进草稿前，URL 编码解码工具可以快速核对到底什么算 URL（Twitter 按 RFC 3986 模式识别 URL，查询字符串和片段都算）。子域名、协议、端口、路径、查询和片段都会被这 23 字符的替换一口吞下。
Twitter 其它字段：显示名 50 字符、简介 160 字符、handle 15 字符。Threads（Meta 对标 Twitter 的产品）改用 500 字符限制。
Instagram——2,200 标题、30 标签、125 字符钩子
Instagram 标题允许 2,200 字符，但 feed 只展示前 125 个字符，之后折叠到「… more」点击之后。超过一半的读者从不点开。决定互动的 instagram caption limit 因此是 125，尽管硬限制是 2,200。
30 个 hashtag 的上限是硬性的：试图加第 31 个会让整篇帖子发布失败。经验上 5-10 个 hashtag 表现最好；超过 11 个之后流量加成几乎走平，算法也开始把它当成垃圾内容。
其它字段：简介 150 字符，显示名 30 字符，私信 1,000 字符。
LinkedIn——3,000 帖子、1,300 甜区、「see more」折叠
LinkedIn 帖子的 linkedin character limit 是 3,000，但 feed 只显示前 210 字符，之后折叠在「see more」之下。1,200-1,500 字符区间的帖子在 LinkedIn 上最容易拿到互动（Buffer 和 Hootsuite 的多份研究都收敛到 1,300 左右的峰值），这个长度足够展现价值，又不会拖到读者放弃滚动。
LinkedIn Articles（长文发布产品）允许 110,000 字符，实际上等于不限。Profile headline 上限 220，about 区 2,600。
Facebook——63,206 字符、80 字符自然流量甜区
Facebook 那条 63,206 字符的上限大体只是冷知识；实际场景中 80 字符以下的帖子比更长的帖子能拿到约 30% 更高的自然互动（HubSpot 多年来一直观察到这一规律）。折叠以上桌面端显示约 477 字符，移动端在 125 字符处裁剪。
评论上限 8,000 字符。点赞、转发和点击全部偏向短帖；长文应该放在链接文章里，而不是 Facebook 的标题里。
新兴平台——Bluesky、Mastodon、Threads、TikTok
- Bluesky 帖子上限 300 字符，是少见的特例：Bluesky 按字素簇计数，因此七个码点的家庭 emoji 👨👩👧👦 算 1 个字符，而不是 7 个
- Mastodon 默认每条 toot 500 字符，但实例管理员可以把上限提到 5,000 甚至取消；发帖前确认你登录的实例
- Threads 沿用 Twitter 风格的 500 字符上限，按码点计数
- TikTok 标题允许 2,200 字符，折叠以上约 100 字符可见
Reddit、Discord、Slack——长内容与社区默认
- Reddit 标题 300 字符（subreddit 的版主常通过 AutoModerator 强制低于 60）；评论 10,000 字符
- Discord 标准消息 2,000 字符；嵌入描述 4,096；Nitro 把纯消息上限提到 4,000
- Slack 消息 40,000 字符；超过 2,000 字符后可读性急剧下降，许多接收者会直接忽略长消息
Word Count Targets by Content Type
社交和 SEO 是字符限制的主场；其它场景大多按字数来衡量，包括学术作业、计费、内容营销和长篇手稿。下表给出每类常见内容的目标范围和阅读时间估算（按 230 wpm，Brysbaert 2019 静默阅读元分析的中位数）。
| 内容类型 | 字数目标 | 阅读时间 @ 230 wpm | 备注 |
|---|---|---|---|
| Tweet | 30-40 words | 10 sec | 按字符而非字数优化 |
| LinkedIn post（甜区） | 170-250 words | 1 min | 折叠以上 |
| Instagram caption（钩子） | 20-25 words | <10 sec | 前 125 字符 |
| Blog post——短篇 | 500-700 words | 2-3 min | listicle、新闻、快评 |
| Blog post——标准 | 1,000-1,500 words | 4-7 min | 教程、深度指南 |
| Blog post——长篇 | 2,000-3,000 words | 9-13 min | 综合指南 |
| SEO pillar page | 2,500-5,000 words | 11-22 min | 主题权威 |
| 学术论文（高中） | 500-1,500 words | 2-7 min | 因作业而异 |
| 学术论文（本科） | 1,500-3,000 words | 7-13 min | 按作业要求 |
| NaNoWriMo 日更 | 1,667 words/day | — | 30 天写完 5 万字 |
| 小说——短篇 | 50,000-70,000 words | — | YA、悬疑 |
| 小说——标准 | 80,000-100,000 words | — | 成人小说 |
| 会议演讲（12 分钟 @ 130 wpm） | 1,500-1,600 words | 演讲 | 排练后再确认 |
| 播客单集（30 分钟 @ 130 wpm） | 3,900 words | 演讲 | 脚本部分 |
对内容营销来说，阅读时间是比字数更有用的目标单位：读者对「5 分钟阅读」这种标签的反应比对「1,150 字」更可靠。字数仍然是计费（翻译按源字数）、平台合规（NaNoWriMo 的 5 万字、学术作业的 2,000 字上限）以及合同条款的硬通货。字数统计在你打字时实时显示两者，外加按 130 wpm 估算的演讲时间，适合做演讲和播客时使用。
6 Counting Mistakes That Break Real Apps
下面这些故障是已发布代码和已上线营销活动中反复出现的。每条都配上症状、根因和修复。
Mistake 1: Using string.length for character-limit validation
**症状：**用户粘贴一条含三个 emoji 的推文，实际只有 270 个码点。你的前端校验显示 276 并拒绝提交。或者更糟，代码放过了一篇 285 个码点的草稿（因为 emoji 的预算相互抵消），结果 Twitter 在服务端拒收。
**根因：**JavaScript 的 String.prototype.length 返回 UTF-16 码元。每个 emoji 是一个代理对，占 2 个码元。每个辅助平面字符（数学符号、古代文字）也是同样。
**修复：**用展开运算符或 Array.from 按码点遍历。
// ❌ wrong
function isUnderTwitterLimit(text) {
return text.length <= 280;
}
// ✅ correct
function isUnderTwitterLimit(text) {
return [...text].length <= 280;
}如需更深入的基于正则的码点遍历模式（包括字素簇处理），Regex Cheat Sheet 涵盖了 /u 和 /v 标志以及 Unicode 属性转义。
Mistake 2: Splitting CJK text on whitespace for word count
**症状：**一篇 500 字符的中文文章被报告为 1 个 word。按此估算的翻译报价错了 500 倍。
**根因：**中日韩语言不用空格分词。text.split(/\s+/) 会把整篇文章当成一个 token 返回。
**修复：**把每个 CJK 表意文字算作一个 word，这是 Microsoft Word、Google Docs 以及所有原生 CJK 字处理器的约定。
function countWordsMixed(text) {
const cjk = (text.match(/[一-鿿-ヿ가-]/g) || []).length;
const latin = (text
.replace(/[一-鿿-ヿ가-]/g, ' ')
.match(/[A-Za-z0-9]+(?:['’-][A-Za-z0-9]+)*/g) || []).length;
return cjk + latin;
}上述 Unicode 范围覆盖 CJK 统一表意文字（U+4E00 到 U+9FFF）、平假名与片假名（U+3040 到 U+30FF）以及韩文音节（U+AC00 到 U+D7AF），正是 Microsoft Word 字数统计当作表意文字的四个块。
Mistake 3: Forgetting Twitter URL 23-char substitution
**症状：**草稿在你的计数器上显示 320 字符，其中包含一个 80 字符的 URL。你花了 10 分钟修剪文本，才意识到 Twitter 本来就会以 263 字符接收原稿。
**根因：**Twitter 在发布时把每个 URL 替换成 23 字符的 t.co 短链。你那个原始计数器并不知道。
**修复：**用 raw − URL_length + 23 对每个 URL 预先估算发布后的长度。草稿含多个 URL 时把每个修正值累加。已发布内容中的 URL 识别遵循 RFC 3986，正是 URL Encoding & Decoding 指南讲到的同一套解析规则。
Mistake 4: Writing meta description to 320 chars (old guideline)
**症状：**你写了一段 280 字符、把 CTA 放在末尾的 meta description。在 Google 搜索结果里，描述在第 158 个字符处被截断，CTA 从未出现。
**根因：**2017 年 12 月到 2018 年 5 月之间，Google 曾短暂把 meta description 显示扩展到 320 字符。许多 SEO 教程至今仍引用那个数字。Google 已于 2018 年中恢复到约 160，此后再未改变。
**修复：**按 150-160 字符写。主关键词放在前 30 字符内，CTA 放在最后 30 字符内。对重要页面使用像素精确的 SERP 模拟器：宽字形（W、M、K）比窄字形（i、l、t）更快吃掉预算。
Mistake 5: Confusing 280 characters with 280 words
**症状：**团队里有人写「我们要发一条 280 字的推文」，结果交出 1,500 字符的好文笔。推文发不出去。
**根因：**字符与字数概念混淆。英文散文中这两个单位大约相差 5-6 倍。
**修复：**为每个平台钉死规则。Twitter、SMS 和 SEO meta 数字符；NaNoWriMo、学术作业、翻译合同以及大多数内容营销 brief 数字数。拿不准时，查平台自己的计数器（Twitter 的发布框、Word 的「审阅 > 字数统计」），再去敲定规格。
Mistake 6: Pasting smart quotes that silently switch SMS to UCS-2
**症状：**你把客户回执模板从 Google Doc 复制到 SMS 发送系统。原稿 145 字符，以 GSM-7 单段发出。粘贴之后仍是 145 字符，却按 2 段 UCS-2 计费。百万级活动的成本翻倍。
**根因：**Google Docs 和 Word 会自动把 " 和 ' 转成排版引号 " " 和 ' '。这些引号不在 GSM-7 字符集内，会让整条消息切换到 UCS-2。
**修复：**发送前先做归一化：
function toGsm7Quotes(s) {
return s
.replace(/[“”]/g, '"') // " " → "
.replace(/[‘’]/g, "'") // ' ' → '
.replace(/[–—]/g, '-'); // – — → -
}在涉及计费的发送之前运行它。Twilio、MessageBird 和 Bandwidth 都会在响应中暴露一个 encoding 字段——把它记录下来，模板预期是 GSM-7 但实际出现 UCS-2 时发出告警。
FAQ
字符计数与字数计数有什么区别？
字符计数把每一个字符——包括空格、标点和 emoji——都算上，多数现代平台按 Unicode 码点衡量。字数计数针对拉丁文字按空格分隔的 token 数，针对中日韩文字逐个表意文字计算。Twitter、SMS 和 SEO meta description 用字符计数。学术论文、NaNoWriMo 手稿和翻译发票用字数计数。
为什么 Twitter 把 emoji 算 1 个字符，JavaScript 却算 2 个？
Twitter 按 Unicode 码点衡量——每个 emoji 是一个码点、一个字符。JavaScript 的 string.length 衡量的是 UTF-16 码元。大多数 emoji 都在 U+FFFF 之上，在 UTF-16 中以代理对编码，因此占两个码元，.length 返回 2。用 [...text].length 或 Array.from(text).length 才能得到 Twitter 真正在数的码点数。
为什么 SMS 字符限制有时是 160 有时是 70？
SMS 默认使用 7 位的 GSM-7 编码，在 140 字节的载荷里装下 160 个字符。如果消息包含任何非 GSM-7 字符——emoji、智能引号、CJK、超出小子集的带重音拉丁字母——整条消息就会切换到 16 位的 UCS-2 编码，单段上限掉到 70 个字符。消息中任何位置一个 emoji 就会触发切换。
2026 年理想的 meta description 长度是多少？
对准 150-160 个字符。Google 桌面端 SERP 在 155-165 字符附近截断，具体落点取决于显示像素宽度；移动端在 100 到 120 之间裁剪。低于 120 字符时 Google 经常用页面正文中的一段直接替换你的描述。把主关键词放在前 30 字符，CTA 放在最后 30 字符，让消息从任一方向被截断后仍然完整。
字符限制包含空格和 emoji 吗？
是的，几乎所有平台都包含。空格、换行、标点和 emoji 各算一个 Unicode 码点。值得记住的两个例外：SMS（emoji 会触发上述编码切换），以及 Bluesky（按字素簇计数，所以家庭 emoji 👨👩👧👦 这样的多码点 emoji 只算 1 个字符而不是 7 个）。
中文、日文、韩文的字数怎么计算？
每个 CJK 表意文字算 1 个 word——这是 Microsoft Word 中文模式字数统计、Google Docs、原生 CJK 编辑器以及所有商业翻译记忆系统的约定。一篇 500 字的中文短文报告为 500 words。混合文本按字符数表意文字、按空格数拉丁 token，两者相加。
Twitter 的 280 字符限制如何处理 URL 长度？
Twitter 在发布时把每个 URL 自动包裹为 23 字符的 t.co 短链，与原始长度无关。发布长度遵循公式 published = raw − URL_length + 23，每个 URL 单独计算。一篇含一个 100 字符 URL 的 320 字符草稿，发布后实际占 243 字符。Twitter 按 RFC 3986 模式识别 URL，因此查询字符串和片段都会被吸收进 URL token。
Related reading
- Regex Cheat Sheet：字符校验的模式匹配、Unicode 属性转义
- Text Diff Online Guide：逐行、逐字符比较两段文本
- URL Encoding & Decoding Guide：文本通过 URL 传输时的转义规则
- Understanding Base64：「比特如何变成字符」编码的另一面，应用于邮件与二进制数据