前阵子帮朋友排查个老系统，用户昵称入库后动不动就变问号方块。查了半天才发现截断逻辑有问题：那套代码图省事，拿 substr 按"长度"硬切，默认字符串长度就是字节数。ASCII 下这俩确实一回事，可 UTF-8 里一个汉字占 3 字节、一个 emoji 占 4 字节，按字节拦腰斩，汉字直接被劈成两半，落库成乱码，严重的还会触发数据库字符集报错。
最隐蔽的是这种 bug 测试阶段根本发现不了，测试数据全是字母数字，永远碰不到多字节字符。
正解其实简单：按码点或者字素簇来切，别盲信 string length。Python 切片 [] 是按码点的，JS 用 Array.from 或 Intl.Segmenter 都行。下次写截断前，先想想你的用户会不会用中文名、爱发表情包。
顺着楼主说的"按码点切是正解"这一点，我想稍微往深里推一层。码点（code point）确实比字节安全，但码点之上还有一层叫字素簇（grapheme cluster）的概念，这一层没兜住，截断照样会出怪事。
举个具体例子：用零宽连接符 ZWJ 拼出来的"家庭"组合表情，或者带重音符号的 é（当它由字母 e 加一个组合重音符两个码点拼成时），视觉上明明是一个"字"，底层却由好几个码点组成。Python 的切片和 JS 的 Array.from 都是按码点迭代的，碰上这种复合序列照样会拦腰斩断——Array.from 会把那个家庭表情拆成若干个元素，你按"前 N 个元素"截断，出来的就是被劈散的无效序列，前端渲染多半是豆腐块或空白。严格来说
所以严格讲（strictement parlant），Intl.Segmenter 配上 grapheme 模式才是真正按"人眼看到的字符"来切的方案，Array.from 只是比 substr 安全了一截，不宜和前者划等号说"都行"。当然绝大多数场景用户名里不会出现 ZWJ 序列，码点级截断已经够用，楼主的大方向没错。
顺带一句，MySQL 那边 VARCHAR(20) 的 20 到底按字符还是按字节算，还取决于库用的是 utf8（实际是 utf8mb3，最长 3 字节）还是 utf8mb4，前者连 4 字节 emoji 都存不下。光修应用层截断未必治本，你们排查老系统时可以顺手核对一下字符集。
顺着你说的 JS 那段补一句：Array.from 和 Intl.Segmenter 其实不是一回事，不能一句"都行"就带过。
Array.from(str) 是按码点迭代的，能把代理对拼回一个完整的码点，所以代理对表示的 emoji 不会被劈开。但它停在码点这一层就结束了——遇到 ZWJ 连写的复合 emoji，或者"基字符 + 组合附加符号"这样的字素簇，Array.from 照样给你切散。真要按"用户眼里的那一个字"来截断，还是得用 Intl.Segmenter 配上 granularity: ‘grapheme’。
另外"一个汉字占 3 字节"对常用字成立，但 CJK 扩展 B 区往后的生僻字和 emoji 都是 4 字节，照着 3 字节节奏估截断位置照样翻车。你们那套老系统后来怎么改的？
补个细节：Python 切片按码点而非字素簇，组合字符 é 或 ZWJ 表情仍会被劈开，光靠它还不够稳。
排查这种藏得深的 bug 最熬人，辛苦了。测试数据净是字母数字这点太真实，真实用户一进来准露馅。
顺着"按码点切是正解"这个点我想补一句：码点层面截断，照样能把字素簇劈开。比如带组合重音的字母（é 可以是 e 加组合音符两个码点拼出来的），或者肤色修饰符、ZWJ 连写的家庭 emoji，用户眼里明明是一个字，底下却是好几个码点。从中间断，落库还是半截乱码。
另外"一个 emoji 占 4 字节""字符串长度就是字节数"得看语言。JS 的 string.length 数的是 UTF-16 码元，不是字节，所以 JS 系统踩的坑其实是代理对（surrogate pair）被斩断;真正按字节硬切的是 PHP 的 substr，老 PHP 系统最典型;Python3 的 [] 确实按码点走，这点帖子说对了。
所以更稳的做法是拿字素簇边界来切（JS 用 Intl.Segmenter，Python 上 grapheme 库都行），别停在码点就当完事。再补一层：代码切对了还不够，数据库列本身若是按字节限长——比如老 MySQL 的 utf8 三字节上限——emoji 压根存不进，得上 utf8mb4 才算闭环。
你们那套老系统最后是用 Array.from 还是 Segmenter 修的？
测试数据全是字母数字这个太真了，等用户带着表情包杀进来才露馅哈哈。之前见人emoji被截成方块，丑哭
读到最后那句"按字节拦腰斩"，心里忽然一动。一个好好的汉字被劈成两半，落进库里成了谁也认不出的方块，这画面竟有些让人心软。本来圆满的一整团…，非要按外头的尺子从中间量断，剩下的那半截，自己也不知该往哪儿去。
最让我感慨的还是你说的那个盲区。我们总拿自己最习惯的那一小撮数据去验证整个世界：字母数字干净利落，便以为天下字符都该这般规整。可真实的人偏偏爱用中文名，偏偏爱甩个表情包进来。一个系统若只容得下最驯服的那部分输入，它眼里的"完整"打从一开始就是缺的。
忽然觉得，许多看不见的残缺，原是被人用"整齐"两个字轻轻盖住了。
按字节拦腰斩这个形容也太生动了哈哈。说真的，测试数据全用字母数字这种事，哪个项目没踩过，写测试图省事都一个德行。你朋友那老系统当初多半也是"能跑就行"心态堆出来的，这种技术债迟早要还 :D
测试数据全字母数字那个太真实了…，谁写单测会特意塞个emoji进去啊… 话说数据库报错那次没把表锁死吧？好奇后续怎么收场的
你提到“按码点或者字素簇来切”，这两者其实差别挺大，值得商榷。
按码点（code point）切片在大部分场景够用，但碰到组合字符还是会翻车。比如带声调的拼音字母，或者某些由基础字符加组合标记拼出来的生僻字，在UTF-8里占多个码点，按码点切一样会劈开。真正严谨的做法是按字素簇（grapheme cluster）切，也就是用户视觉上感知到的“一个字符”。
补充个具体数据：Unicode 15.0标准里定义了超过14万个码点，但实际渲染出的独立字形单位数量要少得多，因为大量码点是用来做组合修饰的。JS里 Intl.Segmenter 走的就是字素簇逻辑，比 Array.from 按码点拆更稳妥。
之前见过一套系统用Python处理藏文文本，直接按码点截断，结果元音符号全被剥离了，存进去的词根本没法读。多字节问题不光是汉字和emoji的事，各种小众语言更容易中招。
以前不是这样的，早年间写代码那会儿大家脑子里全是单字节，ASCII一统天下，谁去管什么码点字素簇。
你提测试数据那个事我太有感触了。我年轻的时候帮人搭过个小论坛，本地跑得好好的，上线第一天就被几个巴西老哥用葡萄牙语带重音符号的名字搞崩了，后台日志刷出来一排排的方块，看着跟天书一样。后来才搞明白是字符集没对齐，光是把那几个名字从库里捞出来修好就折腾了一晚上。
想当年stack_fox前阵子好像也踩过类似的坑，不过他是被emoji的长度教做人了。这种bug就是典型的“平时不吭声，一炸要人命”。慢慢来吧，踩过一次就知道痛了。
补一个坑：按码点切还不够稳。国旗 emoji、肤色修饰符、ZWJ 组合这些都占两个以上码点，Python 切片按码点拦腰斩照样把它们劈开。真要敢让用户狂发表情包，还是得按字素簇切，Intl.Segmenter 才是靠谱方案。
补充一个坑，JS 那句里 Array.from 和 Intl.Segmenter 其实不是一回事。Array.from(str) 按码点拆，但一个视觉上"是一个字"的 emoji 常常由好几个码点拼成——比如带肤色修饰的 👍🏻、ZWJ 连起来的家庭或者旗帜 emoji，Array.from 一拆就散架，截断照样把它们劈开。真要按"字"切，得上 Intl.Segmenter，granularity 设成 ‘grapheme’。
再一个现实麻烦：Intl.Segmenter 挺新，Chrome 87 之后才有，一堆老 WebView 跟旧内核根本不认。碰上跑在老环境里的系统，这条路子得挂 polyfill。所以"Array.from 或 Segmenter 都行"得看场景，要稳就 Segmenter，但得兜底兼容。
Python 那段也没错，不过得限定 py3：py3 的 str 切片按码点，py2 的 str 还是字节，老项目里栽过的人懂的都懂。
说到底截断这活儿最好别放前端兜底。前端按可视长度拦一下纯属体验优化，真正落库的边界让后端用现成库按字符数切最稳
码点这一层还有个坑。按码点切能修好汉字被字节劈半的问题，但码点本身也不是用户眼里"一个完整的字"。像带肤色修饰的 emoji、ZWJ 连写的家庭组合，底层是好几个码点拼出来的。帖子举的 Python s[:n] 和 JS Array.from 其实都只切到码点，从中间斩照样会裂开。想保住显示完整还是得字素簇分割，也就是你最后说的 Intl.Segmenter，前面那几个例子没覆盖到这一层。
我们组早年也栽过，测试库 username 全是 test01，上线首日来了个"司马光砸缸"加一串表情，日志直接刷爆。绝了说真的按码点切只是底线，emoji 连字 Array.from 都救不了，得上 grapheme cluster。
我之前也碰到过，用户名存进去变豆腐块，查半天才知道是字节截断地锅，测试全用ascii真发现不了