go无substring函数，直接s[0:n]按字节截取会因越界panic或破坏utf-8编码致乱码；安全截取须先转[]rune按字符数操作。
截断字符串时为什么 substring 会 panic？
Go 没有内置的 substring 函数，直接用 s[0:n] 切片超长字符串会触发 panic: runtime error: slice bounds out of range。更隐蔽的问题是：如果字符串含中文、emoji 等 Unicode 字符，按字节截取会破坏 UTF-8 编码，导致乱码（比如截出半个 ? 显示为 ）。
正确做法是先确认长度是否足够，再按 rune（而非 byte）计数截取：
func truncateRune(s string, maxRunes int) string {
runes := []rune(s)
if len(runes)
- 永远用
[]rune(s)转换后再操作，避免字节越界和编码损坏 - 不要用
utf8.RuneCountInString单独算长度再切——多一次遍历，且仍需防越界 - 注意：空字符串或
maxRunes 时需单独处理，否则 <code>runes[:0]返回空串但逻辑可能不符合预期
添加省略号（…）时如何避免长度溢出？
加 "…" 后总长度可能超过限制，尤其当 maxRunes 很小（如 1 或 2）时。直接拼接 truncateRune(s, maxRunes-1) + "…" 在 maxRunes == 0 或 1 时会越界或显示异常（如 "…" 占 1 个 rune，但截 1 位后只剩 0 位给原内容）。
安全写法是预留至少 1 个 rune 给省略号，并做最小长度兜底：
func truncateWithEllipsis(s string, maxRunes int) string {
if maxRunes
-
maxRunes == 1是关键边界：不能截 0 位再加"…"，必须直接返回"…" - 省略号用 UTF-8 的
"…"（U+2026，1 个 rune），别用三个英文点"..."（3 个 runes），否则长度计算全错 - 如果业务要求省略号可选，建议把
ellipsis bool作为参数，而不是复用maxRunes做魔法判断
性能敏感场景下如何避免重复分配？
高频调用（如日志、API 响应截断）中，[]rune(s) 每次都新建切片并拷贝所有 rune，开销明显。若已知字符串基本是 ASCII（如日志 ID、路径片段），可先快速检查是否全在 ASCII 范围内，跳过 rune 转换：
func fastTruncate(s string, maxRunes int) string {
if maxRunes 0x7F {
allASCII = false
break
}
}
if allASCII {
if len(s)
- ASCII 快速路径能提升 3–5 倍性能（实测 10KB 字符串，百万次调用）
- 但注意：该优化仅适用于「大部分输入是 ASCII」的场景；若常含中文，反而因多一次扫描而变慢
- 别试图用
unsafe或预分配[]rune缓冲——Go 的 slice 复用在字符串场景难安全落地，得不偿失
Web 输出时要不要 HTML 实体转义？
如果截断结果直接插入 HTML（如 <div>{{.Title}}</div>），而原始字符串含 、<code>& 等字符，截断后未转义会引发 XSS 或标签错乱。但转义必须在截断之后做，否则 < 会被当成普通文本计算 rune 数，导致逻辑错乱。
- 顺序只能是：原始字符串 → 截断（含省略号）→ HTML 转义
- 用标准库：先
truncateWithEllipsis(s, n)，再html.EscapeString(result) - 千万别在截断前转义——
"<"是 4 个 runes，但语义上只是 1 个，用户感知的“长度”不是这个 - 模板引擎（如
html/template）自动转义时，确保传入的是截断后的纯字符串，不要提前手动转义两次
"??" 是 4 个 runes，但视觉上是一个图标。按 rune 截断可能把它切成 "?" 这种无效序列。真有这类需求，得用专门的 Unicode 图形簇（grapheme cluster）库，比如 golang.org/x/text/unicode/norm 配合 iter，但绝大多数业务不需要走到那一步。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
