使用方法
- 在大文本框里粘贴或输入标题文本。它默认已经直出「柳泉工具 - 免费在线计算器合集」这一条中英混排样例，打开页面就能看到字符数、汉字数与估算像素宽；清空后想恢复点「载入示例」。
- 三个数字框分别是汉字像素宽、拉丁／符号像素宽与对照用像素上限，都写了 min、max、step。前两个默认 14 与 7，是估算用的近似值；上限默认 600，代表一个可自行改动的搜索结果宽度参照。改完任意一个直接按 Enter 重算。
- 大文本框因为要换行，约定 Ctrl/Cmd + Enter 触发重新检测；点「检测标题长度」按钮效果相同。
- 结果区带 role="alert"：五张卡片给出字符数、汉字数、其他字符数、估算像素宽与距上限余量，下面
<pre>逐行打印代入过程、是否超限的结论，以及「同样 60 字符在纯汉字与纯拉丁下差多少像素」的对照。 - 点「复制结果」取走快照；「导出对照表 CSV」下载带 BOM 的表格；「复制对照表 TSV」把 16 行样例按制表符复制。对照表默认只显示 12 行，点「加载更多」展开其余 4 行。
所有估算都只在当前页面完成，不发起网络请求、不写 Cookie、不碰 localStorage，标题不会被上传到任何地方。
这个工具能解决什么问题
第一，纠正「标题别超过 60 字符」这条被误用到中文上的经验。这条建议来自以拉丁字母为主的搜索结果环境，那里的 60 个字符大约对应一个固定像素宽度；但一个汉字在常见字体下差不多顶两个拉丁字符宽，同样写满 60 个字符，纯中文标题的像素宽可能是纯英文的两倍，早就触发截断了。本页把字符数与像素宽并列给出，让这句经验有可核对的边界。
第二，让中文标题的「字数」有分层口径。标题标签长度检测这一名称里的「标签」指的是 HTML 的 title 标签与搜索结果里那一行可点击标题，它既不是正文，也不是描述。字符数、汉字数、其他字符数是三个不同的量：空格、连字符、竖线、英文单词都算字符却不都是汉字，混排标题里它们占的宽度和汉字完全不同，分开报才不会误判。
第三，提前发现会被截掉的尾巴。很多标题在后台看着完整，到了搜索结果页却被省略号砍掉后半段，品牌名或核心卖点正好落在被砍掉的部分。本页给一个可自行设定的像素上限，超过就明确提示「很可能按像素截断」，方便你把最重要的词往前挪。
边界也要说清：本页做的是估算，不是浏览器真实排版；不读取网页、不请求搜索引擎、不判断关键词排名，也不改写标题。旧占位脚本里那套把编码、反转、大小写混在一起的通用文本逻辑同样不沿用，本页只回答「这个标题在三种口径下各是多少、估算多宽」。
计算原理与三个口径
字符数 = title.length，按 UTF-16 码元计；BMP 内的汉字、拉丁字母、半角标点各占 1。中文全角标点也算 1 个字符，虽然它在屏幕上往往和汉字一样宽。
汉字数用 Unicode 区间 /[\u4e00-\u9fff]/g 逐字符匹配，只数中日韩统一表意文字基本区里的汉字；英文单词、数字、空格、连字符、中英文标点都不计入。其他字符数 = 字符数 − 汉字数，代表所有非基本区汉字的成分。
估算像素宽 = 汉字数 × 汉字像素宽 + 其他字符数 × 拉丁像素宽。默认值 14 与 7 来自「汉字约 14 px、拉丁与符号约 7 px」的近似；把它拆成两项，是因为一个汉字在常见无衬线字体里差不多正好是拉丁小写字母宽度的两倍。默认样例「柳泉工具 - 免费在线计算器合集」有 13 个汉字和 3 个其他字符，代入就是 13 × 14 + 3 × 7 = 203 px。
与像素上限比较。上限是你可以自己改的参照值，脚本算「上限 − 估算宽度」得到余量：余量为负就提示很可能被截断；为正也不保证不被截断，因为真实渲染还受字体、字重、字距和容器宽度影响。
本页真正要讲透的是：搜索结果按像素宽度截断，不是按字符数。搜索引擎给标题留的是一段固定像素的可视区域，超出就用省略号砍掉，它并不去数你写了几个字。于是「60 字符」这条经验只在「一个字符约 7 px」的拉丁语境里成立：同样 60 个字符，纯拉丁按 7 px 估、纯汉字按 14 px 估，后者像素宽是前者的两倍，前者稳稳放得下，后者必然被截。对中文标题来说，按字符数判断长短从根上就是错的口径——一个 30 汉字的标题字符数只有 30，看起来远没到 60，像素宽却已经和 60 个拉丁字符相当；反过来一个 60 个拉丁字母的标题字符数触顶，像素宽却只有纯汉字标题的一半。因此本页坚持同时给字符数、汉字数、估算像素宽三个量，并让前两个只是「组成说明」，真正用来判断截断的是第三个。把三者混为一谈，或者只报一个「字符数」就说标题合格，是中文 SEO 里最常见也最隐蔽的误判。
完整示例（默认输入实算）
默认标题是「柳泉工具 - 免费在线计算器合集」。页面脚本按上面的口径实算得：字符数 = …，汉字数 = …，估算像素宽 = … px。这三个数都不是写死在源码里的，而是脚本对默认标题逐字符判定后算出来的。
再看「60 字符」这条经验有多不稳：同样写满 60 个字符，纯拉丁标题按 7 px 估算约 … px，纯汉字标题按 14 px 估算约 … px，后者是前者的两倍。默认标题只有 16 个字符，却已经占了 203 px，就是因为 13 个汉字每个都比拉丁字符宽一倍。
把文本框换成你自己的标题，或把两个像素宽改成你站点实际字体的近似值，五张卡片与逐行推导会同步刷新；对照表里 16 条样例也用同一函数计算，不存在「示例一套、实算另一套」的情况。
对照表怎么读
工具区下方那张表由脚本对 16 条标题逐条调用同一个统计函数生成：列是标题节选、字符数、汉字数、其他字符数、估算像素宽、是否超过像素上限，中间四列全是算出来的。样例里特意放了纯中文、纯英文、中英混排、带竖线与连字符、超长品牌后缀等组合，方便你横向看「字符数差不多、像素宽差很多」。
默认显示 12 行，点「加载更多」展开其余 4 行；「导出对照表 CSV」给带 BOM 的文件，「复制对照表 TSV」给制表符文本，都包含展开后的全部行。读表时别只看字符数列，把汉字数列与像素宽列对着看，才能理解为什么中文标题更容易被截。
结果边界与舍入规则
- 像素宽是估算值。14 与 7 是近似常数，真实宽度受字体、字重、字号、字距、浏览器缩放影响；本页给的是可复核的相对量，不是浏览器实测的布局宽度，也不联网取真实渲染。
- 全角标点与全角字母。中文逗号、书名号不在汉字区间里，按「其他字符」用拉丁宽估算，实际却接近汉字宽，会让估算偏小；全角字母同理。遇到大量全角标点时，请自行把像素宽调高再看余量。
- Emoji 与生僻字。Emoji 是 UTF-16 代理对，字符数按码元会记 2，汉字数不计入，像素宽估算按「其他字符」处理；补充平面汉字同理。这类字符的真实宽度远大于估算，不适合用本页做精确判断。
- 非法输入。标题为空、三个数字框为空／非数字／越界／带小数，各有指名到具体输入框和当前值的报错；脚本不会用「取不到就当 0」兜底，也不会把空标题算成 0 px 后报「合格」。
- 上限只是参照。对照用像素上限默认 600，可自行改动；超过只提示「很可能截断」，为正也不保证不截断，因为真实容器宽度由搜索结果页决定，本页无从得知。
- 舍入。字符数、汉字数、其他字符数都是整数计数；像素宽是两个整数相乘再相加，结果仍是整数，不做四舍五入，也不按有效数字截断。
- 本地性。只有正则匹配、长度统计与整数运算，没有 fetch、没有表单提交、没有第三方脚本，也不写 Cookie 或 localStorage。
常见问题
为什么 60 字符的经验对中文标题不适用？
因为搜索引擎按像素宽度截断，一个汉字约顶两个拉丁字符宽。同样 60 个字符，纯汉字标题的像素宽约是纯拉丁的两倍，前者必被截、后者放得下。字符数相同不代表占的像素相同，只看字符数就会把中文标题误判成「还很短」。
字符数、汉字数、其他字符数有什么区别？
字符数是整条标题的码元总数；汉字数只数基本区表意文字；其他字符数是两者之差，涵盖空格、连字符、竖线、英文、数字与标点。三者是组成关系，混排标题里汉字多寡直接决定像素宽，所以要分开报。
估算像素宽准确吗？
它是按 14 与 7 两个近似常数算出来的相对量，不是浏览器实测的布局宽度。字体、字重、字距、缩放都会让真实宽度浮动，所以本页只用来比较和预警，不当作精确像素值；两个常数都能在页面上改。
中文标点为什么会让估算偏小？
中文逗号、句号、书名号不在汉字正则区间里，被归到「其他字符」按 7 px 估，可它们显示起来和汉字差不多宽。全角标点多的标题会被低估，遇到这类标题请调高拉丁像素宽或把余量留得更宽。
超过像素上限就一定会被截断吗？
只是「很可能」。上限是你自己设的参照值，本页不知道搜索结果页真实的容器宽度；余量为负要警惕，为正也不能打包票。稳妥做法是把品牌名与核心词放在标题前半段。
三个数字框填错了会怎样？
空值、非数字、越界或带小数都会中止并给出指名到框、带当前值的具体提示，不会用默认值兜底。三个框都要求整数，因为这里数的是字符个数与像素整数，不接受小数。
标题里的 Emoji 怎么算？
Emoji 是代理对，字符数按码元记 2，汉字数不计入，像素宽按「其他字符」用 7 px 估，而它真实显示往往更宽。含大量 Emoji 或生僻字的标题，请把本页结果当粗略参考，别用于精确截断判断。
标题内容会上传吗？
不会。全流程只有正则匹配、长度统计与整数运算，没有网络请求、没有表单提交、没有第三方脚本，也不写 Cookie 或 localStorage。关掉标签页，标题随页面一起消失。