::after分隔符显示方块是因›未被当前字体支持，应改用content: "\203A";；需用li:not(:last-of-type)::after排除末项；设display:inline-block并统一font-family或transform缩放优化对齐；避免HTML硬编码，注意高对比度模式兼容。
为什么 ::after 生成的分隔符常显示为方块或乱码
直接写 content: "›"; 在某些字体或系统下会渲染失败，尤其在中文字体为主、未显式指定 font-family 的场景里，›（U+203A）可能 fallback 到不支持该字符的字体，最终显示为方块（）或空白。这不是 CSS 写错了，而是字符编码未被当前字体覆盖。
- 优先用 Unicode 十六进制转义：例如
content: "\203A";，比直接写字符更稳定 - 避免使用易混淆的相似符号，如
>（HTML 实体）、>（ASCII 小于号）、»（U+00BB，双右角引号），它们语义和宽度都不同 - 若项目需兼容旧 Android 或 iOS Safari，可降级用
\003E（即>），但视觉上不如\203A精准
面包屑中每个 ::after 分隔符只加在非末项上
给所有 li 加 ::after 会导致最后一项也带分隔符，破坏语义。必须排除最后一个子元素——但注意不能简单用 :last-child，因为面包屑 DOM 结构里末项可能是 li:last-child，也可能包裹在 nav 或 ol 中，且存在辅助节点（如图标、span）干扰。
- 推荐用
li:not(:last-of-type)::after，它基于元素在父容器中的“类型顺序”，不受中间插入的非li节点影响 - 如果结构是
ol > li，则ol > li:not(:last-child)::after更直观，且兼容性更好（:last-of-type在 IE 中不支持） - 务必设置
display: inline-block或display: inline给::after，否则content可能不渲染（默认为display: inline，但某些重置样式会改掉）
content 里的字符宽度与对齐问题怎么调
像 3A 这类符号在不同字体中字宽不一致，容易造成文字错位或右侧留白过大。单纯靠 margin 微调不可靠，因为缩放或 font-smoothing 会改变实际像素占位。
- 统一设置
font-family: "Segoe UI", system-ui, sans-serif;，确保分隔符走等宽/半宽路径，避免中文字体强行撑开 - 用
transform: scale(0.85)缩小分隔符（配合vertical-align: middle），比调font-size更安全——它不影响行高计算 - 如果分隔符紧贴文字后出现挤压，加
letter-spacing: 0.15em在li上，而非::after，避免跨浏览器渲染差异
要不要用 SVG 或伪元素替代 content 字符
纯字符方案足够轻量，但遇到需要颜色渐变、响应式旋转（如折叠态箭头）、或无障碍要求（如 screen reader 需明确标识“分隔”语义）时，字符就力不从心了。
立即学习“前端免费学习笔记（深入）”；
- SVG 作为
background-image插入::after是可行的，但需 base64 编码或外链，增加维护成本；且无法继承父级文字颜色 - 更实用的做法是：保留
content: "\203A"作为默认，再用color和opacity控制其状态；仅当设计要求动态翻转（如 RTL 语言自动镜像）时，才用transform: scaleX(-1) - 真正该警惕的是：把分隔符写死在 HTML 里（如每个
li后手动加<span class="sep">›</span>），这会让 DOM 膨胀、语义混乱，且无法通过 CSS 批量控制状态
content 字符不会自动反色，得靠 forced-colors 媒体查询兜底。 
